You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2022/01/15 05:03:26 UTC

Re: [DISCUSS] Compiling against internal JDK classes was: Let's require NetBeans to be built with JDK11

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 <an...@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [DISCUSS] Compiling against internal JDK classes was: Let's require NetBeans to be built with JDK11

Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,

Am Samstag, dem 15.01.2022 um 06:03 +0100 schrieb Jaroslav Tulach:
> 
> 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.

we already have the necessary "--add-opens" declarations in place
AWT/Swing is not an area with a lot "lets just remove some classes"
cases. The code from my perspective is mostly set in stone and so save
to use.

Trying to get fixes into the JDK is a noble goal, but not helpful here.
We compile against JDK 11 and test on JDK 8, so newer API are just out.
Until we acknowledge, that people have to use a recent JDK, we have to
fix situations on our side.

Greetings

Matthias


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists