You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2021/03/09 12:01:12 UTC
Re: Let's learn to love (the new) nb-javac!
>
> > https://github.com/oracle/nb-javac/pull/12
> >
> > Manually written nb-javac is dead. Long live the new nb-javac!
>
> Firstly, let me say I think that's a great move forward for nb-javac.
> And from how I worded that, you probably know I'm going to raise a
> "however" .. :-) Not something that might be a showstopper to us
> learning to love nb-javac though ..
>
> > > Let's develop the new `nb-javac` and let's learn to love it!
>
> We need to unpick that sentence into two parts. If we presume "Let's
> develop" means Let *us* develop, then the simple answer is we can't.
> Development of nb-javac has to be external and independent.
Right. `nb-javac` is an independent component created with only purpose: To
be consumed by (Apache) NetBeans project and help to improve experience of
NetBeans Java IDE users.
> At the
> same time, in my experience from release managing, nb-javac has been
> the number one cause of release delays. Somehow those things need to
> be reconciled. In order to love nb-javac, surely we would need a long
> term, external commitment to develop it, and a surety that the
> external project can meet our release requirements?
The work on [automatic refactoring of JDK's javac to nb-javac](
https://github.com/oracle/nb-javac/pull/12) shall improve the situation.
Just change the JDK's commit to import, run the build, upload the binaries.
The previous delays were caused by the need to do manual changes and that
is being eliminated by https://github.com/oracle/nb-javac/pull/12.
> And I realise
> that "external" there is probably going to be mostly if not
> exclusively run by people who also happen to be NetBeans committers or
> PMC, just not here!
>
In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over the
maintenance of `nb-javac`. The plan
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
and the work in https://github.com/oracle/nb-javac/pull/12 are results of
that promise. Btw. the plan mentions JDK17 as the target date - e.g. I
assume it is going to take quite some time, before the ownership of
`nb-javac` is transferred to me. Certainly I can't provide any estimate
neither whether that happens at the end or not.
> Assuming that, then can we learn to love it? Well, firstly, as you're
> looking at the sources, an audit that every file is really subject to
> CPE *may* actually allow, given more recent developments, us to go
> back to Apache Legal and request permission to ship nb-javac as a
> dependency out of the box. Is that actually a desirable outcome,
> particularly considering above?
>
+100, yes, that's the desirable outcome. Jakub Herkel has just complained
about two different ways to use javac in NetBeans - having just one (e.g.
automatically generated `nb-javac` from the latest JDK) would be awesome!
If it remains an optional dependency,
Javac is hard dependency for NetBeans Java IDE (not for PHP, JavaScript
parts, etc.) right now. Luckily it comes as a system dependency (from any
modern JDK). That means `nb-javac` is ...
> then we're left with considering
> "Optional means that the component is not required for standard use of
> the product or for the product to achieve a desirable level of
> quality.
...is an optional dependency. People can use NetBeans on latest JDK and get
the same (with https://github.com/oracle/nb-javac/pull/12 it is really the
same!) experience. Given JDK17 is going to be an LTS I'd suggest to force
NetBeans IDE users to: Either run NetBeans on JDK17 or install nb-javac!
> What about editing JDK 19 while running on JDK 17?
That would only be possible with `nbjavac@19` running on JDK 17.
> Could that also be
> addressed by eating our own dog food and running the LSP on the target
> VM?
That is an unexplored area for me. I assume it is a long road to get there
and keep the current level of Java support. Certainly longer than my
nb-javac plans:
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
> The key thing being, if nb-javac remains optional, then what
> features of the IDE do we continue to consider non-standard or not
> wanted by the majority of users?
>
I believe it is the combination of IDE's JDK/Java features that creates the
restrictions. Without `nb-javac` selecting the right JDK matters. With
`nb-javac` and any JDK8+ one can run NetBeans IDE and use the latest Java
features without any restrictions.
> Contrary to the assertion, I'm not sure that everyone hates nb-javac.
> I don't! I think we've been staring at a map for a good long while,
> may have finally reached the fork in the road that we could see on the
> horizon, and are still not quite sure which direction to take.
>
Choices are always tough. Luckily for me, I don't have a choice. I promised
to take away the cost of maintenance from current `nb-javac` maintainers by
end of 2021. On the other side I need NetBeans IDE and/or VSNetBeans to run
on GraalVM8. I am doing my best to balance these two requirements.
-jt
Re: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Couple of comments inline - firstly, have opened
https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-563
Hopefully OK?
It's not like it's asking any more than
https://issues.apache.org/jira/browse/LEGAL-489 mind you, but
hopefully updated info might help! :-\
On Thu, 11 Mar 2021 at 07:45, Jaroslav Tulach <ja...@gmail.com> wrote:
> It always depends how one tells the story. I want to find arguments for Apache
> NetBeans to bundle `nb-javac` along with the convenience binaries. When I say
> "the only purpose" I want to stress that the maintainers of `nb-javac` really
> want it to be used that way.
True! And as maintainers that makes sense. From the ASF / NetBeans
as consumer angle, IMO it's a positive if it's a library that has
other users than just us. And the "entirely separate from our
products" argument is a little easier.
> > And
> > published via Oracle namespace in future?
>
> I am quite happy with current setup where Toni uploads the binaries to Maven
> central. I have no intention to change it[1].
Given that one concern (from legal) is ensuring CPE applies, eg. that
all source files used to create the resulting binary are subject to
CPE, it *might* be easier if the binary we consume was built by and
from *a* namespace belonging to the copyright holder, and with
explicit CPE license attached. Let's see what we get back.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Neil.
> > Right. `nb-javac` is an independent component created with only purpose:
> > To be consumed by (Apache) NetBeans project ..
>
> Well, to me the "only purpose" bit is the crux of the "independent"
> argument, and makes it rather different to other libraries we use, but
> also from plugins. I'm not sure it's necessarily useful to say that
> it continues to be developed with only that purpose?
It always depends how one tells the story. I want to find arguments for Apache
NetBeans to bundle `nb-javac` along with the convenience binaries. When I say
"the only purpose" I want to stress that the maintainers of `nb-javac` really
want it to be used that way.
> The other things obviously are independent public source hosting and
> build instructions, independent distribution, independent issue
> tracking, etc. All things I think have been addressed recently.
Right. All of that is in place at https://github.com/oracle/nb-javac and with
the help of Toni Epple the JARs are even distributed via Maven central.
> > In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over
> > the maintenance of `nb-javac`.
>
> As in maintained and developed by Oracle Labs into the future?
Yes, I am involved and I plan to be involved. With https://github.com/oracle/
nb-javac/pull/12 the maintenance is trivial. As such I am not afraid to commit
to continue maintaining the `nb-javac` in the future.
I also believe that, once we settle on unified infrastructure to use the same
Javac libraries (either from latest JDK or via nb-javac backport), OracleLabs
will be able to improve the user experience (completion, hints, project
integration, debugging experience) even more than we have done during last two
releases.
> And
> published via Oracle namespace in future?
I am quite happy with current setup where Toni uploads the binaries to Maven
central. I have no intention to change it[1].
> Because ...
> OK, I'm inclined to open a legal ticket then, and see where we get
> with that so we can at least plan based on it. Any objections? Or
> someone else really want to do it?
> I think with the recent assessment that CPE *could* be compatible with
> ASF licensing requirements, we're left with also ensuring it's all
> fully independent - sources moved from legacy netbeans.org location to
> Oracle namespace, binaries no longer consumed from OSUOSL - I think
> we're in a much better place there now.
It would be amazing to see the automatically generated `nb-javac` based on
JDK-17 `javac` to be included in NetBeans convenience binaries!
-jt
[1] Please note that neither GraalVM libraries are uploaded to Maven under
Oracle namespace. For example:
https://search.maven.org/search?q=g:org.graalvm.tools
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 11 Mar 2021 at 08:08, Jaroslav Tulach <ja...@gmail.com> wrote:
> Looks like the invention of LSP was really great move by the VSCode guys! It
> allows each language to provide good enough IDE support by coding in the
> language itself and writing the "server side" IDE piece while reusing
> internals of own language compiler. No surprise everyone is providing LSP
> servers.
Agreed!
> > I remember
> > talking with you at JCrete on this during early transition, and about
> > the fact that the other, other VSCode LSP support was using it.
>
> The days where NetBeans could afford to support any language on the planet are
> over. There is just a few of us and we don't have the momentum we used to have
> in the first ten years of this century. In such situation re-using work done by
> others via LSP is the best option we have.
In the bit you quoted I was meaning other consumers of nb-javac ...
But in general, I think us embracing LSP as a server provider, and as
a consumer for other languages is great. But I'm trying to ask
whether we should be moving towards a position where *every* language
in the IDE UI is supported by an LSP server, ours or someone else's?
A *long term* goal to consume our own Java LSP server might, with
limited resources, link ...
> VSCode support is
> important for OracleLabs strategy, it actually means quite a lot of
> contributions from Sváťa, Dušan, Martin, me.
... even more into the IDE experience?
I also mentioned re. nb-javac because the alternative if we can't rely
on nb-javac as the single option in future to support developing JDK
19 while running on JDK 17 is surely along the lines of ..
https://github.com/apache/netbeans/pull/1475
?
> > don't think it still is, maybe it could be encouraged back to it - an
> > independent component that provides useful features for editors in
> > general, and is consumed by other projects, is a good thing IMO!
>
> PS: Such an independent component would have to be built on top of `(nb)-
> javac`. I don't understand how that would simplify the licensing or
> distribution? As far as I can tell all the problems we are solving now would
> remain the same.
Again, it won't, because that bit was specifically talking about other
consumers of nb-javac.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!
Posted by Jaroslav Tulach <ja...@gmail.com>.
Let's open another thread...
> > > Could that also be
> > > addressed by eating our own dog food and running the LSP on the target
> > > VM?
> >
> > That is an unexplored area for me. I assume it is a long road to get there
> > and keep the current level of Java support.
>
> Almost certainly. OTOH there seems to be a lot more focus on LSP at
> the moment, so I wondered whether it's a useful direction of travel
> that actually focuses efforts and longer-term reduces workload? Just
> throwing it out there - I like the idea of decoupling into UI and
> headless processes anyway, potentially running on different VMs. A
> thread for another day!
Looks like the invention of LSP was really great move by the VSCode guys! It
allows each language to provide good enough IDE support by coding in the
language itself and writing the "server side" IDE piece while reusing
internals of own language compiler. No surprise everyone is providing LSP
servers.
> I remember
> talking with you at JCrete on this during early transition, and about
> the fact that the other, other VSCode LSP support was using it.
The days where NetBeans could afford to support any language on the planet are
over. There is just a few of us and we don't have the momentum we used to have
in the first ten years of this century. In such situation re-using work done by
others via LSP is the best option we have.
It took me a long time to convince Jan Lahoda to bet on LSP, but the results
are great! I am really enjoying editing TypeScript in NetBeans these days and
that's all possible only because of yet adopting LSP and creating
infrastructure to use such servers.
From the other side (again thanks to Jan's early work) we can use the NetBeans
infrastructure and expose it (via LSP) to VSCode users. As VSCode support is
important for OracleLabs strategy, it actually means quite a lot of
contributions from Sváťa, Dušan, Martin, me. As there is close synergy between
VSNetBeans and real NetBeans, the whole project benefits.
All of that has only been possible thanks to relying on LSP. Amazing result,
I'd say.
-jt
> I
> don't think it still is, maybe it could be encouraged back to it - an
> independent component that provides useful features for editors in
> general, and is consumed by other projects, is a good thing IMO!
PS: Such an independent component would have to be built on top of `(nb)-
javac`. I don't understand how that would simplify the licensing or
distribution? As far as I can tell all the problems we are solving now would
remain the same.
PPS: Running `ant -f java/java.lsp.server/ build-lsp-server` actually creates
such component.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Let's learn to love (the new) nb-javac!
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Thanks for the detailed response! A few comments inline - let's see
how we get this to the next stage then ...
On Tue, 9 Mar 2021 at 12:01, Jaroslav Tulach <ja...@gmail.com> wrote:
> Right. `nb-javac` is an independent component created with only purpose: To
> be consumed by (Apache) NetBeans project ..
Well, to me the "only purpose" bit is the crux of the "independent"
argument, and makes it rather different to other libraries we use, but
also from plugins. I'm not sure it's necessarily useful to say that
it continues to be developed with only that purpose? I remember
talking with you at JCrete on this during early transition, and about
the fact that the other, other VSCode LSP support was using it. I
don't think it still is, maybe it could be encouraged back to it - an
independent component that provides useful features for editors in
general, and is consumed by other projects, is a good thing IMO!
The other things obviously are independent public source hosting and
build instructions, independent distribution, independent issue
tracking, etc. All things I think have been addressed recently.
> The previous delays were caused by the need to do manual changes and that
> is being eliminated by https://github.com/oracle/nb-javac/pull/12.
Partly, yes. Although a lot has also been to do with delays in
integration and our infrastructure. eg. switch to third-party UC in
11.2 was caused by inability of plugin portal to handle different IDE
releases (something we unfortunately still have), and current delay
was caused by conflation of bug fixes with switch to Maven.
The nb-javac team have done a great job - I think partly it's also,
from a previous schedule thread, that our release schedule and that of
the JDK make timing a little awkward?
> In Dec/Nov 2020 I made a commitment (internally in Oracle) to take over the
> maintenance of `nb-javac`.
As in maintained and developed by Oracle Labs into the future? And
published via Oracle namespace in future? Because ...
> > go back to Apache Legal and request permission to ship nb-javac as a
> > dependency out of the box. Is that actually a desirable outcome,
> > particularly considering above?
>
> +100, yes, that's the desirable outcome.
OK, I'm inclined to open a legal ticket then, and see where we get
with that so we can at least plan based on it. Any objections? Or
someone else really want to do it?
I think with the recent assessment that CPE *could* be compatible with
ASF licensing requirements, we're left with also ensuring it's all
fully independent - sources moved from legacy netbeans.org location to
Oracle namespace, binaries no longer consumed from OSUOSL - I think
we're in a much better place there now.
> That means `nb-javac` ...
> ...is an optional dependency.
I still think we're playing semantics a little there with what
"optional" means, and I think it sometimes colours decisions about
this. The other part of that ASF quote was about not being used by
the majority of users, and I think that's a harder one to claim.
OTOH, we were also allowed to do what we're currently doing because
the need to accept GPL+CPE is hardly a surprise to someone wanting to
develop in Java.
There is the question whether, in either scenario, nb-javac should be
a non-optional requirement for opting in to Java development?
> > Could that also be
> > addressed by eating our own dog food and running the LSP on the target
> > VM?
>
> That is an unexplored area for me. I assume it is a long road to get there
> and keep the current level of Java support.
Almost certainly. OTOH there seems to be a lot more focus on LSP at
the moment, so I wondered whether it's a useful direction of travel
that actually focuses efforts and longer-term reduces workload? Just
throwing it out there - I like the idea of decoupling into UI and
headless processes anyway, potentially running on different VMs. A
thread for another day!
> Choices are always tough. Luckily for me, I don't have a choice. I promised
> to take away the cost of maintenance from current `nb-javac` maintainers by
> end of 2021. On the other side I need NetBeans IDE and/or VSNetBeans to run
> on GraalVM8. I am doing my best to balance these two requirements.
Awesome! Choice made then ... well, partly. :-)
Thanks and best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists