On 06.02.23 21:23, Neil C Smith wrote:
On Sun, 5 Feb 2023 at 19:12, Michael Bien <mbie...@gmail.com> wrote:
would be great. The JDK 8 -> 11 step is in many ways "special" since so
much changed between those two LTS releases.
Well, yes, otherwise we might have done this some time ago! :-)
I don't think we have to move everything to JDK 11 at once -
...
We can move modules to JDK 11 incrementally until nothing is left on JDK
8.
Isn't that the status quo?
no it isn't. This is met by very high resistance. We have workarounds in
the maven-indexer space exclusively to keep JDK 8 compatibility and keep
using an EOL lucene lib.
Another (smaller) example was a bugfix i recently reviewed which fixed
java version number parsing and basically replicates an API which is
already in JDK 11 - there too we didn't bump the version.
What is needed is to communicate that it is ok to upgrade everything to
JDK11 - which would open the flood gates. Nobody sets release=8 for the
extra challenge :).
The policy was as far as I remember to be ok with new modules starting
out on JDK 11, old modules have to be discussed before move - that is
too much work since NB has ~450 sub-projects.
Changing this will probably require a vote - I don't know. Users already
know that they have to run on JDK 11+ since this is on the download page
since 12.6 I believe - nothing changes there.
Having a few modules opting in to JDK 11
seems a bit different to moving towards having everything opt-in and
losing the benefits of a default configuration. At some point we
surely need to move the default configuration up to JDK 11?
this should be goal of course. Lets move everything to JDK 11 unless it
is used by the platform.
We don't have to make this a hard rule. I would move to the next LTS as
soon it makes sense and we are actually able to do it. Once this works
we can make a rule out of it :)
Who said "hard rule"? Our release schedule and process (which this
ties into) was agreed to try and provide consistency and clarity for
ourselves and users. But it's iterated multiple times since. Part of
the thoughts on this are because OpenJDK iterated its release and
support schedule. Having some principle that we can agree and can
advertise to end users, particularly platform and plugin developers,
has benefit.
Let me reword the suggestion a little - the only two hard guarantees would be to
- a) support running the platform on JDK 8 until NetBeans 19
- b) to commit to supporting building and running on JDK 11 until (at
least?) NetBeans 22 / May 2024
b) should leave room for exceptions though as long the modules are
optional and give convincing reasons to require JDKs >11. (gave an
example before, e.g: JakartaEE 11 targeting JDK 21)
I don't think a forward looking statement regarding building
requirements of the IDE is needed tbh. If its left out we don't have to
define exceptions.
We don't need to commit to raising the bytecode version straight away,
true, just it becomes an option at that point - we could also have a
soft requirement as now.
right
i was hoping to be able to implement one 'release' property in the build
which would define the default bytecode level for everything and remove
the source/target properties everywhere. Modules would only define a
'release' version if they want to break that convention.
Yes, saw that and totally agree. Isn't that an argument for not
taking the opt-in approach above though?
if it works we can do it all at once. I am just a bit skeptical that it
will "just work" given how many edge cases and custom javac calls the
build has to deal with.
No reason not to try. This is also one of the more time consuming tasks.
Since you have to run a full build and then check via a script that none
of the class files suddenly starts having their version set to 65.
The beauty of custom ant builds (I am kidding).
We should also consider a dialog for NB 18 which warns users if they try
to run NB on JDK 8 - we still don't have that dialog, I somehow keep
forgetting about it and only get reminded again while reading the issue
tracker during the RC phase.
You and me both! :-) I'm almost thinking it might not be worth it -
depends how we approach in future and whether it has re-use.
well. I have a demo somewhere which downloads a runtime JDK into the
netbeans folder if the version isn't right :)
best regards,
michael
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
