[DrJava] Re: New JSR 14.

[Charles R. <cr...@ri...>]

Jim Van Fleet wrote:
> Yeah, JSR 14 has become a 1.5 preview.  Suddenly, we're en vogue!
> 
> I'm here and ready to help you work on it.  It's an issue with our team,
> too.  (I'm working with Zoran on his compiler group.)
 >
> I'm hoping that it will be positive in at least one of these ways.  1)
> If it worked in DrJ, we could just use that as our coding platform.  2)
> The process might illuminate me on how we could plug this into Eclipse,
> which is what they are/have been using.

We should be able to get it to work with DrJava pretty soon (probably next 
week).  Eclipse is a very different can of worms, because they have 
incremental compilation.  I don't see Eclipse cooperating with JSR-14 until 
IBM actually makes an effort to support it.  Guess they'd better get 
started, if JDK 1.5 is scheduled for the end of this year.


> I'm taking notes already on what's going on.  Do you know anything about
> shell scripting?

I have a passing knowledge if you have any questions, but it sounds like 
you got the general idea of the scripts they included.


> I see one probably minor issue and a couple of major ones.  Note that this
> is only in my esitmation, I am not familiar enough with these parts of DrJ
> to think I'm an authority.
> 
> The script distributed with the files flat out won't work for OS X, as it
> assumes the presence of rt.jar instead of classes.jar and ui.jar (I
> think...)  That's the minor issue.

Actually, we won't be using their scripts at all-- we call their compiler 
programmatically, so it isn't an issue.


> The first major issue is that this new JSR-14 appears to depend on 1.4,
> potentially forcing us to choose between generics and 1.3 support.  I'll
> let you make the call.  What's happening is that the javac and java
> scripts are depending on an environment variable being set that indicates
> the root of a valid 1.4 distribution.  It doesn't check that that are, in
> fact, 1.4, it just checks that they exist.  (At least, from what I can
> tell with my extremely limited shell script knowledge.)  It does the same
> with the jsr-14 jar, but I figured that wasn't just a big deal-- we're
> already finding that in some way, it's just that the file name may have
> changed.

In fact, JSR-14 v1.0 requires JDK 1.3, JSR-14 v1.2 requires JDK 1.4.0 and 
JSR-14 v1.3 requires JDK 1.4.1.  I'm not surprised that JSR-14 v2.0 
requires JDK 1.4.1.  (Note that this is true regardless of the scripts.)

In the recent past, the only way to use generics in JDK 1.3 (eg. on Macs 
without Jaguar/1.4.1) is to find a copy of JSR-14 v1.0, or use GJ itself. 
DrJava can support those compilers, but we can't redistribute them (and Sun 
doesn't distribute old versions of JSR-14).  So technically, there has been 
no "legal" way for new users to use generics in JDK 1.3 unless they happen 
to have an old copy of JSR-14.

Our current job is to write a new adapter to support JSR-14 v2.0 while 
maintaining compatibility with all the old versions.  Someday, we'll drop 
support for JDK 1.3, but not yet.  :)


> The other major issue is that the alias for javac passes the new jsr-14
> jar to the java interpreter that's running javac as its boot class path.
> I'd imagine this is going to have to be done "by hand" in the code.
> Then, on top of that, I believe javac itself is given the generic
> collect.jar and rt.jar on its boot classpath.
> 
> Java invocation is a bit more straightforward, it's just
> 
> /bin/java -Xbootclasspath/p:${JSR14DISTR}/gjc-rt.jar
> 
> after the checks I've mentioned above.

This is going to be a headache.  Previous versions of JSR-14 haven't 
required changes to rt.jar or even collect.jar.  We'll have to be very 
aware of this in both the compiler adapter and the Interactions Pane, since 
classes compiled with JSR-14 v2.0 will need to have this new rt.jar for 
updated library classes.  (Note that the user might need to reset the 
Interactions Pane if he switches to JSR-14 v2.0 while DrJava is running...)

I think we can pull all of this off, but it will take a little work.  Neal 
and I are going to start experimenting with it this afternoon.

Thanks for your input, and I'm sure we can use your help.

Charlie