Unfortunately due to https://issues.apache.org/jira/browse/NETBEANS-6273 we
still need to start NetBeans 12.3 and above on JDK 1.8 due to keyboard
mapping issues. With 12.2 and lower this issue is not present.

On Fri, 1 Oct 2021 at 16:28, Jaroslav Tulach <jaroslav.tul...@gmail.com>
wrote:

> 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 <jaroslav.tul...@gmail.com>
> 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
> > ebre...@gmail.com
>

Reply via email to