search

eclipse-jdt / eclipse.jdt.debug

Eclipse Public License 2.0
16 stars 47 forks source link

Drop support for older Java versions in debugger #451

Open iloveeclipse opened 3 months ago

iloveeclipse commented 3 months ago

Same as https://github.com/eclipse-jdt/eclipse.jdt.ui/issues/1465 but for JDT Debug component.

We should follow-up the jdt.core issue https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2536 with support in the JDT Debug as well. This issue is to discuss and track the corresponding debugger changes. To start with, we should remove the older versions of JEs and compliance levels from the UI.

The other issue that is kind of related but might be worth taking up is the ordering of the compliance levels. As we focus more on support for more recent Java versions, it doesn't make sense to stick to the older-versions-first approach on the UI drop down list. Perhaps, we should revert the order to reflect the trend in usage.

Example for the old EE's is properties of the JRE container on a project:

image

also a "new Java project" and similar wizards: image

What is not clear for me if this page should also filter possible EE's (why should it if they can't be used for projects, but of course there are bundles around that have old EE's specified):

image

HannesWell commented 3 months ago

What is not clear for me if this page should also filter possible EE's (why should it if they can't be used for projects, but of course there are bundles around that have old EE's specified):

This is similar to https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/433, isn't it? I'm supporting clean-ups of EEs, but if these EEs are really removed PDE has to be adapted in advance to avoid problems like in the attempt to remove the JRE-1.1 EE last release cycle.

The other issue that is kind of related but might be worth taking up is the ordering of the compliance levels. As we focus more on support for more recent Java versions, it doesn't make sense to stick to the older-versions-first approach on the UI drop down list. Perhaps, we should revert the order to reflect the trend in usage.

I agree with your assessment, but I think this is an orthogonal change, but a good one in my opinion.

iloveeclipse commented 3 months ago

This is similar to #433, isn't it?

I'm thinking about possibility to just "hide" old EEs from every UI, and at least not allow to create anything with old environment. So internally it still may be understood / referenced. The problem I see is that we can't support Java 6 environment with Java 6 compilation settings, because compiler would reject Java 6 target. This is however irrelevant for PDE/p2 where compiler settings are not needed because the bundles are "given" and compiled already.

So something like "read-only" support for old EE's...

iloveeclipse commented 3 months ago

@HannesWell : something like https://github.com/eclipse-jdt/eclipse.jdt.debug/pull/452 + https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/1469, based on https://github.com/eclipse-jdt/eclipse.jdt.core/pull/2606 idea.

With this PDE could still use "old" API with all possible Java / EE versions, while JDT UI only sees "new" Java versions.

HannesWell commented 3 months ago

With this PDE could still use "old" API with all possible Java / EE versions, while JDT UI only sees "new" Java versions.

If you thing the new API is necessary in the wider scope, I'm fine and will see if it's reasonable to adjust PDE to the new methods or not. With #433 and my previous comment I mainly wanted to express that I'm willing to help and adapt PDE if the existing methods change their behavior. Just for PDE I don't think new API has to be introduced and callers of existing methods can be adapted to the new situation, even if EEs are really removed and not just hidden.