On 07.02.23 00:43, Neil C Smith wrote:
On Mon, 6 Feb 2023, 22:22 Michael Bien, <[email protected]> wrote:
What is needed is to communicate that it is ok to upgrade everything to
JDK11 - which would open the flood gates.
Maybe. But do we really want a flood of modules with non-default
configuration?
there is no default configuration for source/target yet - that was just
an idea.
again: if we can do everything in one go -> even better
we can probably set the module manifest to JDK 11 in one go for example
which would be the easy part.
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
In my mind it requires a lazy consensus thread, like the previous one. ie.
A proposal with no vetoes. Vetoes of course being based on technical
arguments or alternative approaches to address the problem.
I'm happy to write something up if no-one else does first. I restarted this
discussion to try and work out what that should look like.
this should be goal of course. Lets move everything to JDK 11 unless it
is used by the platform.
Why do you think the platform should be special cased?
I don't think it necessarily should. But it currently is.
Platform has to run on JDK 8+. IDE runs on JDK 11+ since NB 12.6.
you just wrote:
"a) support running the platform on JDK 8 until NetBeans 19"
-> special case in build, CI etc until NB 19 is out
after that we should sync everything 11. But there is no technical
reason to wait with IDE modules till that date, if someone wants to move
a module for NB 18 it shouldn't be a big deal.
Not a lot would prevent us to require JDK 21 for the IDE once it is out
some time in future (assuming tests work). But I imagine there will be
resistance to do the same for the platform. So the same situation will
likely repeat again.
Platform is a lib, the IDE is a tool/product. The distinction will
likely always cause some friction in runtime requirements.
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.
In many respects I agree. The important part of any statement is runtime
compatibility. However ASF releases sources, so there are some arguments
for good advance communication of build requirements too?
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.
True, but that's what I mean by opt-out vs opt-in. Why not keep the custom
configuration for the edge cases?
opt-ins can be trivially removed with search and replace once the
default is bumped. This shouldn't be the reason to stop an IDE module
from requiring JDK 11 for another year.
We would have to do this anyway since there would be already opt-ins to
remove once we add a default config due to already existing modules
which require JDK 11.
What is your concern?
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.
Good job we have a test for that already then!
it is very rudimentary
https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237
-mbien
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
