On 12. 04. 23 6:04, László Kishalmi wrote:
Well, your proposal is actually putting additional work both on who wants
to move forward and who wants to support Java 8 runtime. Also how would it
look like wne Java 17, 21 would be the base? I would like to avoid having
codes in the ide like this one:
https://github.com/apache/netbeans/blob/7f8dfdeb60ce3bec5554fc19ddb40fac0388d885/extide/gradle/netbeans-gradle-tooling/src/main/java/org/netbeans/modules/gradle/tooling/NbProjectInfoBuilder.java#L1090

Disclaimer: not advocating ob the vote result or the voted-on questions, just reacting to a specific technical issue.

I am sure this can be done more gratitiously. For example, if we make a chain of processors, that declare themselves to be usable for a version range, to process several 'well known' entities to Map info that is then merged ... ... it could look a way better and the "old" processors (if we talk about NB modular code in general, not the gradle plugin) could be even separated to optional modules that won't be distributed by default. I've already thought about something along those lines with the gradle plugin, but it did not seem that important. The fathest in that direction was the GradleInternalAdapter.Gradle76().

But it requires some degree of cooperation, which seem to be rejected upfront.

Even code beautification, like (for example) using JDK 9+ java.util.Map.of() can be accommodated (you know, we have bytecode patching classloaders, that can do a lot of magic, like diverting the code to an utility method shipped with NB) - again all the magic separated into modules that need not load in the first place (similar to unless you run an old module, filesystem-compat8 won't load), or even distributed with the standard binary.

But again, that assumes some degree of honest cooperation/respect from the progressive majority - but given the past communication, throwing obstacles in the way could easily happen, manifested in declaring the effort "DeadBeans" by a PMC member.

What's funny is that similar tricks could allow us to modernize the *source code* to the newest supported JDK (LTS) while gracefuly degrading for the rest of supported JDKs (yes, without the hated Frgaal), whatever LTS-1 or LTS-2 policy is in the place. But it's too easy and self-pleasing to just laugh.

-S.


---------------------------------------------------------------------
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



Reply via email to