jlahoda commented on PR #5609: URL: https://github.com/apache/netbeans/pull/5609#issuecomment-1475327204
> > One advantage of having a firm compiler during build is less dependence on specifics of the compile-time JDK. This might be important if we e.g. wanted to compile some module with `javac.source=19` or `javac.source=20` - currently, that would require upgrading the build JDK to 19/20, and everyone building NB would need to use that. Also, there may be conflict between supported JDKs of Gradle that we use, and the required JDK to build e.g. `javac.source=20` module. > > I think this is an academic discussion. If we can't build with the current JDK, it is a bug that must be fixed. Fixating the compiler will only suppress the pain and when it is finally resolved, it will be painful to fix. We see this in the codebase already: > > * NetBeans forked javac in the past instead of working with upstream to stabilize it and make it usable over multiple java versions. We are still suffering from that failure. > > * NetBeans used an ancient copy of graaljs and maybe even patched this. The two branches got so far apart, that now they have to maintained independently. The initial help of the external codebased turned into a problem. > > > The same will happen, once we introduce a fixed compiler. People will not fix problems with upstream compiler and code will bitrot. We will be forced to use a non-standard javac ad infinitum. I think this is backwards: the compiler would be the up-to-date compiler. So, people would have to deal with any problems, and it would be more difficult to hide from problems related to the compiler. (It might be easier to hide solving non-compiler related problems, though.) > > It is also a bit ironic to speak about `javac.source=20` in the NetBeans codebase. It currently literally takes days to make a module, that can use current APIs (current as in "5 years ago"). The NetBeans codebase targets bytecode, that is 9(!) years old, so sorry, but that argument does not fly with me. I am completely confused here: on purely technical level, I think I can add a optional module with `javac.source=17` quite easily: https://github.com/jlahoda/netbeans/tree/test-module-17 There are, of course, some issues with that, among others: - maybe I would want that module to be usable on older JDKs. Then I probably cannot do it, but this is not a technical problem. - I need to use JDK 17 to build NB from now, and everyone else has to. - (possibly some handwaving around eager modules, which may or may not desirable for a given module) The second point makes it unclear to me how to finalize a change like this - while this should not affect people running the resulting build, it will affect everyone building it, and will require upgrade of the build JDK. How does one do that? Should we simply say that NB builds using the newest JDK only? (The newest JDK at the time of release, or something like this.) Because that's one of the very few alternatives I see for using newer sources? (Here I'd like to point out that build JDK is not necessarily the runtime JDK. And, with the changes in past years, I believe it should be easily achievable to have build JDK newer than the runtime JDK, and the opposite direction was always the case.) > > > Also, if we ever tried to make reproducible builds, having a firm, known, compiler might reduce the amount of problems to solve. > > It is trivial to install a JDK from a known vendor, if the javac is really the biggest problem. Contrary to some comments about using recent JDKs read as if it takes days to install a current JDK, in reality it is a matter of minutes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- 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
