[hibernate-dev] Moving Java Forward Faster

[Rory O'Donnell]

Hi Sanne,

Please do share your thoughts on the OpenJDK mailing list.

Rgds,Rory

On 07/09/2017 11:22, Sanne Grinovero wrote:
> Hi Rory,
>
> thank you very much for this heads up! Opening up the build-and-test
> infrastructure and the commercial components sounds like an amazing
> development.
>
> Some early thoughts. The methodology of faster release cycles is very
> welcome, yet the proposed versioning I saw mentioned on twitter to be
> "year based" is a bit puzzling: in our experience it's nice to be able
> to clearly differentiate a non-backwards compatible version from a
> backwards compatible version, and yet be in control of when an
> "incompatibility event" happens: that can't be time boxed as generally
> we all try to avoid it but sometimes innovation requires to.
>
> I guess we could agree that technically no changed software is fully
> backwards compatible from all perspectives, but people are aware of
> this and yet benefit from knowing the maintainer's intent. This seems
> to map to the "long term support" editions but then those LTS versions
> only become the "version" in people's perspective. Specifically my
> concern would be that different versions would be perceived as a
> significant migration risk even though such an update might be
> relatively much simpler than others. It's possible that in practice
> Java 10 already had some breaking changes planned so this concern
> wouldn't apply right now, but with such numbering you'll never be able
> to benefit from it even in future releases.
> I'd welcome faster innovation cycles but libraries like Hibernate
> can't drop support for JVMs still largely in use, so unless people get
> comfortable in adopting new JVM versions by removing any such mental
> barriers we won't be able to adopt new versions as fast as we'd all
> like. On the other hand if the suggestion is that libraries should
> generally target "long term support" platforms, then it becomes
> painfully slow: as in other OSS projects - like Fedora - practical
> needs dictate that you at least support the two latest platforms so
> that would force us to support 6+ years old JVMs and slow innovation
> down rather than speeding it up. (Fedora supports the last two
> releases but a new release appears every 6 months).
>
> We'll think about this in the team and see if it's worth sharing some
> more thoughts on the OpenJDK mailing list.
>
> Regards,
> Sanne
>
>
>
> On 7 September 2017 at 10:35, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
>> Hi Sanne,
>>
>> Oracle is proposing a rapid release model for Java SE going-forward.
>>
>> The high points are highlighted below, details of the changes can be
>> found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].
>>
>> Under the proposed release model, after JDK 9, we will adopt a strict,
>> time-based model with a new major release every six months, update
>> releases every quarter, and a long-term support release every three years.
>>
>> The new JDK Project will run a bit differently than the past "JDK $N"
>> Projects:
>>
>> - The main development line will always be open but fixes, enhancements,
>> and features will be merged only when they're nearly finished. The main
>> line will be Feature Complete [3] at all times.
>>
>> - We'll continue to use the JEP Process [4] for new features and other
>> significant changes. The bar to target a JEP to a specific release will,
>> however, be higher since the work must be Feature Complete in order to
>> go in. Owners of large or risky features will be strongly encouraged to
>> split such features up into smaller and safer parts, to integrate
>> earlier in the release cycle, and to publish separate lines of
>> early-access builds prior to integration.
>>
>> The JDK Updates Project will run in much the same way as the past "JDK
>> $N" Updates Projects, though update releases will be strictly limited to
>> fixes of security issues, regressions, and bugs in newer features.
>>
>> Related to this proposal, we intend to make a few changes in what we do:
>>
>> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to
>> make it easier for developers to deploy Java applications to cloud
>> environments. We'll initially publish OpenJDK builds for Linux/x64,
>> followed later by builds for macOS/x64 and Windows/x64.
>>
>> - We'll continue to ship proprietary "Oracle JDK" builds, which include
>> "commercial features" [6] such as Java Flight Recorder and Mission
>> Control [7], under a click-through binary-code license [8]. Oracle will
>> continue to offer paid support for these builds.
>>
>> - After JDK 9 we'll open-source the commercial features in order to make
>> the OpenJDK builds more attractive to developers and to reduce the
>> differences between those builds and the Oracle JDK. This will take some
>> time, but the ultimate goal is to make OpenJDK and Oracle JDK builds
>> completely interchangeable.
>>
>> - Finally, for the long term we'll work with other OpenJDK contributors
>> to establish an open build-and-test infrastructure. This will make it
>> easier to publish early-access builds for features in development, and
>> eventually make it possible for the OpenJDK Community itself to publish
>> authoritative builds of the JDK.
>>
>> Questions , comments, feedback to OpenJDK discuss mailing list [2]
>>
>> Rgds,Rory
>>
>> [1]https://mreinhold.org/blog/forward-faster
>> [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
>> [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
>> [4]http://openjdk.java.net/jeps/0
>> [5]http://openjdk.java.net/legal/gplv2+ce.html
>> [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html
>> [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
>> [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland