InternalAPIsUnavailableInJava9

(Difference between revisions)
m (Created page with '=Internal JDK APIs Unavailable In Java 9= With Java 9 comming we have to prepare for several big changes which will affect NetBeans and might break the code. One such change is t…')
m
Line 1: Line 1:
=Internal JDK APIs Unavailable In Java 9=
=Internal JDK APIs Unavailable In Java 9=
-
With Java 9 comming we have to prepare for several big changes which will affect NetBeans and might break the code. One such change is that bunch of internal APIs from JDK 8 and older will become really JDK internal one and will not be accessible from NetBeans. We have to therefore replace these APIs with new one. This document serves for tracking NetBeans packages which are affected, list some already published replacement/workarounds. We will use to make sure NetBeans version supposed to be running on Java 9 will be ready on time re API usage.
+
With Java 9 coming we have to prepare for several big changes which will affect NetBeans and might break the code.  
 +
One such change is that bunch of internal APIs from JDK 8 and older will become really JDK internal and will not be accessible from NetBeans. We have to therefore replace these APIs with new one. This document serves for tracking NetBeans packages which are affected, list some already published replacement/workarounds. We will use this doc to make sure NetBeans version supposed to be running on Java 9 will be ready on time re API usage.
==jdeps tool==
==jdeps tool==
-
We used [[https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool|jdeps tool]] to search for what Java internal APIs we are using. It lists also some examples what internal API can be replaced by supported public API.
+
We used [https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool| jdeps tool] to search for what Java internal APIs we are using. It lists also some [https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool| examples] how to replace obsolete internal APIs with new public ones.
==sun.* packages==
==sun.* packages==
-
These will be Java private one and will not be accessible from within NetBeans sources here is the list of NetBeans modules and what sun.* packages were found.
+
APIs under sun.* will be Java private one and will not be accessible from within NetBeans sources. Here is the list of NetBeans modules and what sun.* packages were found.
{|- border="1"
{|- border="1"
! NetBeans module
! NetBeans module
Line 122: Line 123:
| sun.misc.SharedSecrets, sun.misc.ClassLoaderUtil
| sun.misc.SharedSecrets, sun.misc.ClassLoaderUtil
|}
|}
 +
 +
==com.sun.* packages==
 +
Some packages from com.sun will become public API in Java 9. These are:
 +
* com.sun.source.*
 +
* com.sun.jdi
 +
* com.sun.tools.javac.* is exported, subpackages will be internal
 +
 +
As the source of intermediate info about what packages will be exported from Java 9 you can refer to [http://hg.openjdk.java.net/jdk9/dev/file/tip/modules.xml| modules.xml] for Java 9 modules being API. This info/mechanism can change (modules.xml can be replaced by something different) once Java 9 implementation proceeds further to Feature complete and release.
 +
Following table lists NetBeans modules which utilizes com.sun.* internal APIs which will be internal in Java 9. com.sun.source usage and com.sun.jdi usage were removed from this list.
 +
{|- border="1"
 +
! NetBeans module
 +
! Java API
 +
|-
 +
|javacard.*
 +
|com.sun.javacard.*
 +
|-
 +
|jconsole
 +
|com.sun.jmx.*
 +
|-
 +
|web.el
 +
|com.sun.el.parser.*
 +
|-
 +
|web.jsf.editor
 +
|com.sun.faces.*
 +
|-
 +
|websvc.*
 +
|com.sun.tools.ws.*, com.sun.xml.ws.*, com.sun.xml.rpc.*
 +
|-
 +
|java.source
 +
| com.sun.tools.javac.* (only this package exported, subpackages are not)
 +
|-
 +
|lib.nbjavac
 +
| com.sun.tools.javac.*
 +
|-
 +
|debugger.jpda.visual
 +
|com.sun.media.jfxmedia.*
 +
|-
 +
|apisupport.feedreader
 +
|com.sun.syndication.*
 +
|-
 +
|debugger.jpda.visual
 +
|com.sun.javafx.runtime.*
 +
|-
 +
|core.browser.webview
 +
|com.sun.javafx.scene.web.Debugger
 +
|-
 +
|-debugger.jpda.visual
 +
| com.sun.javafx.tk.*
 +
|-
 +
|o.n.swing.plaf
 +
|com.sun.java.swing.plaf.gtk.GTKLookAndFeel, com.sun.java.swing.plaf.windows.WindowsLookAndFeel
 +
|-
 +
|o.n.bootstrap
 +
| com.sun.jnlp.JNLPClassLoader
 +
|-
 +
|core.startup
 +
| com.sun.java.swing.plaf.gtk.GTKLookAndFeel, com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel, com.sun.java.swing.plaf.windows.WindowsLookAndFeel
 +
|-
 +
|identity.profile.api
 +
| com.sun.identity.*
 +
|-
 +
| cnd.modelimpl
 +
| com.sun.org.apache.xerces.*, com.sun.org.apache.xml.*
 +
|-
 +
| deployment.deviceanywhere
 +
|com.sun.xml.stream.ZephyrParserFactory
 +
|}
 +
 +
==Reflection==
 +
It should be be possible to use reflection to call Java internal APIs even after module boundaries will be in place. It will be likely necessary to call '''setAccessible(true)''' for elements which needs to be called via reflection. At this moment it is not 100% confirmed it will work this way or setAccessible(true) will be needed.

Revision as of 12:37, 15 May 2015

Contents

Internal JDK APIs Unavailable In Java 9

With Java 9 coming we have to prepare for several big changes which will affect NetBeans and might break the code. One such change is that bunch of internal APIs from JDK 8 and older will become really JDK internal and will not be accessible from NetBeans. We have to therefore replace these APIs with new one. This document serves for tracking NetBeans packages which are affected, list some already published replacement/workarounds. We will use this doc to make sure NetBeans version supposed to be running on Java 9 will be ready on time re API usage.

jdeps tool

We used jdeps tool to search for what Java internal APIs we are using. It lists also some examples how to replace obsolete internal APIs with new public ones.

sun.* packages

APIs under sun.* will be Java private one and will not be accessible from within NetBeans sources. Here is the list of NetBeans modules and what sun.* packages were found.

NetBeans module Java API
debugger.jpda sun.reflect.ReflectionFactory
dlight.remote sun.awt.shell.ShellFolder
dlight.remote sun.swing.FilePane
glassfish.common sun.misc.BASE64Encoder
jconsole sun.jvmstat.monitor.*
jconsole sun.management.ConnectorAddressLink
kenai sun.misc.BASE64Encoder
lib.profiler sun.jvmstat.monitor.*
o.n.swing.dirchooser sun.awt.shell.ShellFolder
openide.filesystems sun.security.tools.KeyTool
openide.filesystems sun.security.tools.JarSigner
php.dbgp sun.misc.BASE64Encoder
profiler.heapwalker sun.misc.VM
profiler.snaptracer sun.swing.plaf.synth.SynthIcon
core.network sun.net.spi.DefaultProxySelector
core.network sun.net.NetProperties
core.windows sun.awt.X11.XToolkit, sun.awt.X11.XWM, sun.swing.plaf.synth.SynthIcon
debugger.jpda sun.reflect.DelegatingClassLoader, sun.font.AttributeMap, sun.reflect.ReflectionFactory, sun.awt.X11.XAwtState, sun.awt.X11.XBaseWindow, sun.awt.X11.XToolkit, sun.awt.X11.XAtom
debugger.jpda.visual sun.misc.Launcher$AppClassLoader
dlight.remote sun.swing.WindowsPlacesBar, sun.awt.shell.ShellFolder
editor sun.awt.AppContext
glassfish.common sun.net.NetProperties
groovy.editor sun.boot.class.path
j2me.keystore j2me.keystore
jconsole sun.tools.jconsole.JConsole
lib.profiler.charts sun.swing.SwingUtilities2
o.n.bootstrap sun.awt.AppContext
o.n.swing.dirchooser sun.swing.WindowsPlacesBar, sun.awt.shell.ShellFolder
o.n.swing.plaf sun.swing.plaf.synth.SynthUI
openide.explorer sun.beans.editors.EnumEditor
openide.text sun.awt.im.InputContext, sun.awt.im.InputMethodContext
openide.util sun.awt.AppContext
profiler.oql sun.misc.Ref
sampler sun.management.ThreadInfoCompositeData
spi.editor.hints sun.swing.plaf.synth.SynthIcon
traceio sun.misc.IoTrace
web.jspparser sun.misc.SharedSecrets, sun.misc.ClassLoaderUtil

com.sun.* packages

Some packages from com.sun will become public API in Java 9. These are:

  • com.sun.source.*
  • com.sun.jdi
  • com.sun.tools.javac.* is exported, subpackages will be internal

As the source of intermediate info about what packages will be exported from Java 9 you can refer to modules.xml for Java 9 modules being API. This info/mechanism can change (modules.xml can be replaced by something different) once Java 9 implementation proceeds further to Feature complete and release. Following table lists NetBeans modules which utilizes com.sun.* internal APIs which will be internal in Java 9. com.sun.source usage and com.sun.jdi usage were removed from this list.

NetBeans module Java API
javacard.* com.sun.javacard.*
jconsole com.sun.jmx.*
web.el com.sun.el.parser.*
web.jsf.editor com.sun.faces.*
websvc.* com.sun.tools.ws.*, com.sun.xml.ws.*, com.sun.xml.rpc.*
java.source com.sun.tools.javac.* (only this package exported, subpackages are not)
lib.nbjavac com.sun.tools.javac.*
debugger.jpda.visual com.sun.media.jfxmedia.*
apisupport.feedreader com.sun.syndication.*
debugger.jpda.visual com.sun.javafx.runtime.*
core.browser.webview com.sun.javafx.scene.web.Debugger
com.sun.javafx.tk.*
o.n.swing.plaf com.sun.java.swing.plaf.gtk.GTKLookAndFeel, com.sun.java.swing.plaf.windows.WindowsLookAndFeel
o.n.bootstrap com.sun.jnlp.JNLPClassLoader
core.startup com.sun.java.swing.plaf.gtk.GTKLookAndFeel, com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel, com.sun.java.swing.plaf.windows.WindowsLookAndFeel
identity.profile.api com.sun.identity.*
cnd.modelimpl com.sun.org.apache.xerces.*, com.sun.org.apache.xml.*
deployment.deviceanywhere com.sun.xml.stream.ZephyrParserFactory

Reflection

It should be be possible to use reflection to call Java internal APIs even after module boundaries will be in place. It will be likely necessary to call setAccessible(true) for elements which needs to be called via reflection. At this moment it is not 100% confirmed it will work this way or setAccessible(true) will be needed.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo