On 10/03/2016 10:15 AM, Rafael Winterhalter wrote:
[...] However, for the adoption process, I think it is
crucial that non-modularized code behaves as it did before, i.e. that
non-modularized code shows the same behavior when its run on a Java 9 VM.
I agree with the sentiment here however I
Hi Alan,
I just tried to get an overview to answer what you have asked and some of
the internal types being used are for example the specific JMX bean
implementations rather than their interfaces to expose some additional
metrics that someone at customer ops required at some time following the
On 03 Oct 2016, at 13:30, Peter Levart
> wrote:
Use qualified exports?
Which circles back to the discussion that you don't necessarily know at
compile-time which JPA/DI/whatever implementation you're targeting with the
module in a Java EE
Hi Paul,
On 10/03/2016 11:23 AM, Paul Bakker wrote:
I have updated the migration demo that Sander and I showed at JavaOne to
the latest Jigsaw prototype (
https://github.com/sandermak/java9-migration-demos). This is a
Spring/Hibernate application. The goal is to migrate the app's code to a
I have updated the migration demo that Sander and I showed at JavaOne to
the latest Jigsaw prototype (
https://github.com/sandermak/java9-migration-demos). This is a
Spring/Hibernate application. The goal is to migrate the app's code to a
named module, while keeping libraries as automatic modules
On 02/10/2016 18:34, Stephen Felts wrote:
I picked up javassist 3.21 to work around Jigsaw problems on JDK 9. It works
great. The only problem is that it no longer works on JDK 8.
Has anyone seen this problem? Don't you hate it when you can't find
java.lang.String? :)
In a recent mail
Changeset: ddfee9808a34
Author:alanb
Date: 2016-09-30 15:34 +0100
URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddfee9808a34
Update --patch-module to align with module path scanning
! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java
Changeset: a106e5390e5f