On Sun, Jul 30, 2017 at 8:37 AM, Simon Spero <sesunc...@gmail.com> 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" <chtom...@gmail.com> wrote: > > > > On Jul 27, 2017, at 12:53 PM, Gary Gregory <garydgreg...@gmail.com> > 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" <jochen.wiedm...@gmail.com> > 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 <garydgreg...@gmail.com> > >> 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 >
