I think a
more appropriate question at this point would be to ask which areas would be benefited most from the Java EE tooling support?
Looking at https://www.eclipse.org/webtools/,
I can think of a few areas and how the landscape has evolved over the last
decade for some of them:
Server Tools: These were primarily app server connectors
which were responsible to call the appropriate startup/shutdown/restart or
deploy hooks of their respective app servers from within the IDE. There is
little room for improvement in that area so long as the tools are kept updated
with the latest app server versions.
Server Profiling: This is a very grey area. Eclipse used to
have TPTP which was retired long back. However, IBM continued to provide a very
similar functionality in their WAS profiling. Oracle have their own proprietary
AppXRay and I think even JBoss had(?) its own profiler project based on JVMPI
and JVMTI. Besides, the profiling landscape has changed a lot to catch up with
the demands of the industry. The need has shifted from server profiling to
application profiling as enterprises are finding themselves in heterogeneous environments.
They are looking for specialized context aware profiling tools (such as APM
tools for end-to-end transaction profiling) which are provided by third party
vendors. The application profiling tools market is pretty competitive here and
with the need to support profiling for cloud based deployments or in heterogeneous
environments, I don’t think any vendor would be willing to wait for Eclipse
tools to catch up and provide a base for them. Also with the evolution of
Restful APIs and the cloud based service models many of the profiling capabilities
are built into the API management tools themselves which require them for
monitoring SLAs.
Web UI tooling: There was a time when companies like Exadel,
Genuitec(MyEclipse IDE), Instantiations(GWT designer) had a thriving market for
the UI tools they provided on top of Eclipse. Those days are long past. The
tooling support was needed because the UI components were being generated on
the server for most of the web frameworks available during that time. And
server-side programmers did not have the necessary skills or time to create
attractive UI. Today, in order to facilitate lean multi-channel architectures,
enterprises require building channel specific UI on top of their RESTful services. Today we speak of rich-clients which
are not just browser based but have to cater to mobile platforms as well. The
current crop of UI libraries and frameworks do not require much IDE support to
build rich UI on top of REST APIs. (Btw, if we are speaking about supporting the
current crop of UI frameworks and libraries then it is worth mentioning that
Jetbrains has a solid presence and a clear lead there which leaves little room
for Eclipse to establish itself). Even on the server-side, thanks to annotation
based approaches, we no longer require scaffolding code to publish or consume
REST services, so not much need for IDE support there as well.
Database tooling: JPA is widely used for relational databases and its support for NoSQL data is still not mature enough. So unless the specifications become mature and stable on that front, there is little to benefit from tooling, as the JPA implementations continue to provide their own approaches for NoSQL access. On the relational front, I think the current tooling capabilities are sufficient.
Summarily, we need to re-evaluate where the webtools projects are headed and how relevant are those tools in the current enterprise web-development landscape.
My 2 cents.