(Posting to users list, since this is more a user-oriented issue.)
I think it’s time we drop Java 5 support in JRuby.
Five years ago we took the then-controversial step of dropping Java
1.4 support, largely so we could take advantage of generics and
annotations throughout the codebase. These days, Java 5 is over six
years old, and I think it’s time we took the next step.
Other than Java 5’s age, there’s plenty of reasons to do this:
Linux distributions often don’t even have packages for Java 5, since
it was never an OSS codebase.
It is no longer possible to get Java 5 for OS X (Snow Leopard and
higher simply don’t have Java 5 builds available anywhere).
The lack of Java 5 support on the JRuby team’s dev systems makes it
increasingly difficult to avoid using Java 6+ features. I just did it
again last week (String.getBytes(Charset)).
Android is actually based on Apache Harmony SE 6 (not 5 as I was led
to believe) so it doesn’t represent a Java 5 hold-out.
Java 5 has been EOL by Sun/Oracle for over two years, which means no
further fixes, patches or development have gone into it since that
time.
Java 5 versions for most exotic platforms are now old, EOL, and
buggy as hell (IBM J9, HP/UX, OpenVMS, …)
So I guess I’m asking for a good reason why JRuby 1.7 shouldn’t drop
Java 5 support, finally, and only support Java 6+. Anyone? Anyone?
On Jan 20, 2012, at 9:49 AM, Charles Oliver N. wrote:
(Posting to users list, since this is more a user-oriented issue.)
I think it’s time we drop Java 5 support in JRuby.
[snip bunch of good reasons to drop]
I am in favor of dropping Java5 support for the JRuby 1.7 release. I can
only speak for myself, but none of my machines have had Java5 installed
on them for at least 3 years. There is no reason old technology should
hold us back particularly when Java7 provides so many awesome
benefits.
I understand that JRuby will continue to support Java6. I think that is
fine. Ask me about this again in 2015 when I haven’t had Java6 on my
system for 3 years.
I understand that JRuby will continue to support Java6. I think that is fine.
Ask me about this again in 2015 when I haven’t had Java6 on my system for 3 years.
Yeah, JRuby 1.6.x (if we do any past 1.6.6) will still support Java
5+, JRuby 1.7 will support only Java 6+, and we’ll revisit this in a
year or so. I don’t expect Java 7 adoption to go any faster than Java
6, and that took 2-3 years to get to 50% share in a receptive
environment. We won’t be dropping it any time soon.
I’m happy with that since I don’t have Java 5. Currently, I don’t test
JRuby on Java 5.
After dropping Java 5, we won’t need livetribe-jsr223-2.0.6.jar for
build jruby.jar.
Also, I’m thinking about dropping BSF support. I think people don’t
use that way old API anymore.
-Yoko
On Fri, Jan 20, 2012 at 10:49 AM, Charles Oliver N.
On Sat, Jan 21, 2012 at 12:23 AM, Charles Oliver N. [email protected] wrote:
I would have no problem dropping BSF. Perhaps we could spin it
completely off into its own library and let it die there. Then people
could still use it if they want, but we wouldn’t ship it.
That would be pretty nice. I’ve used it as a macro interpreter in
jEdit; I still mostly use BeanShell macros in it, so it wouldn’t be a
great loss to me, but it would be nice to be able to use Ruby in the
editor.
I would have no problem dropping BSF. Perhaps we could spin it
completely off into its own library and let it die there. Then people
could still use it if they want, but we wouldn’t ship it.
Ok, after tiny unscientific polls here and on Twitter, we can come up
with no compelling reason to continue supporting Java 5 in JRuby 1.7.
So we’re going to drop it.
If we run into any major issues (like if some big user absolutely
can’t leave Java 5) we can roll it back, but for now, JRuby 1.7 will
officially work only on Java 6+.
I’ll let Yoko decide how and when to pull BSF bits out of JRuby, since
the Java 6 requirement means the built-in scripting support will
always be available now.
Charlie
On Fri, Jan 20, 2012 at 9:49 AM, Charles Oliver N.
I certainly sympathize, but it’s a difficult challenge for us to
continue holding back on use of newer APIs and to support older,
buggier versions of the JVM.
Perhaps this is a case where community members like you could take up
ownership of a Java 1.5 version of JRuby? We’re not leaping ahead fo
Java 7, so the API differences are small and could probably be handled
well by “retro” libraries that can rewrite code.
On Mon, Jan 30, 2012 at 5:09 AM, Charles Oliver N. [email protected] wrote:
I certainly sympathize, but it’s a difficult challenge for us to
continue holding back on use of newer APIs and to support older,
buggier versions of the JVM.
Perhaps this is a case where community members like you could take up
ownership of a Java 1.5 version of JRuby? We’re not leaping ahead fo
Java 7, so the API differences are small and could probably be handled
well by “retro” libraries that can rewrite code.
Or several community members could continue to maintain 1.6.x (which
is still 1.5 compatible) after the JRuby team has released 1.7 and is
focused on Java 6+.
-1 as far as I am concerned. We have built an application framework in
my
company on top of JRuby, and at least one (possibly two) rather
important
customer of ours are currently stuck on Java 1.5 on their Websphere
servers. Since most of its usage is for other applications than ours, we
cannot force an upgrade upon them; it’s simply not an option. So, they
are
stuck with Java 1.5 for the moment.
Dropping Java 5-support in JRuby 1.7 means that we won’t be able to
upgrade
our application framework to JRuby 1.7, which may be a problem in the
future when more gems start requiring more recent Ruby versions etc…
Yes,
we can still support this customer with an older version of the
application
framework (based on JRuby 1.6) but having to diverge like that is
sub-optimal, if it can be avoided.
Having said that, I can still understand that you want to drop the Java
5-support, because of the reasons previously mentioned. Still, I just
want
to affirm that we are actually using (and relying on) the support for
Java
5.
I think it might be easier for backports if we allow the community to
branch off of master since the deltas between master and 1.6 is
getting rougher and rougher.
