so 19. 12. 2020 v 16:53 odesÃlatel Laszlo Kishalmi < laszlo.kisha...@gmail.com> napsal:
> Well, > > Personally I do not hate nb-javac. I do not like the relationship we are > having with it. And the way we are communicating it with the users. Like > we have a new JDK which nb-javac is does not support, we tell the users > go for the JDK. When some exception happens in we say try with nb-javac, > and again if there is something strange with nb-javac we tell the users > do not use nb-javac. +1 That's exactly what I am doing as well when something isn't working. Try without nb-javac, try on old JDK, try on latest JDK, try with nb-javac. Still broken? Clear the caches ;-( As Javier puts it: > I love it when it works and hate it when it doesn't. That's certainly not the experience we want to load on shoulder of NetBeans users. However the core of the problem is that nb-javac behavior is significantly different to regular JDK's javac. My proposal is to eliminate this difference. nb-javac shall be no different to JDK17+ javac! There shall be an automatic process to generate nb-javac from any javac: - no delays publishing new version - no differences in behavior That's my "common ground" to build solution on top of. Once we have it, we can ask: # How shall that influence Apache NetBeans users? Maybe Laszlo's: > Create a separate distribution channel for nb-javac. # How shall nb-javac be distributed? Neil suggested my favorite solution: > all files are covered by CPE, ... so we open a specific ticket for this with legal? # How shall nb-javac be promoted? Include nb-javac in Apache NetBeans ZIP/installer by default as Neil indicated? Telling Apache NetBeans users to always run their IDE on latest JDK? Options are endless when we have a "common ground" to build on top of. I am going to rely on Jan Lahoda to improve JDK's javac to be good enough. I'll continue thinking about the automatic transformation to nb-javac. -jt
