Moving to Java 5?

[Bill Dortch]

+1

Echoing Marcin's concerns, we should spell out in the JRuby Style Guide any restrictions or caveats for implementing 1.5 features in core code. But it would be great to be able to use features like annotations (goodbye module.defineXxxMethod...), enums, varargs and the various java.util.conncurrent classes.  Auto boxing/unboxing may simplify some JI code as well.

-Bill

On 7/26/07, Marcin Mielżyński <lopx@...> wrote:

Charles Oliver Nutter wrote:

> Before we released 1.0, we discussed the possibility of making future
> releases of JRuby based on Java 5 instead of Java 1.4.2. I think it's
> time to raise that question again.
>
> We have a 1.0 release out now, which largely seems to be very solid
> and very well received. Compatibility is very good and performance is
> comfortable enough to be safely used in real production apps. We will
> maintain the 1.0 branch for users of JRuby 1.0, which will receive
> compatibility and minor performance fixes as appropriate. Release
> 1.0.1 will be coming out soon with a large collection of fixes

> migrated from the trunk work and from a couple large users of JRuby

> that have been helping to merge stuff across.
>
> But the lack of Java 5 support in trunk is now starting to hold back
> development. A short list of things we could actually make use of:
>
> - Enums for the many flags and specifiers in the system
> - Real concurrent collections, rather than emulated implementations
> from the backport library
> - Annotations for specifying method bindings. This could largely
> eliminate the need for manual method-binding code, as well as allow us
> to split method implementations by arity and even argument type
> - Support for Java 5 constructs (generics, varargs, enums) in Java
> integration
> - Elimination of a few areas of inefficiency: environment variables,
> Integer.valueOf (Integer caching), various String manipulation
> methods, Charset conversions...
>
> So there's lots of reasons to start making trunk Java 5+ only. And we
> made good on our promise to release JRuby 1.0 compatible with Java 1.4.2.
>
> Perhaps it's time we made the move to Java 5?
>
> - Charlie
>

+1

Though, I'd be reluctant in using generics too often since they make it
difficult to control casting.

lopex

--
Opole - Miasto Bez Granic.
http://www.opole.pl - tu znajdziesz nowe miejsca, nowe mozliwosci, nowe inspiracje...



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Werner Schuster (murphee)]

Charles Oliver Nutter wrote:
> Before we released 1.0, we discussed the possibility of making future
> releases of JRuby based on Java 5 instead of Java 1.4.2. I think it's
> time to raise that question again.
Just out of curiosity: wouldn't this move preclude JRuby running on
anything that's nowadays called J2ME? From what I know, MIDP doesn't
even have the "new"  Collections API (the one introduced in the last
millennium), let alone anything resembling Java5.

murphee

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Wes Nakamura]

| Charles Oliver Nutter wrote:
| > Before we released 1.0, we discussed the possibility of making future
| > releases of JRuby based on Java 5 instead of Java 1.4.2. I think it's
| > time to raise that question again.

Just another quick note: although I wasn't able to get jruby working
exactly right with gcj (and didn't have time to investigate further),
it's something I've been interested in.  It looks like there will be
changes (using the eclipse compiler) so gcj 4.3 will support java 1.5,
but it looks like that will be awhile.

This isn't a vote for staying at 1.4 (I use both 1.5 and 1.6 at work),
but it is something that crossed my mind.

Wes

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Werner Schuster (murphee) wrote:
> Charles Oliver Nutter wrote:
>> Before we released 1.0, we discussed the possibility of making future
>> releases of JRuby based on Java 5 instead of Java 1.4.2. I think it's
>> time to raise that question again.
> Just out of curiosity: wouldn't this move preclude JRuby running on
> anything that's nowadays called J2ME? From what I know, MIDP doesn't
> even have the "new"  Collections API (the one introduced in the last
> millennium), let alone anything resembling Java5.

Which is why, in order to run on ME right now, JRuby already requires
some substantial hackery, basically paring it down into a completely
different distribution. Adding enums and a few other niceities from Java
5 probably wouldn't make it much worse. But I've never done the chopping
myself, so others might have a different opinion.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Wes Nakamura wrote:

> | Charles Oliver Nutter wrote:
> | > Before we released 1.0, we discussed the possibility of making future
> | > releases of JRuby based on Java 5 instead of Java 1.4.2. I think it's
> | > time to raise that question again.
>
> Just another quick note: although I wasn't able to get jruby working
> exactly right with gcj (and didn't have time to investigate further),
> it's something I've been interested in.  It looks like there will be
> changes (using the eclipse compiler) so gcj 4.3 will support java 1.5,
> but it looks like that will be awhile.
>
> This isn't a vote for staying at 1.4 (I use both 1.5 and 1.6 at work),
> but it is something that crossed my mind.

(Note this isn't directed at Wes, but at general concerns about moving
away from Java 1.4)

It's hard for me to feel those concerns when there's multiple free Java
5 implementations for Linux (the typical place people are running GCJ),
Sun's Java 6 version is available under very flexible distribution
licenses, and there's practically nothing but politics keeping people
from using Sun's Java 5 anyway. And like I mentioned before, JRuby 1.0
would still support Java 1.4; but allowing the pace of other OSS Java
projects (projects we don't test against or run ourselves) to hinder our
development process or make *my* job harder doesn't seem very true to
the bazaar. If there are people out there really concerned about running
on Java 1.4 on GCJ or another Java 1.4 implementation, I'm all for them
stepping up and offering to maintain a compatible version of JRuby. But
everyone I know that contributes to the project is using Java 5 or
higher, and contribution is what earns you a vote.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Charles Oliver Nutter wrote:
> So there's lots of reasons to start making trunk Java 5+ only. And we
> made good on our promise to release JRuby 1.0 compatible with Java 1.4.2.
>
> Perhaps it's time we made the move to Java 5?

I've been playing with Retroweaver today, and it appears to work
sufficiently well enough to make the move to Java 5.

Locally I have my annotation work passing all tests as well as a
"jar-1.4" target that replaces the jruby.jar file with a 1.4-compatible
version. I haven't figured out a good way to run all unit tests with the
1.4 jar, but it passes MRI's test.rb successfully; and largely that may
be enough confirmation.

I will post the complete patch shortly.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Nick Sieger-2]

On 7/26/07, Charles Oliver Nutter <charles.nutter@...> wrote:

It's hard for me to feel those concerns when there's multiple free Java
5 implementations for Linux (the typical place people are running GCJ),
Sun's Java 6 version is available under very flexible distribution
licenses, and there's practically nothing but politics keeping people
from using Sun's Java 5 anyway. And like I mentioned before, JRuby 1.0
would still support Java 1.4; but allowing the pace of other OSS Java
projects (projects we don't test against or run ourselves) to hinder our
development process or make *my* job harder doesn't seem very true to
the bazaar. If there are people out there really concerned about running
on Java 1.4 on GCJ or another Java 1.4 implementation, I'm all for them
stepping up and offering to maintain a compatible version of JRuby. But
everyone I know that contributes to the project is using Java 5 or
higher, and contribution is what earns you a vote.

It's funny, suddenly I take a look around and it seems like the same conversation is happening all over the place.  Lucene [1] and CXF/XFire [2] are two examples I came across today.  [2] is worth reading to remind yourself that retroweaver/retrotranslator are not perfect, and it will be possible for code to drift away from weave-ability.

[1]: http://www.gossamer-threads.com/lists/lucene/java-dev/51605
http://www.nabble.com/The-JDK-1.5-Can-o'-Worms-t4138703.html

[2]: http://www.nabble.com/RE%3A-Java-1.4-p11653138.html

/Nick

[Charles Oliver Nutter-2]

Nick Sieger wrote:

> It's funny, suddenly I take a look around and it seems like the same
> conversation is happening all over the place.  Lucene [1] and CXF/XFire
> [2] are two examples I came across today.  [2] is worth reading to
> remind yourself that retroweaver/retrotranslator are not perfect, and it
> will be possible for code to drift away from weave-ability.
>
> [1]: http://www.gossamer-threads.com/lists/lucene/java-dev/51605
> http://www.nabble.com/The-JDK-1.5-Can-o'-Worms-t4138703.html 
> <http://www.nabble.com/The-JDK-1.5-Can-o'-Worms-t4138703.html>
>
> [2]: http://www.nabble.com/RE%3A-Java-1.4-p11653138.html

At this point I'm not myself concerned about Java 1.4. The retroweaver
stuff I added in was to at least show it can be possible to maintain a
weaved version, and that with what little Java 5 stuff we're using now
we're still in the clear. Outside that, I'm not going to worry about it
all that much...I'm for Java 5.

I think getting unit tests up and running on the weaved JAR will help a
lot with ensuring we're not drifting too far away. And I think one
problem many projects run into is trying to do a mass conversion to Java
5 features; lo' and behold, it turns out some of them don't weave. We'll
take it slow, use things that actually serve a purpose for us, and count
on unit tests and actual 1.4 users to keep us honest. Outside that, the
benefits of Java 5 are too great to ignore any longer.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email