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