You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Antoine Toulme <at...@intalio.com> on 2010/03/21 20:24:34 UTC
Java integration
Hi guys,
I'd like to open a new discussion with Buildr and offer a new insight on
Buildr's link to Java.
>From day one, Buildr was tightly bound to Java. We use either RJB or JRuby
as the gateway to Java, and we have one common API to discuss with it.
We use the Java integration in critical yet well defined operations:
compiling is for sure one, we also run some tools directly.
I think we could find a way to make Buildr less resilient on Java. I wrote
an experimental compiler that relies on an external javac recently here:
http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
This compiler helps me as I need to use a different JDK for part of the
projects I have to compile.
I think the Java integration of Buildr helps starting the JVM only once - I
also think we could support most scenarios by calling Java over a subshell.
I don't know how much more expensive it would turn out to be but I see it as
a good option - when RJB breaks, or when JFFI refuses to load, which happens
all too often.
We know the main problem of Buildr is its installation story. How about we
give a drop and run Buildr gem that just relies on the JVM by calling it,
instead of linking to it ? That would make for less headaches and work
allright on most OSes.
I would like to make such an implementation - as time permits.
Please let me know what you think.
Thanks,
Antoine
Re: Java integration
Posted by Alex Boisvert <al...@gmail.com>.
How do you expect to support antwrap-like functionality with this approach?
And who is your target user? How would he/she be better served than with
JRuby?
Alex
On Mar 22, 2010 8:06 AM, "Antoine Toulme" <at...@intalio.com> wrote:
Simply provide a baseline that will work on any JDK (do we need to run
Buildr on a JDK 1.4 to compile 1.4 code right now ?). That will also let us
use different JDKs for compilation over different projects (I had that use
case recently). And it will be a simple gem.
On Sun, Mar 21, 2010 at 22:45, Daniel Spiewak <dj...@gmail.com> wrote: >
What would the advant...
Re: Java integration
Posted by Antoine Toulme <at...@intalio.com>.
Simply provide a baseline that will work on any JDK (do we need to run
Buildr on a JDK 1.4 to compile 1.4 code right now ?). That will also let us
use different JDKs for compilation over different projects (I had that use
case recently). And it will be a simple gem.
On Sun, Mar 21, 2010 at 22:45, Daniel Spiewak <dj...@gmail.com> wrote:
> What would the advantage be for such a third port over simply Buildr on
> JRuby? Faster startup time maybe, but the startup time would be more than
> dwarfed by the overhead of constantly shelling out.
>
> Daniel
>
>
> On Sun, Mar 21, 2010 at 10:47 PM, Antoine Toulme <at...@intalio.com>wrote:
>
>> I don't want to drop Java integration. It's our differentiator.
>>
>> I want to add a third port that uses subshells to get the job done - same
>> way it's done in Maven today (because apparently, Maven does use a
>> subshell
>> for compilation).
>>
>> On Sun, Mar 21, 2010 at 16:57, Alex Boisvert <alex.boisvert@gmail.com
>> >wrote:
>>
>> > Personally, I'm still enjoying using MRI more than JRuby. If it wasn't
>> > for installation issues and getting JDK 1.6 working on some machines,
>> I'd be
>> > a completely happy camper.
>> >
>> > I think Daniel illustrated well that we need more than exec("java")
>> > functionality to retain the speed and integration we currently have.
>> And
>> > if anything, I want Buildr to have better Java integration, not less, so
>> I
>> > would not want to go to a situation where we have to shell out to "java"
>> > every time something needs to invoke bytecode. I'm happy with using
>> RJB as
>> > lowest common denominator for what should work on Buildr in a standard
>> > sense, and possibly using JRuby for extra features.
>> >
>> > And while I'm a big supporter of having a fully supported, all-in-one
>> JRuby
>> > distro, I don't yet see what we would gain from going JRuby-only and
>> > dropping support for MRI. I would be fine making the JRuby distro our
>> > recommended choice on the download page, though, since it would probably
>> > result in better first experience.
>> >
>> > alex
>> >
>> >
>> > On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <djspiewak@gmail.com
>> >wrote:
>> >
>> >> I think we rely on being able to call onto the JVM too much to do this.
>> >> It's not just for compiler invocation. The most creative use (in my
>> >> opinion) is our test class detection, which works by spinning up a
>> >> URLClassLoader and filtering specified .class files for specific
>> >> attributes
>> >> (such as name or superclass). Of course, as with everything
>> JVM-related
>> >> that we're doing, we could just shell out, but that means we would have
>> to
>> >> eat the cost of JVM startup not once, but several times over the course
>> of
>> >> a
>> >> normal build. There are also tools like Cobertura or the *entire*
>> Groovy
>> >> integration layer which are fairly heavily dependent on Ant. It would
>> be
>> >> annoying and tricky to enable these things through mere shell
>> invocation.
>> >>
>> >> I think the main problem we're trying to solve here is the fact that
>> RJB
>> >> is
>> >> flaky, difficult to install and causes endless compatibility issues. I
>> >> would much sooner solve this problem by going JRuby-only. I mean, I
>> like
>> >> MRI as much as the next guy (particularly for startup), but JRuby has
>> made
>> >> pretty significant strides here in the most recent release. We could
>> do
>> >> even better if we pre-compiled all of the relevant .rb files and
>> >> encouraged
>> >> the use of the all-in-one bundle (still supporting gem installations,
>> but
>> >> only on JRuby).
>> >>
>> >> Just to be clear, I'm not exactly a fan of this idea. MRI support
>> offers
>> >> some very nice advantages (like Growl integration, startup time, etc).
>> >> However, if we are seriously looking to get away from RJB, then I think
>> we
>> >> should do it by going to JRuby, rather than ditching JVM integration
>> >> altogether.
>> >>
>> >> Daniel
>> >>
>> >> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <at...@intalio.com>
>> >> wrote:
>> >>
>> >> > Hi guys,
>> >> >
>> >> > I'd like to open a new discussion with Buildr and offer a new insight
>> on
>> >> > Buildr's link to Java.
>> >> >
>> >> > From day one, Buildr was tightly bound to Java. We use either RJB or
>> >> JRuby
>> >> > as the gateway to Java, and we have one common API to discuss with
>> it.
>> >> > We use the Java integration in critical yet well defined operations:
>> >> > compiling is for sure one, we also run some tools directly.
>> >> >
>> >> > I think we could find a way to make Buildr less resilient on Java. I
>> >> wrote
>> >> > an experimental compiler that relies on an external javac recently
>> here:
>> >> >
>> >> >
>> >>
>> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
>> >> >
>> >> > This compiler helps me as I need to use a different JDK for part of
>> the
>> >> > projects I have to compile.
>> >> >
>> >> > I think the Java integration of Buildr helps starting the JVM only
>> once
>> >> - I
>> >> > also think we could support most scenarios by calling Java over a
>> >> subshell.
>> >> > I don't know how much more expensive it would turn out to be but I
>> see
>> >> it
>> >> > as
>> >> > a good option - when RJB breaks, or when JFFI refuses to load, which
>> >> > happens
>> >> > all too often.
>> >> > We know the main problem of Buildr is its installation story. How
>> about
>> >> we
>> >> > give a drop and run Buildr gem that just relies on the JVM by calling
>> >> it,
>> >> > instead of linking to it ? That would make for less headaches and
>> work
>> >> > allright on most OSes.
>> >> >
>> >> > I would like to make such an implementation - as time permits.
>> >> >
>> >> > Please let me know what you think.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Antoine
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Java integration
Posted by Daniel Spiewak <dj...@gmail.com>.
What would the advantage be for such a third port over simply Buildr on
JRuby? Faster startup time maybe, but the startup time would be more than
dwarfed by the overhead of constantly shelling out.
Daniel
On Sun, Mar 21, 2010 at 10:47 PM, Antoine Toulme <at...@intalio.com>wrote:
> I don't want to drop Java integration. It's our differentiator.
>
> I want to add a third port that uses subshells to get the job done - same
> way it's done in Maven today (because apparently, Maven does use a subshell
> for compilation).
>
> On Sun, Mar 21, 2010 at 16:57, Alex Boisvert <alex.boisvert@gmail.com
> >wrote:
>
> > Personally, I'm still enjoying using MRI more than JRuby. If it wasn't
> > for installation issues and getting JDK 1.6 working on some machines, I'd
> be
> > a completely happy camper.
> >
> > I think Daniel illustrated well that we need more than exec("java")
> > functionality to retain the speed and integration we currently have.
> And
> > if anything, I want Buildr to have better Java integration, not less, so
> I
> > would not want to go to a situation where we have to shell out to "java"
> > every time something needs to invoke bytecode. I'm happy with using RJB
> as
> > lowest common denominator for what should work on Buildr in a standard
> > sense, and possibly using JRuby for extra features.
> >
> > And while I'm a big supporter of having a fully supported, all-in-one
> JRuby
> > distro, I don't yet see what we would gain from going JRuby-only and
> > dropping support for MRI. I would be fine making the JRuby distro our
> > recommended choice on the download page, though, since it would probably
> > result in better first experience.
> >
> > alex
> >
> >
> > On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <djspiewak@gmail.com
> >wrote:
> >
> >> I think we rely on being able to call onto the JVM too much to do this.
> >> It's not just for compiler invocation. The most creative use (in my
> >> opinion) is our test class detection, which works by spinning up a
> >> URLClassLoader and filtering specified .class files for specific
> >> attributes
> >> (such as name or superclass). Of course, as with everything JVM-related
> >> that we're doing, we could just shell out, but that means we would have
> to
> >> eat the cost of JVM startup not once, but several times over the course
> of
> >> a
> >> normal build. There are also tools like Cobertura or the *entire*
> Groovy
> >> integration layer which are fairly heavily dependent on Ant. It would
> be
> >> annoying and tricky to enable these things through mere shell
> invocation.
> >>
> >> I think the main problem we're trying to solve here is the fact that RJB
> >> is
> >> flaky, difficult to install and causes endless compatibility issues. I
> >> would much sooner solve this problem by going JRuby-only. I mean, I
> like
> >> MRI as much as the next guy (particularly for startup), but JRuby has
> made
> >> pretty significant strides here in the most recent release. We could do
> >> even better if we pre-compiled all of the relevant .rb files and
> >> encouraged
> >> the use of the all-in-one bundle (still supporting gem installations,
> but
> >> only on JRuby).
> >>
> >> Just to be clear, I'm not exactly a fan of this idea. MRI support
> offers
> >> some very nice advantages (like Growl integration, startup time, etc).
> >> However, if we are seriously looking to get away from RJB, then I think
> we
> >> should do it by going to JRuby, rather than ditching JVM integration
> >> altogether.
> >>
> >> Daniel
> >>
> >> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <at...@intalio.com>
> >> wrote:
> >>
> >> > Hi guys,
> >> >
> >> > I'd like to open a new discussion with Buildr and offer a new insight
> on
> >> > Buildr's link to Java.
> >> >
> >> > From day one, Buildr was tightly bound to Java. We use either RJB or
> >> JRuby
> >> > as the gateway to Java, and we have one common API to discuss with it.
> >> > We use the Java integration in critical yet well defined operations:
> >> > compiling is for sure one, we also run some tools directly.
> >> >
> >> > I think we could find a way to make Buildr less resilient on Java. I
> >> wrote
> >> > an experimental compiler that relies on an external javac recently
> here:
> >> >
> >> >
> >>
> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
> >> >
> >> > This compiler helps me as I need to use a different JDK for part of
> the
> >> > projects I have to compile.
> >> >
> >> > I think the Java integration of Buildr helps starting the JVM only
> once
> >> - I
> >> > also think we could support most scenarios by calling Java over a
> >> subshell.
> >> > I don't know how much more expensive it would turn out to be but I see
> >> it
> >> > as
> >> > a good option - when RJB breaks, or when JFFI refuses to load, which
> >> > happens
> >> > all too often.
> >> > We know the main problem of Buildr is its installation story. How
> about
> >> we
> >> > give a drop and run Buildr gem that just relies on the JVM by calling
> >> it,
> >> > instead of linking to it ? That would make for less headaches and work
> >> > allright on most OSes.
> >> >
> >> > I would like to make such an implementation - as time permits.
> >> >
> >> > Please let me know what you think.
> >> >
> >> > Thanks,
> >> >
> >> > Antoine
> >> >
> >>
> >
> >
>
Re: Java integration
Posted by Antoine Toulme <at...@intalio.com>.
I don't want to drop Java integration. It's our differentiator.
I want to add a third port that uses subshells to get the job done - same
way it's done in Maven today (because apparently, Maven does use a subshell
for compilation).
On Sun, Mar 21, 2010 at 16:57, Alex Boisvert <al...@gmail.com>wrote:
> Personally, I'm still enjoying using MRI more than JRuby. If it wasn't
> for installation issues and getting JDK 1.6 working on some machines, I'd be
> a completely happy camper.
>
> I think Daniel illustrated well that we need more than exec("java")
> functionality to retain the speed and integration we currently have. And
> if anything, I want Buildr to have better Java integration, not less, so I
> would not want to go to a situation where we have to shell out to "java"
> every time something needs to invoke bytecode. I'm happy with using RJB as
> lowest common denominator for what should work on Buildr in a standard
> sense, and possibly using JRuby for extra features.
>
> And while I'm a big supporter of having a fully supported, all-in-one JRuby
> distro, I don't yet see what we would gain from going JRuby-only and
> dropping support for MRI. I would be fine making the JRuby distro our
> recommended choice on the download page, though, since it would probably
> result in better first experience.
>
> alex
>
>
> On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <dj...@gmail.com>wrote:
>
>> I think we rely on being able to call onto the JVM too much to do this.
>> It's not just for compiler invocation. The most creative use (in my
>> opinion) is our test class detection, which works by spinning up a
>> URLClassLoader and filtering specified .class files for specific
>> attributes
>> (such as name or superclass). Of course, as with everything JVM-related
>> that we're doing, we could just shell out, but that means we would have to
>> eat the cost of JVM startup not once, but several times over the course of
>> a
>> normal build. There are also tools like Cobertura or the *entire* Groovy
>> integration layer which are fairly heavily dependent on Ant. It would be
>> annoying and tricky to enable these things through mere shell invocation.
>>
>> I think the main problem we're trying to solve here is the fact that RJB
>> is
>> flaky, difficult to install and causes endless compatibility issues. I
>> would much sooner solve this problem by going JRuby-only. I mean, I like
>> MRI as much as the next guy (particularly for startup), but JRuby has made
>> pretty significant strides here in the most recent release. We could do
>> even better if we pre-compiled all of the relevant .rb files and
>> encouraged
>> the use of the all-in-one bundle (still supporting gem installations, but
>> only on JRuby).
>>
>> Just to be clear, I'm not exactly a fan of this idea. MRI support offers
>> some very nice advantages (like Growl integration, startup time, etc).
>> However, if we are seriously looking to get away from RJB, then I think we
>> should do it by going to JRuby, rather than ditching JVM integration
>> altogether.
>>
>> Daniel
>>
>> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <at...@intalio.com>
>> wrote:
>>
>> > Hi guys,
>> >
>> > I'd like to open a new discussion with Buildr and offer a new insight on
>> > Buildr's link to Java.
>> >
>> > From day one, Buildr was tightly bound to Java. We use either RJB or
>> JRuby
>> > as the gateway to Java, and we have one common API to discuss with it.
>> > We use the Java integration in critical yet well defined operations:
>> > compiling is for sure one, we also run some tools directly.
>> >
>> > I think we could find a way to make Buildr less resilient on Java. I
>> wrote
>> > an experimental compiler that relies on an external javac recently here:
>> >
>> >
>> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
>> >
>> > This compiler helps me as I need to use a different JDK for part of the
>> > projects I have to compile.
>> >
>> > I think the Java integration of Buildr helps starting the JVM only once
>> - I
>> > also think we could support most scenarios by calling Java over a
>> subshell.
>> > I don't know how much more expensive it would turn out to be but I see
>> it
>> > as
>> > a good option - when RJB breaks, or when JFFI refuses to load, which
>> > happens
>> > all too often.
>> > We know the main problem of Buildr is its installation story. How about
>> we
>> > give a drop and run Buildr gem that just relies on the JVM by calling
>> it,
>> > instead of linking to it ? That would make for less headaches and work
>> > allright on most OSes.
>> >
>> > I would like to make such an implementation - as time permits.
>> >
>> > Please let me know what you think.
>> >
>> > Thanks,
>> >
>> > Antoine
>> >
>>
>
>
Re: Java integration
Posted by Alex Boisvert <al...@gmail.com>.
Personally, I'm still enjoying using MRI more than JRuby. If it wasn't for
installation issues and getting JDK 1.6 working on some machines, I'd be a
completely happy camper.
I think Daniel illustrated well that we need more than exec("java")
functionality to retain the speed and integration we currently have. And
if anything, I want Buildr to have better Java integration, not less, so I
would not want to go to a situation where we have to shell out to "java"
every time something needs to invoke bytecode. I'm happy with using RJB as
lowest common denominator for what should work on Buildr in a standard
sense, and possibly using JRuby for extra features.
And while I'm a big supporter of having a fully supported, all-in-one JRuby
distro, I don't yet see what we would gain from going JRuby-only and
dropping support for MRI. I would be fine making the JRuby distro our
recommended choice on the download page, though, since it would probably
result in better first experience.
alex
On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <dj...@gmail.com>wrote:
> I think we rely on being able to call onto the JVM too much to do this.
> It's not just for compiler invocation. The most creative use (in my
> opinion) is our test class detection, which works by spinning up a
> URLClassLoader and filtering specified .class files for specific attributes
> (such as name or superclass). Of course, as with everything JVM-related
> that we're doing, we could just shell out, but that means we would have to
> eat the cost of JVM startup not once, but several times over the course of
> a
> normal build. There are also tools like Cobertura or the *entire* Groovy
> integration layer which are fairly heavily dependent on Ant. It would be
> annoying and tricky to enable these things through mere shell invocation.
>
> I think the main problem we're trying to solve here is the fact that RJB is
> flaky, difficult to install and causes endless compatibility issues. I
> would much sooner solve this problem by going JRuby-only. I mean, I like
> MRI as much as the next guy (particularly for startup), but JRuby has made
> pretty significant strides here in the most recent release. We could do
> even better if we pre-compiled all of the relevant .rb files and encouraged
> the use of the all-in-one bundle (still supporting gem installations, but
> only on JRuby).
>
> Just to be clear, I'm not exactly a fan of this idea. MRI support offers
> some very nice advantages (like Growl integration, startup time, etc).
> However, if we are seriously looking to get away from RJB, then I think we
> should do it by going to JRuby, rather than ditching JVM integration
> altogether.
>
> Daniel
>
> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <at...@intalio.com>
> wrote:
>
> > Hi guys,
> >
> > I'd like to open a new discussion with Buildr and offer a new insight on
> > Buildr's link to Java.
> >
> > From day one, Buildr was tightly bound to Java. We use either RJB or
> JRuby
> > as the gateway to Java, and we have one common API to discuss with it.
> > We use the Java integration in critical yet well defined operations:
> > compiling is for sure one, we also run some tools directly.
> >
> > I think we could find a way to make Buildr less resilient on Java. I
> wrote
> > an experimental compiler that relies on an external javac recently here:
> >
> >
> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
> >
> > This compiler helps me as I need to use a different JDK for part of the
> > projects I have to compile.
> >
> > I think the Java integration of Buildr helps starting the JVM only once -
> I
> > also think we could support most scenarios by calling Java over a
> subshell.
> > I don't know how much more expensive it would turn out to be but I see it
> > as
> > a good option - when RJB breaks, or when JFFI refuses to load, which
> > happens
> > all too often.
> > We know the main problem of Buildr is its installation story. How about
> we
> > give a drop and run Buildr gem that just relies on the JVM by calling it,
> > instead of linking to it ? That would make for less headaches and work
> > allright on most OSes.
> >
> > I would like to make such an implementation - as time permits.
> >
> > Please let me know what you think.
> >
> > Thanks,
> >
> > Antoine
> >
>
Re: Java integration
Posted by Daniel Spiewak <dj...@gmail.com>.
I think we rely on being able to call onto the JVM too much to do this.
It's not just for compiler invocation. The most creative use (in my
opinion) is our test class detection, which works by spinning up a
URLClassLoader and filtering specified .class files for specific attributes
(such as name or superclass). Of course, as with everything JVM-related
that we're doing, we could just shell out, but that means we would have to
eat the cost of JVM startup not once, but several times over the course of a
normal build. There are also tools like Cobertura or the *entire* Groovy
integration layer which are fairly heavily dependent on Ant. It would be
annoying and tricky to enable these things through mere shell invocation.
I think the main problem we're trying to solve here is the fact that RJB is
flaky, difficult to install and causes endless compatibility issues. I
would much sooner solve this problem by going JRuby-only. I mean, I like
MRI as much as the next guy (particularly for startup), but JRuby has made
pretty significant strides here in the most recent release. We could do
even better if we pre-compiled all of the relevant .rb files and encouraged
the use of the all-in-one bundle (still supporting gem installations, but
only on JRuby).
Just to be clear, I'm not exactly a fan of this idea. MRI support offers
some very nice advantages (like Growl integration, startup time, etc).
However, if we are seriously looking to get away from RJB, then I think we
should do it by going to JRuby, rather than ditching JVM integration
altogether.
Daniel
On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <at...@intalio.com> wrote:
> Hi guys,
>
> I'd like to open a new discussion with Buildr and offer a new insight on
> Buildr's link to Java.
>
> From day one, Buildr was tightly bound to Java. We use either RJB or JRuby
> as the gateway to Java, and we have one common API to discuss with it.
> We use the Java integration in critical yet well defined operations:
> compiling is for sure one, we also run some tools directly.
>
> I think we could find a way to make Buildr less resilient on Java. I wrote
> an experimental compiler that relies on an external javac recently here:
>
> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb
>
> This compiler helps me as I need to use a different JDK for part of the
> projects I have to compile.
>
> I think the Java integration of Buildr helps starting the JVM only once - I
> also think we could support most scenarios by calling Java over a subshell.
> I don't know how much more expensive it would turn out to be but I see it
> as
> a good option - when RJB breaks, or when JFFI refuses to load, which
> happens
> all too often.
> We know the main problem of Buildr is its installation story. How about we
> give a drop and run Buildr gem that just relies on the JVM by calling it,
> instead of linking to it ? That would make for less headaches and work
> allright on most OSes.
>
> I would like to make such an implementation - as time permits.
>
> Please let me know what you think.
>
> Thanks,
>
> Antoine
>
Re: Java integration
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Wouldn't it bee sufficient to add support for the -bootclasspath and -extdirs options? That might not be as convenient as simply calling javac of another installed jdk of course since you would have to puzzle together those two parameters yourself rather than getting the defaults.
Pepijn
On 22 Mar 2010, at 20:25, Antoine Toulme wrote:
> They do - but javax.sql did change in jdk6. Hibernate doesn't implement all
> the right methods with it then.
>
> That's just one example.
>
> I understand that there is no interest in pushing for that effort. I'll make
> a contribution of the external javac compiler, will ask for code review.
>
> Thanks,
>
> Antoine
>
> On Mon, Mar 22, 2010 at 12:19, Charles Oliver Nutter <he...@headius.com>wrote:
>
>> On Sun, Mar 21, 2010 at 2:24 PM, Antoine Toulme <at...@intalio.com>
>> wrote:
>>> This compiler helps me as I need to use a different JDK for part of the
>>> projects I have to compile.
>>
>> Why do you need to do that? All current Java releases support
>> compiling code for older JVMs...
>>
>> ~/projects/jruby ➔ javac 2>&1 | grep release
>> -source <release> Provide source compatibility with specified
>> release
>> -target <release> Generate class files for specific VM version
>>
>> ~/projects/jruby ➔ javac -version
>> javac 1.6.0_17
>>
>> - Charlie
>>
Re: Java integration
Posted by Antoine Toulme <at...@intalio.com>.
They do - but javax.sql did change in jdk6. Hibernate doesn't implement all
the right methods with it then.
That's just one example.
I understand that there is no interest in pushing for that effort. I'll make
a contribution of the external javac compiler, will ask for code review.
Thanks,
Antoine
On Mon, Mar 22, 2010 at 12:19, Charles Oliver Nutter <he...@headius.com>wrote:
> On Sun, Mar 21, 2010 at 2:24 PM, Antoine Toulme <at...@intalio.com>
> wrote:
> > This compiler helps me as I need to use a different JDK for part of the
> > projects I have to compile.
>
> Why do you need to do that? All current Java releases support
> compiling code for older JVMs...
>
> ~/projects/jruby ➔ javac 2>&1 | grep release
> -source <release> Provide source compatibility with specified
> release
> -target <release> Generate class files for specific VM version
>
> ~/projects/jruby ➔ javac -version
> javac 1.6.0_17
>
> - Charlie
>
Re: Java integration
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi,
On Mar 22, 2010, at 2:50 PM, Charles Oliver Nutter wrote:
> Anyway...I understand now why Antoine (and others) might need to build
> with an older JDK. Though I don't understand supporting 1.4 :)
For sure. I ran into that 1.4 issue years and years ago -- it's just
what I point to as the reason when someone asks me why I always try to
compile on the same JDK that I'm deploying on.
Rhett
Re: Java integration
Posted by Charles Oliver Nutter <he...@headius.com>.
On Mon, Mar 22, 2010 at 2:27 PM, Rhett Sutphin
<rh...@detailedbalance.net> wrote:
> I can't speak for Antoine, but I know I've run into problems where code
> compiled on a 1.5 JDK won't run on a 1.4 JRE, even though the source/target
> options are provided. In the specific case I recall, there was change in
> BigDecimal such that if you compiled this code:
>
> new BigDecimal(4)
>
> against 1.5, it would throw a NoSuchMethodError when run on 1.4. The
> problem was that 1.4 only had BigDecimal(double) while 1.5 has
> BigDecimal(int).
>
> Given the backwards-incompatible changes from 1.5 to 1.6 (e.g., in JDBC), I
> wouldn't be surprised if there are similar gotchas in that transition.
Sure, there's library issues like that. It's unfortunate that javac
doesn't do a better job of detecting that you're calling methods only
in a particular version. Perhaps they should introduce (should have
introduced) a @Version annotation so that javac could discount methods
and classes that are only available on particular versions of the JVM.
Anyway...I understand now why Antoine (and others) might need to build
with an older JDK. Though I don't understand supporting 1.4 :)
FWIW, JRuby does not support 1.4, though in theory it could be
retroweaved to do so. We've had almost no interest in that for a
couple years now.
- Charlie
Re: Java integration
Posted by Rhett Sutphin <rh...@detailedbalance.net>.
Hi Charlie,
On Mar 22, 2010, at 2:19 PM, Charles Oliver Nutter wrote:
> On Sun, Mar 21, 2010 at 2:24 PM, Antoine Toulme
> <at...@intalio.com> wrote:
>> This compiler helps me as I need to use a different JDK for part of
>> the
>> projects I have to compile.
>
> Why do you need to do that? All current Java releases support
> compiling code for older JVMs...
>
> ~/projects/jruby ➔ javac 2>&1 | grep release
> -source <release> Provide source compatibility with
> specified release
> -target <release> Generate class files for specific VM
> version
>
> ~/projects/jruby ➔ javac -version
> javac 1.6.0_17
I can't speak for Antoine, but I know I've run into problems where
code compiled on a 1.5 JDK won't run on a 1.4 JRE, even though the
source/target options are provided. In the specific case I recall,
there was change in BigDecimal such that if you compiled this code:
new BigDecimal(4)
against 1.5, it would throw a NoSuchMethodError when run on 1.4. The
problem was that 1.4 only had BigDecimal(double) while 1.5 has
BigDecimal(int).
Given the backwards-incompatible changes from 1.5 to 1.6 (e.g., in
JDBC), I wouldn't be surprised if there are similar gotchas in that
transition.
Rhett
Re: Java integration
Posted by Charles Oliver Nutter <he...@headius.com>.
On Sun, Mar 21, 2010 at 2:24 PM, Antoine Toulme <at...@intalio.com> wrote:
> This compiler helps me as I need to use a different JDK for part of the
> projects I have to compile.
Why do you need to do that? All current Java releases support
compiling code for older JVMs...
~/projects/jruby ➔ javac 2>&1 | grep release
-source <release> Provide source compatibility with specified release
-target <release> Generate class files for specific VM version
~/projects/jruby ➔ javac -version
javac 1.6.0_17
- Charlie