The problems all come from the fact that Platform and JDT are/were different groups of people. Conway's Law: Code comes to represent the organisation that creates it.
So Eclipse Foundation should restructure the projects to solve this.
Non-blocking code completion with a stream as input
would IMHO also enhance the JDT code completion quite a bit.
Simon, did you ever try to contribute that back to
JDT?
No, I did not. Since we write everything in Scala nowadays, we would
have to rewrite our code in Java if we want to contribute it back.
Also for the limitations in eclipse.core could you
give same examples?
The first that comes to mind are the internals. As a Scala developer
I care a lot about (subjective) great code quality and its
maintainability. By looking at the internals of eclipse.core,
eclipse.ui and nearly everything in JDT the only impression I get is
that its developers tried hard to take Effective Java (the book by
Joshua Bloch), reverse all the rules and then apply them to one
codebase. Code quality may not matter if you can pay all the devs
but it matters if you want to find new contributors and nowadays
there are not even a lot of payed devs anymore.
A related problem is that Eclipse wants to be a platform to build
IDEs upon but refused for its entire existence to provide the
abstractions to build an IDE. Nearly everything is in JDT, which was
only made for Java. Every other language implementation had to
either fork JDT, extend it or rewrite everything from scratch.
Extensiblitiy looks different. The LangEclipseIDE project comes 10
years too late actually, people moved on to IntelliJ and they will
never come back.
When I look at the code of Eclipse (better: the projects mentioned
above, which are relevant for building an IDE) I always get the
impression that no one of the contributors actually understood what
abstraction means. This more or less means that nothing is
extensible. There is this great plugin system Eclipse is built upon
but it was created to handle JDT and when the chance of handling
other languages came up, it was not taken.
Instead of pushing IDE features, people pushed the RCP stuff. While
doing that they forgot that Eclipse is being sold as an IDE and by
refusing to accept that they moved the entire platform on ground.
Over the years it was easy for IntelliJ to take over. And other
platforms like Atom, Visual Studio Code and even Neovim are rising
because they fill gaps Eclipse just can't fill.
I don't know why the Eclipse foundation just couldn't see that the
IDE sector is what made Eclipse important and what keeps Eclipse
alive. I only know that they killed Eclipse for IDE/plugin
developers by completely fucking up the internals and by doing that
they also killed the platform for all of their users.
As a concrete example, just look at eclipse.ui: All of the
improvements you and others did there lately were mostly none for me
or for my coworkers. In fact there were so many regressions
introduced we couldn't even report all of them back, we just get
pissed off. It took me half a year to even adopt Luna and Mars
doesn't look better. In fact I only moved on to Luna because I had
to. This is not how you gain trust in a platform. What did I hear
lately? Android IDE completely moved to IntelliJ, guess why.
Ok, great to hear. I'll have a look if there is something we
could use.
So yeah, for example: content assist, code snippets
("Templates" in JDT lingo), preference pages for all
that, outline and quick-outline (no hierarchical
outline support though).
However, no Junit view, nor package explorer support.
Well not for displaying Java-like flat packages at
least, but there is some support for other Project
Explorer extensions: stuff like project dependencies
and (in an upcoming version) build targets. I dunno
how well that applies to Scala though.
No code folding support either (DDT has that
functionality, but it's crappy code copied from DLTK
that hasn't yet been cleaned-up/refactored, and put
into LangEclipseIDE).
One interesting thing that LangEclipseIDE has, that
doesn't come from JDT or JDT-like IDEs, is
functionality to help you integrate external,
command-line tools to provide IDE functionality. For
example in Goclipse, the outline is provided by an
external parser (updated on the fly as the user types
in the editor). Again dunno if that would apply well
to Scala.
Calling command line tools is not necessary in Scala IDE,
since all the tools are already written in Scala and
therefore can simply added as a library to the IDE.
Sidenote: Funny enough, unlike JDT, the Goclipse
outline is updated almost instantly as the user types,
because there is no artificial delay to start the
reconciler (I dunno why that delay is in JDT in the
first place). Not that it matter much anyways -
personally I haven't used the Outline view in ages,
Quick-Outline is much more handy.
We use the reconciliation time because the Scala compiler is
slow as hell and takes enormous resources during
compilation. It can't be aborted during compilation of a
single file either. Therefore, calling it on every keystroke
would more or less be impossible.
Given that the Scala compiler is so slow a lot of APIs can't
be used or make some features difficult to implement. Code
completion for example can take some seconds before
completion. Because the JDT API just takes a list of
completions we have to block users until the compiler is
finished. If the API would take a potentially infinite
stream of completions, we wouldn't have to block but could
show new completions once they appear. This forces us more
or less to re-implement all APIs in a non-blocking/reactive
way and makes it more difficult to use work from others
because for most languages one does not need to think about
the compiler being to slow.
Scala IDE
dev here. A few years ago I would have
welcomed such a project, nowadays I lost faith
in the Eclipse platform. There are too many
internal issues and limitations that make
using the eclipse.core and especially the
jdt.core API a pain. This means that over the
years we reduced dependencies to these APIs as
much as possible and replaced them with our
own implementations.
We still depend on JDT because that is how we
started and while our core is ready in moving
away from JDT our UI is not. JDT provides some
useful stuff like the package explorer, the
outline view, the junit integration etc. and
we don't have the resources to replace them by
ourselves. Do you have any plans to provide
programming language independent UI
components? This could make your project
useful to us, for core API we probably don't
have a need anymore.
On 07/03/2015 03:34 PM, Bruno
Medeiros wrote:
Hi guys. Doug pointed me
to this mailing list, so I wanted to
let you know about a project I've been
working on: LangEclipseIDE.
LangEclipseIDE is a framework/library
for building language IDEs on top of
Eclipse. It aims to provide common
functionality that is present in IDEs
like JDT or CDT but is not refactored
out into an externally reusable
component. So the aim here is similar
to DLTK, but the overall design is
different in some ways (even though we
reuse bits of code from JDT and DLTK).
LangEclipseIDE is currently used by 3
IDEs: DDT, RustDT, and Goclipse. It's
still a young project so there is much
more that could be done. It would be
nice to get some collaboration going
with other IDE projects as there is a
lot of potential for that.