On 25.10.22 09:06, Jaroslav Tulach wrote:
JDK `javac` drops support for old `-target` versions. E.g. version 11 can no
longer target 1.5 bytecode:
Java 12 dropped support for target 1.6, Java 20 will drop support for
the javac target 1.7. There are no indications that anyone intends to
drop targets of still supported Java versions.
There is a policy for this which is JEP 182. But please note that this
policy is outdated since it was not written for the new release cycle -
OpenJDK does only follow it in spirit, an update is pending as I
understand it. This QA notification does also mention that fact:
https://inside.java/2022/09/26/quality-heads-up/
If I would feel nostalgic one day and wanted to program the "Java Ring"
I would be perfectly fine with starting NetBeans 5.0 for the full
experience. It doesn't have to be NetBeans 16 for max coding efficiency :)
Not to mention that downgrading nb-javac wouldn't work anyway! Since
NetBeans is written against the current javac API (that was the whole
point of nb-javac), this is a dependency to a 3rd party lib like any
other. If you downgrade it, things will break, enums, methods, classes
are missing. So even if someone would maintain a nb-javac which has
generated from JDK 8 to support everything down to 1.2, NB could not
simply swap it out without also shipping the matching modules of an old
editor.
At this point it would be easier to branch the java cluster into
RetroBeans LTS if there is community interest for java 1.1-1.7.
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.
The problem here is that language and JDK are not developed separately.
This is no accident, since if you double down on it (and OpenJDK did) it
quickly becomes a feature and not a bug (ARM blocks, String Templates..
are API+lang combo features).
If someone wanted to change this, it would have to happen in OpenJDK,
not in an IDE. Producing java 1.1 bytecode with JDK 20 while being able
to use the compiler of JDK 1.1 would be a nice-to-have with no RL
applications. Old JDKs still exist online, they ship with a compiler so
that the whole package can be used as convenient... development kit ;)
Providing a good out-of-the box experience serves the community too. A
student creating her/his first java project would be able to use the
latest JDK (lang+API+runtime) without having to configure anything and
target anything down to the oldest, still supported LTS release of Java.
That is already a huge range for a community maintained project like
NetBeans.
-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.
Yes, that is why its important to have the same version of the javac API
at runtime as the version the NB java editor was written and tested
against. The rudimentary bootstrapper demo I linked does exactly that.
It ensures that the _exact_ version of the JDK which was used in CI
during NB 16's dev cycle, is also used as it's runtime. This is likely
unnecessary strict and could be opened up in a vendor neutral way - I
kept the UI minimal, the bootstrapper would support it already.
But I do also have to mention again, that as someone who usually runs NB
without nb-javac, I never experienced that a JDK minor release update
caused problems in the editor. I am not saying that this is impossible
or that we should risk it, I am only arguing that the dependency to
javac internals is not as restricting as it might seem, since JDK
minor-version update releases fix bugs, they don't add features/types etc.
(as mentioned before, if we have concerns about this particular aspect,
we should consider joining:
https://wiki.openjdk.java.net/display/quality/Quality+Outreach )
best regards,
michael
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
