Drop support for older Java versions in debugger

[iloveeclipse]

Same as eclipse-jdt/eclipse.jdt.ui#1465 but for JDT Debug component.

We should follow-up the jdt.core issue eclipse-jdt/eclipse.jdt.core#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:

also a "new Java project" and similar wizards:

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):

[HannesWell]

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 #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]

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]

@HannesWell : something like #452 + eclipse-jdt/eclipse.jdt.ui#1469, based on eclipse-jdt/eclipse.jdt.core#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]

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.