LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!

[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: LSP - eating our own dog food was: Let's learn to love (the new) nb-javac!

[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