JDK-9 preparation

[pmlopes]

Current dependencies that use jdk internal APIs which won't be visible with Java9

vertx/lib/jna-platform-4.0.0.jar

jna-platform-4.0.0.jar -> java.desktop
   com.sun.jna.platform.WindowUtils$MacWindowUtils$1 (jna-platform-4.0.0.jar)
      -> java.awt.peer.ComponentPeer                        JDK internal API (java.desktop)

vertx/lib/jruby-complete-9.0.1.0.jar

jruby-complete-9.0.1.0.jar -> java.base
jruby-complete-9.0.1.0.jar -> java.management
   org.jruby.management.BeanManagerImpl (jruby-complete-9.0.1.0.jar)
      -> sun.management.Agent                               JDK internal API (java.management)
   org.jruby.util.encoding.ISO_8859_16 (jruby-complete-9.0.1.0.jar)
      -> sun.nio.cs.US_ASCII                                JDK internal API (java.base)

vertx/lib/kryo-2.24.0.jar

kryo-2.24.0.jar -> java.base
   com.esotericsoftware.kryo.io.UnsafeMemoryInput (kryo-2.24.0.jar)
      -> sun.nio.ch.DirectBuffer                            JDK internal API (java.base)
   com.esotericsoftware.kryo.io.UnsafeMemoryOutput (kryo-2.24.0.jar)
      -> sun.nio.ch.DirectBuffer                            JDK internal API (java.base)
   com.esotericsoftware.kryo.util.UnsafeUtil (kryo-2.24.0.jar)
      -> sun.nio.ch.DirectBuffer                            JDK internal API (java.base)

vertx/lib/netty-handler-4.0.33.Final.jar

netty-handler-4.0.33.Final.jar -> java.base
   io.netty.handler.ssl.util.OpenJdkSelfSignedCertGenerator (netty-handler-4.0.33.Final.jar)
      -> sun.security.util.ObjectIdentifier                 JDK internal API (java.base)
      -> sun.security.x509.AlgorithmId                      JDK internal API (java.base)
      -> sun.security.x509.CertificateAlgorithmId           JDK internal API (java.base)
      -> sun.security.x509.CertificateIssuerName            JDK internal API (java.base)
      -> sun.security.x509.CertificateSerialNumber          JDK internal API (java.base)
      -> sun.security.x509.CertificateSubjectName           JDK internal API (java.base)
      -> sun.security.x509.CertificateValidity              JDK internal API (java.base)
      -> sun.security.x509.CertificateVersion               JDK internal API (java.base)
      -> sun.security.x509.CertificateX509Key               JDK internal API (java.base)
      -> sun.security.x509.X500Name                         JDK internal API (java.base)
      -> sun.security.x509.X509CertImpl                     JDK internal API (java.base)
      -> sun.security.x509.X509CertInfo                     JDK internal API (java.base)

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.security.x509.X500Name               Use javax.security.auth.x500.X500Principal @since 1.4

vertx/lib/quasar-core-0.7.3-jdk8.jar

quasar-core-0.7.3-jdk8.jar -> java.management
   co.paralleluniverse.common.util.ProcessUtil (quasar-core-0.7.3-jdk8.jar)
      -> sun.management.VMManagement                        JDK internal API (java.management)

vertx/lib/vertx-stack-manager-3.2.1.jar

vertx-stack-manager-3.2.1.jar -> jdk.compiler
   io.vertx.docgen.BaseProcessor (vertx-stack-manager-3.2.1.jar)
      -> com.sun.tools.javac.code.Symbol                    JDK internal API (jdk.compiler)
      -> com.sun.tools.javac.code.Symbol$ClassSymbol        JDK internal API (jdk.compiler)
   io.vertx.docgen.JavaDocGenProcessor (vertx-stack-manager-3.2.1.jar)
      -> com.sun.tools.javac.code.Type                      JDK internal API (jdk.compiler)

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
com.sun.tools.javac.code.Symbol          Use javax.tools and javax.lang.model @since 1.6
com.sun.tools.javac.code.Symbol$ClassSymbol Use javax.tools and javax.lang.model @since 1.6
com.sun.tools.javac.code.Type            Use javax.tools and javax.lang.model @since 1.6

[cescoffier]

Thanks !

I will fix the stack manager, it's actually a packaging issue (even a bug I would say). It should not embed (shade) the io.vertx.docgen.. packages

[pmlopes]

vertx-docgen-3.3.0-SNAPSHOT.jar

vertx-docgen-3.3.0-SNAPSHOT.jar -> jdk.compiler
   io.vertx.docgen.BaseProcessor (vertx-docgen-3.3.0-SNAPSHOT.jar)
      -> com.sun.tools.javac.code.Symbol                    JDK internal API (jdk.compiler)
      -> com.sun.tools.javac.code.Symbol$ClassSymbol        JDK internal API (jdk.compiler)
   io.vertx.docgen.JavaDocGenProcessor (vertx-docgen-3.3.0-SNAPSHOT.jar)
      -> com.sun.tools.javac.code.Type                      JDK internal API (jdk.compiler)

Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
com.sun.tools.javac.code.Symbol          Use javax.tools and javax.lang.model @since 1.6
com.sun.tools.javac.code.Symbol$ClassSymbol Use javax.tools and javax.lang.model @since 1.6
com.sun.tools.javac.code.Type            Use javax.tools and javax.lang.model @since 1.6

[vietj]

these apis don't have replacement.

however I don't think that's a real problem as it does not impact on runtime, only on compilation.

[paulbakker]

Great to see work is being done on this! While working on the OSGi support I noticed a few "split packages". Split packages are not supported by Java 9 (not in the same layer at least), so this is going to break.
What I found:

• https://github.com/vert-x3/vertx-web/tree/master/vertx-web/src/main/java/io/vertx/ext/web/templ and it's implementations are in the same package