Hey!
Hi,
I don't think that any of those suggestions requires a v5 and most of them are already in progress with a v4. But what's a v5 anyway, beyond just marketing? A v5 shouldn't be interpreted as a must-have for innovation, innovation can and already happens with v4.x.
The reason why I tell this is because the move from eclipse 3.x to 4.x wasn't an obvious success, it had a lot of quirks, technically, organizationally; affecting negatively most users and a good part of the community. The reason was that the 4.x was targetting too many changes in a short time, with deadlines for releases, putting pressure on the developers and adopters... I don't want that history to repeat and want to encourage safer continuous innovation as we're doing now over risky "breaking innovation".
I have a few things in mind for this.
- ship the Java tooling inside the SDK on top of
JDT.LS (move towards LSP-based tooling)
JDT-LS integration for Eclipse IDE already exists at
https://github.com/redhat-developer/eclipseide-jdtls. It's currently not actively maintained, but getting back to work wouldn't be hard. Once this is in, the whether to ship JDT-UI or JDT-LS is a matter of packaging. Note that
JDT.LS+LSP4E misses some features and configuration compared to JDT-UI: most of the interesting wizards, configuration pages, debug... are in JDT-UI and
JDT.LS cannot help there. I personally believe we cannot do without it.
JDT.LS + LSP4E can only be used as a substitute for the Java Editor, not much more.
If some people are interested in continuing this work and prefer it to be an Eclipse project, I'd be happy to facilitate the migration and the involvement of new developers.
- ship JDT on top of the javac parser
An up-to-date Javac-capable JDT fork is available at
https://github.com/eclipse-jdtls/eclipse-jdt-core-incubator/ . It's still missing some important features, but it's already usable (Jinbo and I will promote it at EclipseCon, and this fork is what is going to be used for upcoming builds of jdt-ls and vscode-java), and there is not so much work left to do.
- ship a revamped platform-neutral implementation of SWT (gpu accelerated, with some updated look & feel)
I do love my Platform-specific implementation without Eclipse theming on, and with theming coming from GTK/Gnome instead :P
I won't do anything against a new implementation of SWT, but I am personally very skeptical of the return on investement here. It can easily be something extremely expensive which in the end isn't better in term of usage or maintenance than a good old platform-specific implementation.
Cheers,
