Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)

Simon Spero
Class file format is not treated as a breaking change under most versioning
approaches, including the JLS.

The  checkers I looked at that reported on class file format   changes
consider it a micro level version change (+0.0.1)

The past few major version bumps for projects I've worked happened to
coincide with Java version bumps, but they involved major uses of new
features like annotations / try-with-resources / lambda + streams.

These changes were of necessity Major, since there was no default method
support until 8.

Now... MRJARs ( http://openjdk.java.net/jeps/238 )
TL;DR; MRJARs are a mess. Temperature to be determined.

With Java 9, there is now technically the capability to have multiple
versions of classes, targeting  different language levels,  in the same jar
file. This was supposed to be back ported to 8, but that got lost along the
way, so currently it's only usable for 9/ <9.
There's only minimal support at the tool level (threads with maven / gradle
 samples, with authors' apologies :).

There's also no easy way to write code with conditional compilation blocks
(e.g. in jdk9 there's a new interface method in added to j.u.zip.Checksum
that is pulled up from CRC32; there's no easy way to write source  code to
use the method when compiling for jdk 9 but do  instanceof CRC32 / call
virtual if jdk8. Templates or CPP are less than ideal (see ByteBuffer and
friends).

There are some places in commons where a JDK 9 library addition is
important. For example, codec has a CRC32C implementation, and now so does
jdk 9; both are pure Java slice-by-eight... except the jdk version has
annotations marking critical methods as hotspot intrinsic candidates, which
means that on most major machines the Java code will be ignored in favor of
hardware supported carryless multiplication if available.

Coding for multi release jars is something that might be worth developing
code & policies for; some of this waiting on  maven plugin  changes, but
arranging source trees, minimizing copy & paste,  and making sure that the
right tests are run in the right environments is more awkward (e.g. do
some/all unit tests now have to run after package, as if they were
integration tests? Are tests multi-versioned? ).

And returning to the original topic, what should happen to version numbers
if the Java 9 class  needs a minor version bump, but the Java < 9 version
doesn't.


On Jul 28, 2017 8:41 AM, "Rob Tompkins" <[hidden email]> wrote:


> On Jul 27, 2017, at 12:53 PM, Gary Gregory <[hidden email]> wrote:
>
> We have not in the past forced a major version and Maven coordinate change
> when updating the Java platform. We could do that of course.

I’m a tad surprised by this. It feels like updating the minimum
accommodated java version would necessitate a major version change.

-Rob

>
> Gary
>
> On Jul 27, 2017 06:47, "Jochen Wiedmann" <[hidden email]>
wrote:

>
>> Wouldn't that make it 5.0? (Binary incompatible change)
>>
>> Note: I am not opposing the change, I just propose an additional
>> change in the version number.
>>
>> Jochen
>>
>>
>> On Wed, Jul 26, 2017 at 12:18 AM, Gary Gregory <[hidden email]>
>> wrote:
>>> Hi All:
>>>
>>> I propose we make Java 7 the minimum for Commons Collection 4.2.
>>>
>>> Gary
>>
>>
>>
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/
>> evolution-of-the-wheel-300x85.jpg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)

garydgregory
On Sun, Jul 30, 2017 at 8:37 AM, Simon Spero <[hidden email]> wrote:

> Class file format is not treated as a breaking change under most versioning
> approaches, including the JLS.
>
> The  checkers I looked at that reported on class file format   changes
> consider it a micro level version change (+0.0.1)
>
> The past few major version bumps for projects I've worked happened to
> coincide with Java version bumps, but they involved major uses of new
> features like annotations / try-with-resources / lambda + streams.
>
> These changes were of necessity Major, since there was no default method
> support until 8.
>
> Now... MRJARs ( http://openjdk.java.net/jeps/238 )
> TL;DR; MRJARs are a mess. Temperature to be determined.
>

Agreed. For me, for now, PASS. We've dealt with MR-JARs over at Log4j and
it makes a mess in tooling and IDEs.

Gary

>
> With Java 9, there is now technically the capability to have multiple
> versions of classes, targeting  different language levels,  in the same jar
> file. This was supposed to be back ported to 8, but that got lost along the
> way, so currently it's only usable for 9/ <9.
> There's only minimal support at the tool level (threads with maven / gradle
>  samples, with authors' apologies :).
>
> There's also no easy way to write code with conditional compilation blocks
> (e.g. in jdk9 there's a new interface method in added to j.u.zip.Checksum
> that is pulled up from CRC32; there's no easy way to write source  code to
> use the method when compiling for jdk 9 but do  instanceof CRC32 / call
> virtual if jdk8. Templates or CPP are less than ideal (see ByteBuffer and
> friends).
>
> There are some places in commons where a JDK 9 library addition is
> important. For example, codec has a CRC32C implementation, and now so does
> jdk 9; both are pure Java slice-by-eight... except the jdk version has
> annotations marking critical methods as hotspot intrinsic candidates, which
> means that on most major machines the Java code will be ignored in favor of
> hardware supported carryless multiplication if available.
>
> Coding for multi release jars is something that might be worth developing
> code & policies for; some of this waiting on  maven plugin  changes, but
> arranging source trees, minimizing copy & paste,  and making sure that the
> right tests are run in the right environments is more awkward (e.g. do
> some/all unit tests now have to run after package, as if they were
> integration tests? Are tests multi-versioned? ).
>
> And returning to the original topic, what should happen to version numbers
> if the Java 9 class  needs a minor version bump, but the Java < 9 version
> doesn't.
>
>
> On Jul 28, 2017 8:41 AM, "Rob Tompkins" <[hidden email]> wrote:
>
>
> > On Jul 27, 2017, at 12:53 PM, Gary Gregory <[hidden email]>
> wrote:
> >
> > We have not in the past forced a major version and Maven coordinate
> change
> > when updating the Java platform. We could do that of course.
>
> I’m a tad surprised by this. It feels like updating the minimum
> accommodated java version would necessitate a major version change.
>
> -Rob
>
> >
> > Gary
> >
> > On Jul 27, 2017 06:47, "Jochen Wiedmann" <[hidden email]>
> wrote:
> >
> >> Wouldn't that make it 5.0? (Binary incompatible change)
> >>
> >> Note: I am not opposing the change, I just propose an additional
> >> change in the version number.
> >>
> >> Jochen
> >>
> >>
> >> On Wed, Jul 26, 2017 at 12:18 AM, Gary Gregory <[hidden email]>
> >> wrote:
> >>> Hi All:
> >>>
> >>> I propose we make Java 7 the minimum for Commons Collection 4.2.
> >>>
> >>> Gary
> >>
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/
> >> evolution-of-the-wheel-300x85.jpg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Loading...