Apple's missing Java 6

From Protege Wiki
Jump to: navigation, search

The Problem and Our Current Options

It looks as though Apple has stopped development on the powerpc and the 32 bit intel macs. Apple has always had a very hard time keeping up with Java development but they are now working on being four years behind on these two platforms. Even for Apple this is excessive. Though there does not appear to be any information coming from Cupertino, my suspicion is that there will never be an apple or sun supported java 6 on the powerpc. This creates a problem for the Protege group who are now considering the possibility that java 6 will never arrive. Here is my analysis of the options that I see. All the choices are bad.

We could stick with Java 5 as the final Protege development platform. I am having a great deal of trouble stomaching this option.

We have also considered dropping the problematic platforms. All of us in the protege group are uncomfortable with this option. In particular we know people who are using protege (including me!) on the laptops and desktops in question. This option has not entirely been ruled out but we are favoring rejecting it. Over time this may become more palatable.

I have looked into building java 6 on the problematic platforms using openjdk. This is cool but I think there are several problems that make me think that this is not workable. First we would then be supporting our own java distribution - a game that I really don't want to get involved in. Also my experiments indicate that openjdk will have several dependencies. So we would have to install several packages multiplying the problems that will arise. Alternatively there is this macports technology (very cool!!) that will automatically build java 6 openjdk. It doesn't work now on the powerpc but probably will soon. But this is time consuming (several hours to build java 6) and I suspect that there will be build issues. I have pretty much decided to reject this option.

The final two options - which is where I am beginning to go - both involve maintaining code bases for java 5 and the latest java. To support this we would do nightly builds and junit runs in both java 5 and java 6. We would only have to take further measures if, for some reason, the nightly java 5 builds and junits started to fail. It may very well be that there will not be too many cases where the code bases are different. There will be many issues that we have not yet figured out like whether a java 5 client can safely connect to a java 6 server.

So there are two different remaining proposals. First we could create a java 5 branch for the projects that need some additional work. We would create nightly scripts that would merge changes from the trunk into the java 5 branch. If the compile, junits or merge failed then the merge would not be committed. We would have to be somewhat careful with the script but we would probably get it right after a few tries. An advantage of this approach is that regular java 6 developers would not have to be aware of the java 5 issue.

Alternatively, we would not create a branch. Instead we would create multiple source trees. Regular developers would use src and src.java6. Developers maintaining the java 5 platforms would use src and src.java5. The advantage of this would be that there would be no branches and all the additional sources of error associated with this would be removed. It would also be very easy to switch between java 6 and java 5 builds. But I think that this is a bit awkward because classes could move between the src and src.java6. The packages would remain the same but there would be movement of classes from src to src.java6 when issues are discovered.

Actually I guess we could also do this in a single source tree and distinguish the java 6 vs java 5 specific code with a package name. This is easy to manage in the build files but might be more awkward in ides such as eclipse.

We haven't taken the plunge yet but I think that we are getting closer to doing this.

Building Java 6 on the PowerPC

There is a new wiki starting up about this. The mac ports didn't work on the g4 when I tried it because the bootstrap openjdk did not include a g4 version.

If I can succeed, the Protege team will consider the policy of not waiting for Apple once a java release reaches its end of life. The disadvantage of such a policy is that apple users will probably be unhappy about needing to install and run on X11.

This will probably get more detailed when I do it the next time. I am trying the build from icedtea which I got with the following mercurial command.

    hg clone

I needed to get/install

Thus far my configure line looks like this:

./configure --enable-zero=yes  \
            --with-project=bsd --with-gcj-home=/usr/local/lib/gcj-4.2.2 \
            --with-ecj-jar=${jars}/eclipse-ecj.jar \
            --with-xalan2-jar=${jars}/xalan.jar  \
            --with-xalan2-serializer-jar=${jars}/serializer.jar \
            --with-xerces2-jar=${jars}/xercesImpl.jar \

My current error is

./configure: line : syntax error near unexpected token `XPROTO,'
./configure: line 11028: `PKG_CHECK_MODULES(XPROTO, xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)'

From this [1] I found that pkg.m4 needs to be in autoconf's library path. I'm using fink and found that pkg.m4 was already in /sw/share/aclocal. I stuck a command line parameter (-B) into, but next time I'd just symlink /usr/local/share/aclocal.

Dealing with Java5 Compiler issues

Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems. dealing with Java 5 compiler issues