The next message I found in the February thread is this reply to Matthias. I have even written a [blog post]( http://wiki.apidesign.org/wiki/AlternativeImplementation) at that time! ----
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 pá 1. 10. 2021 v 8:27 odesílatel Jaroslav Tulach <[email protected]> napsal: > JDK17 is out and Geertjan told me the old request is going to appear > again. Let me thus review an old thread from November/February... > > ---------- Forwarded message --------- > From: Jaroslav Tulach <[email protected]> > Date: Feb 9 2021 > > Hi. > I knew the time for a discussion like this is going to come when I wrote > my > "Compile with JDK-11 javac --release flag" in November. I have just been > trying > to find the email in archives, but no luck! I had to resend it. Here is it > for > your reference: > > https://lists.apache.org/thread.html/ > r94d421ce16f609687c769125425b46f2322033879120b00afddbe17b%40% > 3Cdev.netbeans.apache.org%3E > > I guess I have to agree with Eric, we cannot stick with JDK8 forever. We > have > to move on. On the other hand, as you know, I am not fan of [Big Bang > changes] > (http://wiki.apidesign.org/wiki/Big_Bang), as such I'd like to propose to > move > forward step by step: > > Let's require JDK11 to build NetBeans sources. > > The switch to JDK11 compiler doesn't mean I suggest to drop running on > JDK8. > Me, my employer/gang, OracleLabs, still need to run VSNetBeans on JDK8. > However we can have it and still move our source code base forward where > needed. > > Matthias wrote: > > I think Jaroslav, said, that in the old time, NetBeans was > > able to be run on JDK-1. I remember that also, but at some point in the > > 8? cycle build requirements jumped to 8, while target version was still > > 1.7. > > Yes, that used to be the policy. Even if we restrict the policy to LTS > versions of Java, JDK17 is near and we have to move forward. As such I > wanted > to discuss this issue in November, 2020. I am still puzzled to understand > where did my email disappear... > > Btw. there is `nb-javac` for JDK8 - related work I am involved in: > https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac > This week we managed to make the (automatic) conversion of JDK16's javac > to > run on JDK8 and pass all the available tests. > > I really wish NetBeans to continue to run on JDK8, but I am ready to do my > best to allow you to use the latest Java APIs and features where needed. I > hope we find a balance between these two desires by going step by step. > > As such I repeat my suggestion: let's require JDK11 to build NetBeans: > https://lists.apache.org/thread.html/ > r94d421ce16f609687c769125425b46f2322033879120b00afddbe17b%40% > 3Cdev.netbeans.apache.org%3E > > > -jt > > > > > > > > Dne pátek 5. února 2021 16:12:10 CET, Eric Bresie napsal(a): > > Question on the Netbeans project's plan for moving forward towards > > introducing and utilizing features with newer Java versions. > > > > I understand the basic expectations at present are mainly build on Java > 8, > > while being possible to build (with applicable flags or jdk settings) for > > newer java versions. > > > > At what point do we need to take the plunge and start actually using some > > of the new features for Java 9 and beyond? > > > > When compiling with new java, I see > > > > 1. references to deprecated or removed interfaces so assume that is > one > > thing that would have to be addressed. > > 2. I see references to "source versions" (I saw one expecting server > > version 1.4) which also show up. As I understand it, at some point > the > > general behavior in some of that will be to only support a few jdk > > version back so assume this might be a case for other needed changes > [what > > makes it a specific version and is it as simple as changing the source > > version in the project details or build scripts]? > > > > Assume doing so would require changes like > > > > 1. Any "JDK" specific build details might have to be addressed > > 2. Address depreciation and source version differences > > 3. Find existing code which are candidates for refactoring with newer > > java features involved > > 4. Maybe leverage some JDK tools or utilizing netbeans Java > "refactoring > > hints" for suggestions (i.e. changing loops to lambdas, utilized newer > > file interfaces, etc.) > > 5. Any dependency libraries would have to be updated with compatible > > versions. This does have the added benefit of utilizing newer > versions > > in these as well which may include performance, security, or bug fits > > benefits as well. > > 6. Update any documentation (i.e. build/runtime environments) > > > > Given the recent javadocs build issues requiring newer jdk, it may mean > the > > time is coming sooner rather than later. > > > > I know this would be a major bit of work but I wanted to raise the > question. > > > > Eric Bresie > > [email protected] > > > > >
