moving to jdk 1.6

Hi, I thought it'd be useful to get information on what's preventing us from moving to jdk 1.6 listed in one place. My motivation is to be able to use certain 1.6 javax.swing classes in the workflow-run-manager suite.

After

   cd core/src/org/ecoinformatics/util/

   cp DBConnection-JDK1.6-Java DBConnection.java

kepler seems to work fine for me with 1.6 under the new build system, both from the command line beneath linux, and on Eclipse (launched w/ system default 1.5) on Mac, by selecting 1.6 from within Eclipse.

What's holding us up? Can the new build system allow certain modules to require different versions of java?

Derik

Could someone on the build and release team let me know your thoughts on this?

And of course we'd presumably (hopefully!) reap additional benefits from the new language features.

My particular case for moving to 1.6 is weak, but I'd like to hear others thinking on this. Are there reasons to stay with 1.5? Is there a timeframe for moving to 1.6? As I mention in the previous post I've been trying it for a little bit now and haven't noticed any issues, but perhaps I have overlooked something(s)...

Hi Derik,

Thank you for your attention to this issue. One problem with requring 1.6 is that is not available for certain versions of Mac OS X (10.4 and earlier). As you know, as soon as we move to 1.6 in the DBConnection class, I believe that 1.5 will no longer work.

I personally would be inclined to require the move to Java 1.6, but then I am certainly not someone who would be negatively affected by such a move in any way.

What I would like to hear are objections from anyone, whether on the build and release team or not, to requiring 1.6. I think people are hesitant. I know that someone in our group is in fact running a slightly older Mac and they cannot use 1.6...

Java 1.6 was not working with Eclipse on the Mac, see http://chess.eecs.berkeley.edu/ptexternal/wiki/Main/Mac#Eclipse1_6

So, we should probably not require Java 1.6 until someone verifies that it will work on the Mac with Eclipse.

However, it would be nice if the build could handle different versions of Java, perhaps by just copying the appropriate file or else by having two directories, one that contains the file in question for Java 1.5 and different directory that contains the appropriate file for Java 1.6.  BTW - I think someone totally lost it at Sun when they introduced that lack of backward compatibility.  By and large, Java is quite backward compatible, this is by far the worst mistake they've made in this area to date.

I also like the idea of the build somehow doing the right thing for different versions.

Are there enough developers on OSes that cannot use 1.6 that this is a reason to wait?

Christopher, is there a reason to need Eclipse itself be running beneath 1.6? On my mac I launch Eclipse with my system default, 1.5, and then from within Eclipse change to 1.6  (via the two Eclipse => Preferences... => Java => Compiler and Installed JREs menus), and Kepler seems to build and run fine.

My system details:

nceas-macbook05:presentations derik$ uname -a
Darwin nceas-macbook05.msi.ucsb.edu 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
nceas-macbook05:presentations derik$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)

Hi Derik,

Right, I can run Kepler under Java 1.6.  However, if Java 1.6 is in my path, then Eclipse does not work very well.  So, more precisely, to run Eclipse with Ptolemy or Kepler on the Mac, you need Java 1.5.  The Kepler or Ptolemy process itself may be run under Java 1.6, but there is this chicken and egg problem:

If I have Java 1.6 in my path first, and DBConnection is changed:

 cd core/src/org/ecoinformatics/util/
 mv DBConnection.java DBConnection-JDK-1.6-Java
 cp DBConnection-JDK1.6-Java DBConnection.java

Then ant will properly build Kepler and I can run Kepler from the command line.  However, Eclipse will fail to start up.

If I have Java 1.5 in my path, then I can use ant to build Kepler, but if I start up Eclipse under Java 1.5 and then run Kepler under Java 1.6, I need to make the above change to get it to compile.

Maybe Eclipse has changed and a newer version works better with Java 1.6 under the Mac.  I'm running 2.0.1v200809-16-1301.

This all seems a little complex, especially for a new Eclipse user. 

The bottom line is that I think we need to support both Java 1.5 and 1.6 in the near term.  Ideally, the build system would recognize which version of Java is being used and act accordingly.

Christopher, yes, I've been juggling similar chicken-egg issues on my mac. I agree with your 'bottom line'. 

Build team, do you have an idea on how difficult it would be to do this?

I've just tried switching my system default to 1.6 (1.6.0_07 -- same steps as in your link), and I get the same error that prevents Eclipse launch as you, and sadly I'm using a very recent Eclipse: Version: 3.4.1 Build id: M20080911-1700

To use Java 1.6 to build the project with Eclipse and from the command-line but to still keep Eclipse running, there are a couple of fairly simple steps you need to take.

(1)

To change the version of java that works at the command-line, got to Applications->Utilities->Java->Java Preferences and change the Java version in both panes to 1.6 (64-bit). This is not enough though. If you type "ant -diagnostics" you will see that the version of Java used by ant is still 1.5. So, you need to change that as well. Right now, Eclipse still works.

(2)

To change the version of Java that ant uses, you need to change the symbolic link. Use the following commands:

cd System/Library/Frameworks/JavaVM.framework/Versions

sudo rm CurrentJDK

sudo ln -s 1.6 CurrentJDK

This will change the version of Java that ant uses. Confirm this by typing "ant -diagnostics." After this change, Eclipse will stop working too...

(3)

Go to the folder which contains the eclipse icon and right click and select "Show Package Contents." Inside the folder, open the Info.plist file. Towards the bottom of this very short file there will be lines that you can uncomment that will make Eclipse use a particular version of Java instead of the default version. In particular, uncomment the following line:

<string>-vm</string><string>/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java</string>

This will make it so that when Eclipse runs, it uses Java 1.5 instead of whatever the default version is. In this way, you can set Java 1.6 to work from the command-line and from ant, but ensure that Eclipse still uses Java 1.5, which it requires. Eclipse will now work again.

(4)

To ensure that Eclipse compiles with Java 1.6, go to Preferences. Select Java->Compiler and change the "Compiler compliance level" to 1.6. This will enable you to use 1.6 features in your code.

(5)

Make sure that the version of org.ecoinformatics.util.DBConnection that you are using is the 1.6 version rather than the 1.5 version. This class is in the the core module.

===

That is pretty much it. For the most part, it is perfectly possible to use Java 1.6 in Mac OS X 10.5. I think some earlier versions of OS X might have some problems because they do not support Java 1.6.

Thanks for the detailed instructions.  It seems like we should continue to support Java 1.5 until Eclipse runs under Java 1.6 without jumping through lots of hoops.  The primary issue is that getting Eclipse to work is bad enough as it is, the subversive plugin setup is tricky etc.  Many Eclipse users are fairly new at this, so I'm loath to ask them to do too much.  Eclipse is pretty much the IDE of choice in this area, we should probably try to make it as simple as possible for these users.

Any ideas on what would be involved with supporting both versions of Java in the build system?  I'd be happy with a fairly brute force method of just copying files around when "ant change-to" was run.  It seems like handling different versions of the OS could also be done by in similar fashion to how the build system should check to see if optional packages like Java3D are present.

_C

Getting the build to change which version of the DBConnection is used depending on the version of Java that is being run by Ant wouldn't be that tricky. (Note that Eclipse users who want to change to 1.6 are still going to have to perform the above steps manually. I can only provide support in the build for the command-line. I suppose if it might be possible to build add a command that makes all the changes necessary on the Mac)

Here is the issue. Should we provide support to 1.6 before we are ready to require 1.6? As soon as developers start checking in 1.6 only features into the code base, they are going break Kepler for those who insist on using 1.5. I suppose that isn't so bad for a non-core module meant to be used by people who are committed to going to 1.6... What is the advantage of developers not willing to force users of their modules to use 1.6 of allowing them to use 1.6 now if we can't use 1.6 features? The only advantage I know of is that the execution speed is a faster. Is this advantage worth making using 1.6 easier given the risk of inadvertently using a 1.6-only feature?

In my view, I think it makes sense to go to 1.6 all at once and actually require it, because I think it would be simpler for developers and it keeps out the confusion from having two different versions of DBConnection.java (and who knows whatever classes in the future) from hanging around. Also, it is certainly an extra step for a developer to confirm that whatever library features they choose to use (and which work fine for them) are backwards compatible with 1.5, especially given the ability of modern IDEs to perform autocompletion and even provide method documentation right there on the fly. I haven't yet heard a compelling rationale for not upgrading. Is there anyone out there running a machine where upgrading to 1.6 (if they don't already have it) would be impossible or extremely difficult? I don't think the simple steps I outlined above are too burdensome for Mac users who choose to use Eclipse, especially since they only have to be performed once.

The NMI nightly builds are running on 1.5, so presumably any 1.6-specific code would cause the nightly build to fail.  That said, its probably better to avoid that situation altogether.  If we do move to support 1.6, we could easily run the NMI build on both 1.6 and 1.5 by just adding in the 1.6 prereq as one of the build configurations.  This would mean the NMI build would be running on Mac, Ubuntu, Fedora, RH, and Windows, each with a build on each of 1.5 and 1.6.  It would take a while (although the builds happen in parallel).

Matt

Yep, I fully understand your point about supporting both 1.5 and 1.6, I've seen the compilation problems that occur.  Developers tend to use the latest and greatest, which is why the nightly build should under 1.5, if not both 1.5 and 1.6.  In the past, the Ptolemy project has released under multiple JDK versions because one size does not fit all, and there is no one choice that meets everyone's needs.  So, we should not require 1.6 until Eclipse easily runs under 1.6 on the Mac.  If we do this, then we lose people like Edward Lee who are on the Mac, use Eclipse, but are not likely to have time to jump through a large number of steps.  If we lose people like Edward, then we are likely to lose other potential developers.

Ptolemy II will not require 1.6 until Eclipse easily runs on the Mac under 1.6.  I'd like to make the switch to requiring 1.6, but cannot justify it at this time.

C jar file.

One more bug for java 1.6.

I checked kepler-trunk out at one cluster head node server, whose os info is x86_64 GNU/Linux. It used to work fine with java 1.6.

Yesterday, I made an update (kepler version 16865, ptolemy version 52662). Everything works fine except compiling util module. Exception info is followed.

It only work after I change java back 1.5 and recompile.

Buildfile: build.xml compile: [compile] Compiling ptolemy... [compile] <<< The module is ptolemy. Setting includes and excludes.... [compile] Compiling common... [compile] Compiling directors... [compile] Compiling actors... [compile] Compiling core... [compile] Compiling util... [compile] Compiling 874 source files to /u/local/apps/kepler/kepler.modules/util/target/classes [compile] error: error reading /u/local/apps/kepler/kepler.modules/util/src/com/numericsolutions/geomodeltools/DensityGridActor.java; /u/local/apps/kepler/kepler.modules/util/src/com/numericsolutions/geomodeltools/DensityGridActor.java (Too many open files) [compile] error: error reading /u/local/apps/kepler/kepler.modules/util/src/com/numericsolutions/geomodeltools/GeomodelGlue.java; /u/local/apps/kepler/kepler.modules/util/src/com/numericsolutions/geomodeltools/GeomodelGlue.java (Too many open files) ... [compile] 100 errors