geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: using Java 5 for java.util.concurrent & annotations and then generating 1.4 compliant jars?
Date Tue, 03 Jan 2006 17:38:16 GMT
How does this affect debugging?


On 1/3/2006 8:39 AM, Aaron Mulder wrote:

>That sounds pretty interesting -- does it really fully handle
>annotations?  I thought some of those could be inspected at runtime
>and I'm not sure how that could be supported in 1.4, but I really
>don't know that much about it.
>On a similar note, it would be great if someone could look into why
>DayTrader blows up if run under 1.5.
>On 12/30/05, <> wrote:
>>First a quick bit of background on why Retrotranslator rocks...
>>Retrotranslator can take any Java 5 bytecode using generics,
>>annotations, auto-boxing, varargs & java.util.concurrent utilities
>>and generate regular 1.4 bytecode that runs just fine on Java 1.4.
>>The 1.4 bytecode uses backport-util-concurrent.jar for the
>>java.util.concurrent stuff, retrotranslator_runtime.jar for other new
>>methods added to Java 5 such as new reflection/generics stuff and
>>asm.jar is currently used to read the annotations. So if you only use
>>the Java 5 concurrent APIs then the only new dependency added on 1.4
>>is backport-util-concurrent.
>>We should be able to create a maven 2 plugin (I've already started)
>>which uses Java 5 for the build to make a Java 5 binary but also
>>creates a 1.4 compliant binary.
>>We should hopefully be able to run tests against both JVMs for each
>>binary too.
>>Now given that Java 5 concurrent is faster than backport-util-
>>concurrent.jar & concurrent.jar it would be good for us to use this
>>by default throughout the Geronimo family of projects. Similarly it
>>would be extremely useful to start using annotations and generics &
>>the new for loop can be handy too.
>>So I wonder; should we experiment with 1 module using Java 5 and
>>creating a 1.4 binary jar? (I'm quite tempted to try this in ActiveMQ
>>to see how it goes). If we start with just the java.util.concurrent <-
>> > backport.util.concurrent it'd be fairly easy to switch back again
>>later if we hit some showstopper.

View raw message