Eclipse would not build without this patch.

I will look at alternatives.

Do you have two VMs installed, and just want to use the 1.4, or have you violated the package dependency "j2sdk>=1.5"?

Sorry for the trouble, in any case. I will work on getting this to build without the patch. Any suggestion would be happily accepted. I would never second-guess upstream (I'm actually more vehement about this than most) if it didn't seem to be necessary to get anything working at all!

Thanks for taking a look at this.

I do have 2 VM's installed (I'm a Java developer) - and wasn't even using JDK1.5 at all up until recently. But the problem that I was having was that after I upgraded to Eclipse 3.2, I could no longer run JUnit tests from Eclipse on a project that was configured to use the 1.4 JVM.

Hmmm .... I'm surprised that Eclipse wouldn't build without the patch.

As I'm a Java developer, and pretty knowledgeable about this stuff, I'll take a look at this and try to find a solution for you.

Thanks again.

Well, the build errors I get are:

[javac] 1. ERROR in /var/abs/local/eclipse/src/plugins/org.eclipse.pde.build/src/org/eclipse/pde/internal/build/FeatureWriter.java
[javac] (at line 24)
[javac] public class FeatureWriter extends XMLWriter implements IPDEBuildConstants {
[javac] ^^^^^^^^^^^^^
[javac] The return type is incompatible with Writer.append(CharSequence, int, int), PrintWriter.append(CharSequence, int, int)
[javac] ----------
[javac] 2. ERROR in /var/abs/local/eclipse/src/plugins/org.eclipse.pde.build/src/org/eclipse/pde/internal/build/FeatureWriter.java
[javac] (at line 24)
[javac] public class FeatureWriter extends XMLWriter implements IPDEBuildConstants {
[javac] ^^^^^^^^^^^^^
[javac] The return type is incompatible with Writer.append(char), PrintWriter.append(char)
[javac] ----------
[javac] 3. ERROR in /var/abs/local/eclipse/src/plugins/org.eclipse.pde.build/src/org/eclipse/pde/internal/build/FeatureWriter.java
[javac] (at line 24)
[javac] public class FeatureWriter extends XMLWriter implements IPDEBuildConstants {
[javac] ^^^^^^^^^^^^^
[javac] The return type is incompatible with Writer.append(CharSequence), PrintWriter.append(CharSequence)


It didn't take long then to find that other people have run into this problem too, and these build error messages are discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=102560 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=125091.

But I think the crux of the problem is in this comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=125091#c9 Bottom line is this:

For the Eclipse JUnit test runner to run correctly even with 1.4 VM's, the Eclipse package needs to get *built* using both a 1.4 VM *AND* a 1.5 VM. As described in that comment, the correct way to build Eclipse is to set JAVA_HOME to your 1.4 VM, and then specify a "-java5home" argument (pointing to your 1.5 VM) when building. I've verified on my machine that this works. If you build it that way, then the build process is smart enough to know which VM to use when, and will result in a package that works correctly using either 1.4 or 1.5.

However, as Arch is on the bleeding edge, the distro no longer *has* a package for JDK1.4. In theory this isn't a problem, as 1.5 is generally backwards compatible with 1.4. But this is one place where it's not: if your build produces 1.5-era class files, then you lose some backward compatibility.

This can be a small or large problem, depending on which package/library is at issue. But in the case of a package like Eclipse - the major IDE that most people use for their Java editing - I think this is a fairly big problem.

Despite Arch's cutting edge philosophy, many (most?) people in the Java commmunity still have not upgraded to JDK1.5, or need to support 1.4-era legacy code. And unfortunately, Arch's Eclipse package won't properly support people still relying heavily on JDK1.4. (They won't be able to launch JUnit tests from within Eclipse. And it's possible there may be other Eclipse features that will have similar problems, which we haven't encountered yet.)

The question is: how to solve this issue?

* Ignore it? (Since there may not be a lot of Arch users that are affected by this (i.e., Java users still using JDK1.4). I know I was one, but there may not be many others.)

* Add JDK1.4 back into Arch just so that this package can get built properly?

* Don't add JDK1.4 back into Arch, but have the package maintainer use their own local install of JDK1.4 when building the package. (This presents a problem, though, because then users won't be able to build Eclipse themselves using ABS unless they have a copy of JDK1.4 installed too. Maybe somehow indicate in the PKGBUILD that jdk1.4 is required? And make the build fail if it's not present?)


What do you think is the best solution here?

I think I'm onboard for a slightly modified version of your third suggestion: effectively, make the download (if possible) and unarchiving of the 1.4 JDK binaries distribution part of the eclipse PKGBUILD. It doesn't get "installed", just untarred and made available in the build directory.

Then it is used to build eclipse, along with the 1.5 VM.

Effectively, encapsulate the 1.4 JVM monolithically into the build process so it will be there. This places no burden on anyone but the package maintainer, and not very much burden on him (me) either.. just a matter of one more download as part of the build process. For anyone who wants to recreate the results, it's no problem.

David, if you want to take a crack at the PKGBUILD rewrite along these lines, feel free. I can probably get to it sometime next week, if you would don't mind waiting.

Thanks so much for helping find our way through this issue.

Hmmmm ... nice idea, but I don't think this is going to be as simple as you'd like. As Jason Chu recently found out with the jre and jdk packages, it's difficult to find a place where you can download a JDK in an automated fashion suitable for a PKGBUILD. (There was a recent thread on the mailing list about this.)

Sun only just recently relaxed their licensing on Java, allowing Linux distros to bundle a JDK in with the distro. Prior to that it was not allowed, and all downloads had to be manual, where you clicked a checkbox to accept their license, etc.

As I mentioned, they now do allow distro bundling, and so now have a site for automated downloads (see https://jdk-distros.dev.java.net/developer.html). But it appears that you can only download JDK1.5 from that site, not 1.4 too.

As your approach would require an automated D/L of JDK1.4, I'm not sure it's workable.

Thoughts?

This non-automatable thing happens from time to time. In that case, I'm happy with the source line just containing the filename and a comment above/below the sources line saying the URL to which you should go to download it. Anything that documents it, I'm not so caught up in the notion that it absolutely needs to be totally automated. Just easy.

Hmmm ... still not so simple. The D/L from Sun is a bin file - not a zip/tar archive. The bin needs to be executed, then you need to hit the space bar a few times (to skip through the license), then you need to answer "yes" to the "do you accept the license" question. Even *this* is a P.I.T.A. to automate.

Why don't we just do this:

* use a _JDK14_HOME variable in the PKGBUILD, which defaults to blank or /usr/local/share/jdk1.4 or something (but the user can manully change this in the PKGBUILD to point to the appopriate place where they've got JDK 1.4 installed)

* check that a JDK exists at that location before building; if not, abort the build

* assuming it's found, export JAVA_HOME=$_JDK14_HOME and build

What do you think?

Or maybe something like this:

export _JAVA_VERSION=$($JAVA_HOME/bin/java -version 2>&1 | head -n 1 | cut -f 3 -d " " | cut -f 2 -d \" | cut -f 1 -d _ | cut -b 1-3)
if [ "1.4" != $JAVA_VERSION ]; then
echo "JAVA_HOME must be set to a 1.4 JDK in order to build Eclipse";
return 1;
fi

Full PKGBUILD then might look something like this:

pkgname=eclipse
pkgver=3.2
pkgrel=2
pkgdesc="Eclipse IDE development platform"
arch=(i686 x86_64)
url="http://eclipse.org"
depends=('j2sdk>=1.5' gtk2)
install=$pkgname.install
makedepends=(zip libgnomeui apache-ant)
source=(ftp://mirror.calvin.edu/$pkgname/downloads/drops/R-3.2-200606291905/$pkgname-sourceBuild-srcIncluded-$pkgver.zip \
eclipse.sh \
eclipse.desktop )
md5sums=('67b41802092d4b2f779fb756dcaec85c' \
'aa63d963281dbb31f90e2511f074687e' \
'0bee44d3b8839d6b217b6a5efb27407f')

build() {
export _JAVA_VERSION=$($JAVA_HOME/bin/java -version 2>&1 | head -n 1 | cut -f 3 -d " " | cut -f 2 -d \" | cut -f 1 -d _ | cut -b 1-3)
if [ "1.4" != $_JAVA_VERSION ]; then
echo "JAVA_HOME = $JAVA_HOME";
echo "_JAVA_VERSION = $_JAVA_VERSION";
echo "JAVA_HOME must point to a version 1.4 JDK in order to build Eclipse";
return 1;
fi

cd $startdir/src/

...

etc.

This should be in 3.2.1-1. Can you confirm it solves your problem?

Looks good to me. Feel free to close the bug.

Oh, and by the way, please remove eclipse-jdk5.patch from CVS, as we won't need it anymore.

Thanks for taking care of this.