Thanks Matthias, yes, using JDK-11 APIs is obviously one of the next steps:
> We should just be prepared, when the > first version bumps for release to 11 are requested :-). It is obviously possible to do that with reflection the way you describe below. However my preferred way is to use http://wiki.apidesign.org/wiki/AlternativeImplementation E.g. slowly start introducing `org.netbeans.modules.xyz.jdk11` modules that would register "seams" and spice the default JDK8 behavior on JDK11 with additional functionality without the need for reflection. By setting `java.target=11` in `project.properties` file one instructs the NetBeans Harness build system to insert OpenIDE-Module-Java-Dependencies: Java > 11 into module manifest. Then such module is only going to be enabled on JDK11. -jt Dne neděle 14. února 2021 16:24:37 CET, Matthias Bläsing napsal(a): > Hi Jaroslav, > > I like the general idea. Using release where possible should give us a > higher ensurance not to create unusable builds. > > I can imaging where it might be interesting to build a class file for > an older bytecode level, but still against a current API: If the usage > of the new API is propertly behind version checks, then the module > could use newer API on newer JDKs, but retain compatibility with older > JDKs. Having said this, I also thing this is a corner case and if > necessary we can still switch over. If I also remember correctly, > MethodHandles should give us room to implement reflection like access > with the speed of bytecode invocation, so it might not even be worth > it. > > > I also think requiring JDK 9+ to compile NetBeans (effectively meaning > 11) is ok at this point in time. We should just be prepared, when the > first version bumps for release to 11 are requested :-). > > Greetings > > Matthias > > Am Dienstag, den 09.02.2021, 19:58 +0100 schrieb Jaroslav Tulach: > > Has anyone seen this email? I haven't received any replies and I cannot > > find it in the mailing list archive... > > -jt > > > > Sent on Nov 28, 2020: > > > Hi. > > > The release is successfully over, long live the next release! > > > > > > Since the [failure of modern > > > code](https://github.com/apache/netbeans/pull/ > > > 2369) experiment, I can't stop thinking about the enormous possibilities > > > NetBeans project could get by adopting `--release` flag of `javac`. > > > There > > > has been numerous voices calling for "coding against never JDK" and > > > that's > > > what the `--release` flag and the nature of [NetBeans Runtime > > > Container](http:// wiki.apidesign.org/wiki/NetBeans_Runtime_Container) > > > allows us to do. However, let's start with the basics: > > > > > > Let's enable usage of `--release` in our Ant Javac task and let's make > > > it > > > the same as the `javac.target` value: > > > > > > ```diff > > > --- a/nbbuild/antsrc/org/netbeans/nbbuild/CustomJavac.java > > > +++ b/nbbuild/antsrc/org/netbeans/nbbuild/CustomJavac.java > > > @@ -66,6 +66,11 @@ > > > > > > @Override > > > public void execute() throws BuildException { > > > + String tgr = getTarget(); > > > + if (tgr.matches("\\d+")) { > > > + tgr = "1." + tgr; > > > + } > > > + setRelease(tgr.substring(2)); > > > String src = getSource(); > > > if (src.matches("\\d+")) { > > > src = "1." + src; > > > ``` > > > > > > That immediately shows errors in our code base. Just compile with JDK-11 > > > and you'll see errors like: > > > > > > ```bash > > > [nb-javac] Compiling 8 source files to > > > /netbeans/platform/queries/build/ > > > classes > > > [nb-javac] Ignoring source, target and bootclasspath as release has > > > been > > > set [repeat] warning: [options] source value 6 is obsolete and will be > > > removed in a future release > > > [repeat] warning: [options] target value 1.6 is obsolete and will be > > > removed in a future release > > > [repeat] warning: [options] To suppress warnings about obsolete > > > options, > > > use -Xlint:-options. > > > [repeat] /netbeans/platform/queries/src/org/netbeans/api/queries/ > > > VersioningQuery.java:52: error: cannot find symbol > > > [repeat] java.util.Objects.requireNonNull(uri); > > > [repeat] ^ > > > [repeat] symbol: class Objects > > > [repeat] location: package java.util > > > [repeat] 1 error > > > [repeat] 3 warnings > > > [nbmerge] Failed to build target: all-queries > > > ``` > > > > > > What's the problem? In spite our code sets the `javac.target=1.6`, it is > > > using API which isn't present in JDK6. That's wrong. Let's fix that! > > > > > > We need a Travis job using JDK-11 to compile (JDK8 doesn't support the > > > `-- > > > release` flag and Ant javac task just ignores it) and then we need us to > > > fix all the compilation issues found. > > > > > > If the change is done properly (and the `--release` flag is used at all > > > compilations), we can drop the requirement to use JDK8 to compile Apache > > > NetBeans. Yet the code will still run on JDK8 thanks to using `--release > > > 8` > > > or older. How does that sound? > > > > > > Jaroslav Tulach > > > NetBeans Platform Architect > > > > --------------------------------------------------------------------- > > 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 > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- 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
