another question is the is it worth to spend time on improving the jdt ui parts when more things are happening in vscode java ?
I do not know and wouldn't dare betting on one or the other ;) But I can share some personal impressions:
I think that by nature of how JDT can integrate natively in Eclipse IDE, it is and will always be more capable of deeper and more powerful integration than what LSP and vscode-java will ever be capable of achieving. Having access to ICompilationUnit in the UI is extremely more powerful than whatever LSP will ever be able to specify. Because of that, if we're to implement a crazy new UI approach for Java development, then it will be easier and faster to achieve with JDT-UI than with vscode-java; and so I think JDT UI is still here to stay and also here to grow. But growing doesn't mean sticking to the current state, it can also mean that for some operations, if we're happy with the generic LSP-based implementation, then JDT-UI could drop some of its specific workflows/UIs and adopt common LSP ones. So on the long run, I would imagine JDT UI dropping progressively some of the most "basic" things that LSP does equally well (but I don't think it's that many things...); and focusing on advanced and powerful integration that cannot be achieved with LSP; basically expressing more added-value.
Since JDT UI contains many features and trying built aside on top of generic editor might seems like building another vscode java on eclipse isn’t it ?
Yes, it's kind of it. I imagine Java development in Eclipse IDE could become like vscode-java on Eclipse IDE + some very advanced features provided by JDT-UI that cannot be achieved through LSP.
When looking more and more extensions for java echo system is popping up and eclipse extensions are rarely updated.
Extensions being rarely updated is also an indicator of Platform and extension stability.
I used to care too much about such metrics; but my personal and I think definitive conclusion on it is that they're worth nothing and are just data used and misused by people in a way that serves their own business goals (ie there is a goal and some people build an interpretation of the data that serve this goal, but could easily have build an opposite interpretation of the data if it were to serve another goal) more than data that is actually analyzed objectively to identify opportunities for real technical progress.
The only data that I think matters is the amount and diversity of code contributors.
