You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by antonio <an...@vieiro.net> on 2022/01/14 07:26:30 UTC
Re: [DISCUSS] Let's require NetBeans to be built with JDK11 was: reviving old thread
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] Let's require NetBeans to be built with JDK11 was: reviving old thread
Posted by Michael Bien <mb...@gmail.com>.
i would always vote for remove/replace if it causes so much dependency
trouble (its "just" a file chooser, right?).
reducing complexity is important, esp for old projects.
-mbien
On 14.01.22 08:26, antonio wrote:
> 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
>
>
>
---------------------------------------------------------------------
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] Let's require NetBeans to be built with JDK11 was: reviving old thread
Posted by Eric Bresie <eb...@gmail.com>.
Not really familiar with the usage or code, but don't suppose
BasicFileChooserUI which is in java.desktop serves a similar purpose does
it?
Eric Bresie
ebresie@gmail.com
On Fri, Jan 14, 2022 at 2:49 PM antonio <an...@vieiro.net> wrote:
> Of course not. Otherwise we'd be using the java.desktop APIs :-).
>
> I believe this dependency with sun.swing and sun.awt internals was
> something that was added to NetBeans long ago [1], possibly to solve
> some bugs in JFileChooser in Windows back then.
>
> Cheers,
> Antonio
>
> [1]
>
> https://github.com/emilianbold/netbeans-releases/commit/33b45cbeada48c2b84bcd3283b8ae2366c0b9600#diff-ed4bc55bdf7e65b31bcff39ddde6083c8bc264946964025515b66a036b7ff007
>
>
> El 14/1/22 a las 20:58, Eric Bresie escribió:
> > Are the needed calls available in the java.desktop [1] module and/or the
> > applicable API associated [2] in it?
>
> ---------------------------------------------------------------------
> 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] Let's require NetBeans to be built with JDK11 was: reviving old thread
Posted by antonio <an...@vieiro.net>.
Of course not. Otherwise we'd be using the java.desktop APIs :-).
I believe this dependency with sun.swing and sun.awt internals was
something that was added to NetBeans long ago [1], possibly to solve
some bugs in JFileChooser in Windows back then.
Cheers,
Antonio
[1]
https://github.com/emilianbold/netbeans-releases/commit/33b45cbeada48c2b84bcd3283b8ae2366c0b9600#diff-ed4bc55bdf7e65b31bcff39ddde6083c8bc264946964025515b66a036b7ff007
El 14/1/22 a las 20:58, Eric Bresie escribió:
> Are the needed calls available in the java.desktop [1] module and/or the
> applicable API associated [2] in it?
---------------------------------------------------------------------
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] Let's require NetBeans to be built with JDK11 was: reviving old thread
Posted by Eric Bresie <eb...@gmail.com>.
I'm sure some of this is a repeat but...
Eric Bresie
ebresie@gmail.com
On Fri, Jan 14, 2022 at 1:26 AM antonio <an...@vieiro.net> wrote:
> 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.
>
Are the needed calls available in the java.desktop [1] module and/or the
applicable API associated [2] in it?
> 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?
>
if I'm not mistaken, I believe that was one of the driving intents of
modularity to move away from internal APIs
From JEP 396 in JDK 16 [3]
-
Encourage developers to migrate from using internal elements to using
standard APIs, so that both they and their users can upgrade without fuss
to future Java releases.
C) Use reflection (and possibly an "--add-opens", note this will have an
> ugly runtime dependency, not a build dependency).
>
Not immediate concern but I believe there are future plans on updates in
reflections [4] so be aware.
There are plenty of resources for migrating out there [5] [6] [7] [10] [11].
Have to be mindful of API deprecation/removals [8], like javax.xml which
was deprecated in Java 9 then removed in Java 11
Tried to document some of these sorts of things here [9]
Cheers
References
[1]
http://cr.openjdk.java.net/~iris/se/10/pfd/java-se-10-pfd-spec-01/api/java.desktop-summary.html
[2]
http://cr.openjdk.java.net/~iris/se/10/pfd/java-se-10-pfd-spec-01/api/java/awt/desktop/package-summary.html
[3] http://openjdk.java.net/jeps/396 JEP 396: Strongly Encapsulate JDK
Internals by Default
[4] https://openjdk.java.net/jeps/416
[5] https://www.infogain.com/blog/java-8-to-11-a-migration-story/
[6]
https://stackoverflow.com/questions/60166816/migrating-java-8-project-to-java-11
[7]
https://medium.com/@daniel.panagio18/first-steps-of-migrating-from-java-8-to-java-11-98ea9a5eafff
[8] https://docs.oracle.com/en/java/javase/11/docs/api/deprecated-list.html
[9] https://issues.apache.org/jira/browse/NETBEANS-5349
[10] https://docs.oracle.com/en/java/javase/11/migrate/index.html
[11] https://docs.oracle.com/javase/9/migrate/toc.htm
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
Re: [DISCUSS] Compiling against internal JDK classes was: Let's require NetBeans to be built with JDK11
Posted by Jaroslav Tulach <ja...@gmail.com>.
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
>
>
>
>