On Tue, 7 Dec 2004, Mark Taylor wrote:
> > I've been playing with Java 1.5 and the ANT build system/STARJAVA for a
> > couple of days to get a better idea of what work needs to be done (spurred
> > on by the fact that 1.5 is now the standard SUN download, as we can all
> > see from the reports we're getting now) and have managed to get it nearly
> > all working, except for two remaining issues.
> >
> > 1) The Java compiler now attempts to do the right thing with extension
> > classpaths (the ones we add to our jar files), but the implementation
> > is a bit deficient in that it doesn't allow for circular dependencies
> > (and merrily blows up). I can work around this by tweaking the
> > .properties files of various packages, but the downside is that these
> > dependencies will need to be moved up the food chain to other
> > packages (and removing these dependencies will break any test
> > targets making use of them). This effects "array", "hdx", "table" and
> > "votable" so far.
>
> These are mostly mine. The circular dependencies are in there more
> or less as a convenience - for instance votable relies on table,
> but table's classpath references votable because you're probably
> likely to want votable if you're using table. However as long as
> the application (or any other jar file higher up than both) remembers
> to reference both jar files, that reference doesn't actually need to
> be there.
But at the moment may be missing, which is why I haven't committed all my
patches.
> As you say, this may break test targets, but that can
> presumably be taken care of by tweaking the classpath in the build.xml
> <junit> elements?
Yes, getting the test targets working again should just be a case of
patching the tests-classpath <path>.
> > 2) The DOM interface has been upped from Level 2 to Level 3. This means
> > there are a load of extra methods that HDX and VOTable need to
> > implement. A null implementation might do as presumably we don't
> > actually use any Level 3 calls.
>
> Hmm, I did take a look at this a while ago and it didn't look like
> much fun - DOM level 3 is a much bigger API. Tedium rather than
> technical difficulties, but even so. Maybe there's a not-too-tedious
> way round it (for VOTable), I'll have a think.
Certainly does seem to be expansive for not much obvious reason. HDX for
instance requires an extra 39 methods adding to it (did the null
implementation for that before loosing the will to live).
> > Clearly 1) can be worked around with effort and future care (it's probably
> > worth complaining to SUN about it too), but 2) requires effort from Norman
> > and Mark, so it looks like a good point to stop for now, but I get the
> > feeling that we will need to move on these sooner rather than later now.
>
> Hmm, it only affects people who want to build starjava, not just run
> it, and I wouldn't have thought there were many of those out there.
> Are you itching to move to using J2SE1.5 features in code? Although
> there are clearly some nice things there (typed collections) I'd be
> inclined to stick at 1.4 for the forseeable future to avoid forcing
> users to upgrade their JVMs.
Naturally I'd like to start playing with the new features, but that's
probably not the right thing to do just yet. We should plan to remain
source compatible for 1.4, but I am worried about collaborators and others
who want to build the collection, they may like to use 1.5 and now that
SUN recommends it may feel our stance increasingly unreasonable (and a
barrier). I also feel unhappy about saying we're OK with 1.5 but without
any day to day testing by us, which we currently don't have the option to
do. I spot 10 times more problems than any user.
Cheers,
Peter.
|