Apple's missing Java 6 - Revision history

JenniferVendetti: Undo revision 8446 by Anzorik (Talk)

2010-08-31T22:07:15Z

Undo revision 8446 by Anzorik (Talk)

Anzorik at 12:00, August 12, 2010

2010-08-12T12:00:51Z

Tredmond: /* Dealing with Java5 Compiler issues */

2009-11-16T15:09:35Z

‎Dealing with Java5 Compiler issues

Tredmond: /* Building Java 6 on the PowerPC */

2009-11-16T14:58:10Z

‎Building Java 6 on the PowerPC

Tredmond: /* The Problem and Our Current Options */

2009-11-15T19:52:41Z

‎The Problem and Our Current Options

Tredmond: /* The Problem and Our Current Options */

2009-11-15T19:19:50Z

‎The Problem and Our Current Options

Tredmond: /* The Problem and Our Current Options */

2009-11-15T19:15:26Z

‎The Problem and Our Current Options

Tredmond: /* The Problem and Our Current Options */

2009-11-15T19:14:47Z

‎The Problem and Our Current Options

Tredmond at 19:14, November 15, 2009

2009-11-15T19:14:25Z

Tredmond: Created page with ' 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 ap...'

2009-11-15T19:08:57Z

Created page with ' 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 ap...'

New page

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.
<pre>
hg clone http://icedtea.classpath.org/hg/icedtea6
</pre>
I needed to get/install
* mercurial
* md5sum
* gawk
* eclipse-ecj.jar ([http://archive.eclipse.org/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php eclipse.org])
* xalan.jar ([http://xml.apache.org/xalan-j/downloads.html xml.apache.org])
* giflib-devel ([http://sourceforge.net/projects/giflib/ sourceforge.net])
Thus far my configure line looks like this:
<pre>
./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 \
--with-rhino=${jars}/js.jar
</pre>
My current error is
<pre>
./configure: line : syntax error near unexpected token `XPROTO,'
./configure: line 11028: `PKG_CHECK_MODULES(XPROTO, xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)'
</pre>

From this [http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/172377.html] 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 autogen.sh, but next time I'd just symlink /usr/local/share/aclocal.

← Older revision		Revision as of 22:07, August 31, 2010
Line 58:		Line 58:
	Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.		Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.
	[[DealingWithJava5CompilerIssues\|dealing with Java 5 compiler issues]]		[[DealingWithJava5CompilerIssues\|dealing with Java 5 compiler issues]]
−
−	~~= External Links =~~
−	~~[http://mackeeper.zeobit.com/mac-recovery-software Data Recovery Software for Mac]~~

← Older revision		Revision as of 12:00, August 12, 2010
Line 58:		Line 58:
	Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.		Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.
	[[DealingWithJava5CompilerIssues\|dealing with Java 5 compiler issues]]		[[DealingWithJava5CompilerIssues\|dealing with Java 5 compiler issues]]
		+
		+	= External Links =
		+	[http://mackeeper.zeobit.com/mac-recovery-software Data Recovery Software for Mac]

← Older revision		Revision as of 15:09, November 16, 2009
Line 57:		Line 57:

	Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.		Sometimes there are problems getting correct files to compile in java 5. Here is a page I made about how to troubleshoot these problems.
−	[[DealingWithJava5CompilerIssues\|~~Dealing~~ with Java 5 ~~Compiler Issues~~]]	+	[[DealingWithJava5CompilerIssues\|dealing with Java 5 compiler issues]]

@@ Line 20: / Line 20: @@
 == Building Java 6 on the PowerPC ==
 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.
@@ Line 51: / Line 53: @@
 From this [http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/172377.html] 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 autogen.sh, but next time I'd just symlink /usr/local/share/aclocal.

@@ Line 4: / Line 4: @@
 We could stick with Java 5 as the final Protege development platform.  I am having a great deal of trouble stomaching this option.
 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.

@@ Line 5: / Line 5: @@
 We could stick with Java 5 as the final Protege development platform.  I am having a great deal of trouble stomaching this option.
-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 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.
+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.
 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.

@@ Line 1: / Line 1: @@
 =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 their java development.  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.
+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.

← Older revision		Revision as of 19:14, November 15, 2009
Line 1:		Line 1:
		+	=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 their java development. 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.

		+	We could stick with Java 5 as the final Protege development platform. I am having a great deal of trouble stomaching this option.
		+
		+	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 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.
		+
		+	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.
		+
		+	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 ==

	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.		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.