Moving to Java 5 gave us much needed language features to improve our
code. New language features don't come with Java 6.

Where Java6 may give performance improvements with the existing API
then a user can switch to using that of their own choice.

The only API feature I think I was curious of was the JTree. I think
this has been improved and we have occasional bug reports due to
strange tree behaviour of the explorer due to the standard Java JTree
(control-click and then drag of multiple items is difficult). I was
curious to see if that had been improved.

Within GEF I followed a period of offering full Java1.3 support but
including Java1.4 features (n particular mousewheel support to scroll
diagram). I did this by compiling with Java1.4 JDK (but target set to
Java1.3 during compile). Any source code that I knew to be calling
Java1.4 API I placed within an if block that tested the JRE at runtime
was appropriate before making the call. That worked fine but does
include the danger of accidentally including new API features by
accident.

I'd suggest we leave things for the time being and wait for an
argument from a developer who specifically needs a new API method. We
can keep our rules on EOSL a little looser to give ourselves the
option to drop support for a specific Java release at any time of our
choosing once Sun support has ended but we can make that decision of
exactly when for ourselves.

When we need to do this we could follow a slightly better method than
I did for GEF. As ArgoUML splits into more smaller components we could
have alternative components loaded based on JRE at runtime. e.g. Load
the Java6 based explorer component only if runtime is Java6 or above
otherwise load the Java5 based explorer component. That removes the
danger that was possible with GEF as each component is either built
with Java5 or Java6 JDK with no change of target.

Regards

Bob.

2009/7/23 Linus Tolke <[email protected]>:
> Hello Jan!
> For the past years, we have used the policy to not provide new versions of
> ArgoUML that runs on JRE's no longer supported by Sun (i.e. that EOSL or
> EOL). This is allowing us to move forward in step with the oldest
> Sun-version. EOL for Java1.4 was the biggest step in this because it meant
> that we could start using Generics and Annotations.
>         /Linus
>
> 2009/7/23 Jan Barnholt <[email protected]>
>>
>> On 24/7/09 5:51 AM, Linus Tolke wrote:
>>
>> > Note that we could still build the Windows and tar releases with Java6
>> > as long as we build specific Mac 32-bit releases using Java5 but that
>> > would complicate the build process a little.
>>
>> Hmm, but what's the point if you couldn't use any Java6 features anyway
>> because
>> they would break the Mac/Java5 build..?
>>
>> Not sure about how switching Java versions was handled in the past,
>> neither how
>> big the Mac user base is anyway - but given the fact that ArgoUML is also
>> targeting academic users, where computers in general tend to stay around
>> in labs
>> for quite a while, I was just wondering whether there are pressing reasons
>> to
>> switch to Java 6 now..?
>>
>> Cheers,
>> Jan
>>
>> ------------------------------------------------------
>>
>> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2374985
>>
>> To unsubscribe from this discussion, e-mail:
>> [[email protected]].
>> To be allowed to post to the list contact the mailing list moderator,
>> email: [[email protected]]
>
>

------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2375118

To unsubscribe from this discussion, e-mail: 
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email: 
[[email protected]]

Reply via email to