Hello Antonio, I am changing the title to discuss usage of JDK internals. > 1. Question I: "sun.awt/sun.swing" classes.
I suggest to avoid using the JDK internals as much as possible. E.g. > B) comment/remove this jdk-internal specific features in NetBeans? I'd encouraged you to rather create a pull request for OpenJDK project. Small changes like https://github.com/openjdk/jdk/pull/3939 have a chance to be integrated. Then NetBeans could rely on proper API rather than continue to hack around JDK limitations. -jt pá 14. 1. 2022 v 8:26 odesílatel antonio <anto...@vieiro.net> napsal: > Hi all, > > Regarding the adoption of JDK 11 and the future stragety we want to > follow, I have several questions: > > 1. Question I: "sun.awt/sun.swing" classes. > > We're using sun.awt and sun.swing classes in one "dlight" module we're > receiving in the 4th/5th donation. This is because there is an > implementation of BasicFileChooser for remote systems. These classes are > _not_ exported in the new java.awt.desktop module. > > Do we want to: > > A) continue using these by adding some "--add-exports" to the build > system to gain access to internal module classes? > > B) comment/remove this jdk-internal specific features in NetBeans? > > C) Use reflection (and possibly an "--add-opens", note this will have an > ugly runtime dependency, not a build dependency). > > 2. Question II: Builds depend on the compiler, not the runtime. > > As Jaroslav points out in his email below, we're using Ant's "<available > property/classname" ([2] for reference) in some places [1]. > > This makes the build dependent on the version of our _compiler_, and not > in on the version of our _target runtime_. > > Questions are: > > A) Is this correct? Do we want the build to depend on the version of our > _compiler_? > > B) If not, do we want to add a: > classpath="${nbjdk.bootclasspath}" > property to these "available" Ant task so the build system depends on > the target runtime? > > C) If so, is "nbjdk.bootclasspath" the correct property to use? > "nbjdk.home" instead? Is there any other one? Do we want a new property > "nb.target.jdk"? > > > Any clarifications most welcome! > > Thanks, > Antonio > > > [1] > A not exhaustive list: > > platform/applemenu: > > https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/platform/applemenu/build.xml#L26 > > nbi/engine: > > https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/nbi/engine/build.xml#L74 > > platform/openide.util.enumerations: > > https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/platform/openide.util.enumerations/build.xml#L24 > > ide/db: > > https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/ide/db/build.xml#L30 > > > [2] > https://ant.apache.org/manual/Tasks/available.html > > El 1/10/21 a las 16:44, Jaroslav Tulach escribió: > >> I like this proposal in principle. > >> In case i am missing something - what module would be a candidate for > >> java.target=11 (as example)? > >> > > I see the applemenu module as a really nice example: > > > https://github.com/apache/netbeans/blob/master/platform/applemenu/build.xml#L26 > > it has two implementations of > > > https://github.com/apache/netbeans/blob/master/platform/applemenu/src/org/netbeans/modules/applemenu/NbApplicationAdapter.java > > one is for JDK8 using some external binary Apple classes > > > https://github.com/apache/netbeans/blob/master/platform/applemenu/src/org/netbeans/modules/applemenu/NbApplicationAdapterJDK8.java > > and the second is using official JDK9 API like `java.awt.desktop. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
