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

[Gary Gregory]

On Sun, Jul 30, 2017 at 8:37 AM, Simon Spero  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"  wrote:
>
>
> > On Jul 27, 2017, at 12:53 PM, Gary Gregory 
> 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" 
> 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 
> >> 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: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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"  wrote:


> On Jul 27, 2017, at 12:53 PM, Gary Gregory  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" 
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 
>> 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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Gary Gregory]

On Fri, Jul 28, 2017 at 5:40 AM, Rob Tompkins  wrote:

>
> > On Jul 27, 2017, at 12:53 PM, Gary Gregory 
> 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.
>

It does not.

If we want to break Binary Compatibility (BC), then we update the major
version, the package name (commons-lang -> commons-lang3), and the Maven
Coordinates (commons-lang -> commons-lang3). At that point, if the group ID
is not org.apache.commons, then we update that too.

In the past, BC has always meant API BC, not byte code level compatibility
(it's confusing that both acronyms are BC.) In some cases, we have broken
source-level compatibility without a major version changes.

Gary


>
> -Rob
>
> >
> > Gary
> >
> > On Jul 27, 2017 06:47, "Jochen Wiedmann" 
> 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 
> >> 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: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [collections][proposal] Java 7

[Rob Tompkins]

> On Jul 27, 2017, at 12:53 PM, Gary Gregory  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"  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 
>> 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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Gary Gregory]

git master is now Java 7.

Gary

On Thu, Jul 27, 2017 at 9:53 AM, Gary Gregory 
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.
>
> Gary
>
> On Jul 27, 2017 06:47, "Jochen Wiedmann" 
> 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 
>> 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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [collections][proposal] Java 7

[Gary Gregory]

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.

Gary

On Jul 27, 2017 06:47, "Jochen Wiedmann"  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 
> 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [collections][proposal] Java 7

[Matt Benson]

I think Jochen is correct wrt the major version bump. But that gets me
thinking: what did Java 7 bring that is of any particular relevance
for [collections]? Wouldn't it present a much larger opportunity to
make the jump to Java 8?

Matt

On Thu, Jul 27, 2017 at 8:47 AM, Jochen Wiedmann
 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  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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Jochen Wiedmann]

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  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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Claude Warren]

+1 -- time to move forward

On Wed, Jul 26, 2017 at 1:23 PM, Dave Brosius 
wrote:

> +1
>
>
> On 07/25/2017 06:18 PM, Gary Gregory wrote:
>
>> Hi All:
>>
>> I propose we make Java 7 the minimum for Commons Collection 4.2.
>>
>> Gary
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [collections][proposal] Java 7

[Dave Brosius]

+1


On 07/25/2017 06:18 PM, Gary Gregory wrote:

Hi All:

I propose we make Java 7 the minimum for Commons Collection 4.2.

Gary




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Dave Brosius]

+1


On 07/25/2017 06:18 PM, Gary Gregory wrote:

Hi All:

I propose we make Java 7 the minimum for Commons Collection 4.2.

Gary




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [collections][proposal] Java 7

[Benedikt Ritter]

Go for it!

Amey Jadiye  schrieb am Mi. 26. Juli 2017 um 05:33:

> +1
>
> Regards,
> Amey
>
> On Wed, Jul 26, 2017, 3:48 AM Gary Gregory  wrote:
>
> > Hi All:
> >
> > I propose we make Java 7 the minimum for Commons Collection 4.2.
> >
> > Gary
> >
>

Re: [collections][proposal] Java 7

[Amey Jadiye]

+1

Regards,
Amey

On Wed, Jul 26, 2017, 3:48 AM Gary Gregory  wrote:

> Hi All:
>
> I propose we make Java 7 the minimum for Commons Collection 4.2.
>
> Gary
>

[collections][proposal] Java 7

[Gary Gregory]

Hi All:

I propose we make Java 7 the minimum for Commons Collection 4.2.

Gary