On 19.10.21 15:25, Jaroslav Tulach wrote:
Dne úterý 19. října 2021 12:43:13 CEST, Neil C Smith napsal(a):
There are a bunch of reasons why end
users are choosing not to use nb-javac now. That fact needs
addressing.
Obviously. It has to be addressed. That's what I am trying to do.
There is only a single plan written down
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
as far as I know.
The plan operates with an assumption that there is going to be no functional
difference between the latest (at the time of release) JDK javac and nb-javac.
As such the dichotomy of using/not using nb-javac shall be gone once the plan
is implemented.
on what is this assumption based on? Are there efforts to upstream
missing functionality into OpenJDK's javac?
https://cwiki.apache.org/confluence/display/NETBEANS/Differences%3A+nb-javac
if i understand all that correctly, there are three compilers right now:
- without nb-javac, NB uses JDKs javac which has less functionality
but should do ok if the newest JDK is used
(this option is often used as workaround if the project OpenJDK is
more recent than the provided nb-javac)
- manually backported nb-javac, this is the supported way, with all
the bells and whistles but also its limitations of not being able to
work with ea JDKs
- automatically backported nb-javac (proposed), is essentially JDK's
javac with a lower bytecode level, or is it more than that / what is
missing from manually backported nb-javac?
michael
---------------------------------------------------------------------
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
