Well,
I'm confused as well. Still not clear, what are we about to solve here.
Use new lang spec with old runtimes? I do not have granny issues...
I usually encounter "problems" with the other directions. I was happily
using java 8 spec, when it turned out that Optional.isEmpty() is only in
Java 11.
The value I see in nb-javac is to be able to support *editing* higher
language specs than NetBeans runtime is using. Code generation for older
runtimes, is not that interesting.
The examples of Java 17 has no support for Java 6 target, makes this
discussion ridiculous.
I kind of like the idea let nb-javac go, not depend more on it. Though
living on the "edge" is often a problem with Gradle, kind of sad, but
understandable. The best of both worlds would be if the javac in each
jdk would be built to be compatible with the previous LTS runtime, so
new javac-s could be used by the IDE directly even if that is running on
a recent LTS. Like now an IDE running on Java 17 would be able to use
the javac directly from Java 19 or 20 ea, without the need of nb-javac.
I know that the download size of a JDK is bigger than the javac itself,
though I'd see totally acceptable if the IDE just downloads Java 19 JDK
in order to develop a Java 19 project, while it is running on Java 17.
Convince me and I support the case! Though, I'm more confused, than
convinced, so far.
On 10/25/22 00:06, Jaroslav Tulach wrote:
JDK `javac` drops support for old `-target` versions. E.g. version 11 can no
longer target 1.5 bytecode:
```
$ /jdk-11/bin/javac -source 1.5 -target 1.5 Hello.java
error: Source option 5 is no longer supported. Use 6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.
```
and such "dropping" constantly continues and happens all the time. For example
JDK-17 cannot target 1.6 anymore:
```
$ /jdk-17/bin/javac -source 1.6 -target 1.6 Hello.java
error: Source option 6 is no longer supported. Use 7 or later.
error: Target option 6 is no longer supported. Use 7 or later.
```
as a consequence one cannot use the latest JDK to build (not so old) versions
of NetBeans. This decay bugs me a lot.
I want to use JDK/JRE as a runtime (newest JDK can still run the 1.0 bytecode
format) and separate compiler from such runtime. Then the world is going to be
a better place.
-jt
Sidenote:
I think Michael Bien answered this: "btw javac has actually a public API, it
won't simply disappear from one release to the other without warning"
NetBeans use of `javac` goes far beyond its public API. I believe there is a
little relevance concluding the important aspects of javac remain based on
existence of some public API.
Dne úterý 25. října 2022 3:16:38 CEST, Eirik Bakke napsal(a):
Right now, when we build NetBeans, we’re using the javac from the JDK that
we’re using to do the build — so that we’re dependent on the JDK team,
which can decide to drop features.
Does the JDK ever drop features? Are we currently dependent on unofficial or
experimental JDK features relating to the official javac?
I think Michael Bien answered this: "btw javac has actually a public API, it
won't simply disappear from one release to the other without warning"
I agree with Michael Bien here:
I would approach this from a different POV and ask why NB requires
nb-javac in the first place, instead of trying to find more stages in the
NB life cycle where we can add it.
Much better to keep NetBeans building with the standard JDK.
-- Eirik
-----Original Message-----
From: Michael Bien <mbie...@gmail.com>
Sent: Monday, October 24, 2022 4:27 PM
To: dev@netbeans.apache.org; Ernie Rael <err...@raelity.com>
Subject: Re: nb-javac for building NetBeans itself
On 24.10.22 22:15, Ernie Rael wrote:
On 22/10/24 8:58 AM, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me.
I'd like to see a more technical discussion.
for me too, I withdrew the -1 vote the moment I realized that this
could qualify as veto since this discussion would fall into the
code-change category.
Luckily withdrawing vetos is legal, which is useful since I didn't
even intend to veto anything :)
And I have to mention one thing that really bugged me: a lot of the
discussion seemed to have the assumption that it's easy for users to
use the latest JDK; I think that's just not accurate (but again
don't have hard data). For me, I have to use Gradle 6.8.x so I can
not use the latest JDK. If it's true in general that many/most users
can not use the latest JDK, that seems like an extremely important
data point.
Yes I heard about this issue. We should take a look if this can be
somehow solved. Its certainly not optimal to be required to change
the runtime JDK of the IDE when switching between projects which use
different gradle versions.
lets try to solve this without nb-gradle if possible.
I only brought that up as an example of a situation where can't use
the latest JDK. I wouldn't be surprised if most users have
restrictions on which JDK can be used and/or targeted.
This doesn't influence the target JDK at all. Java 8 shops don't swap out
the build-in JDK 11 of android studio if they write an app. It is just the
runtime of android studio, it has no other viral effects or influences your
support contracts with specific vendors.
-mbien
best regards,
michael
-ernie
Maybe a straight vote on this is the way forward, and we live with
the consequences either way?!
Best wishes,
Neil
-------------------------------------------------------------------
-- 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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
