Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #352479 +++ It would be nice to move platform debug to a 1.5 BREE. Aside from the obvious language benefits, it would be good to keep its BREE in sync with JDT debug. Pawel, your thoughts? If we were to do this work it would be good to do prior to the promotion of the async viewer code to official API - that way the APIs would not have to modified after-the-fact.
I'm in favor for moving to 1.5, I only need to make sure that I'll have time to refactor the code.
*** Bug 386277 has been marked as a duplicate of this bug. ***
Two notes on this: 1. The minimum execution environment should not be changed (especially raised) unless we have a need for it, e.g. there's a new API without which we can't do the job. 2. When moving to 1.5 or higher one must also generify the code, which involves work (see: http://wiki.eclipse.org/Generify_A_Java_Project ).
Dani- Thanks for pointing this out to me, I did a quick search last night but obviously not enough. I read through the Generify [1] and Evolving API's [2] wikis and have two quick comments/questions: 1) By raising the execution environment, does that necessitate generify'ing the project? Or, can the execution environment be raised independently? 2) Do(/how) the following preferences effect binary compatibility? I can certainly conjecture from their names what the impact may well be. However, in the sense of updating the execution environment, if you only update the classpath and manifest, where do these settings factor in? -org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=disabled -org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.2 -org.eclipse.jdt.core.compiler.compliance=1.4 -org.eclipse.jdt.core.compiler.source=1.3 -(others?) Thanks, JD [1] http://wiki.eclipse.org/Generify_A_Java_Project [2] http://wiki.eclipse.org/Evolving_Java-based_APIs
(In reply to comment #4) > Dani- > > Thanks for pointing this out to me, I did a quick search last night but > obviously not enough. > > I read through the Generify [1] and Evolving API's [2] wikis and have two > quick comments/questions: > > 1) By raising the execution environment, does that necessitate > generify'ing the project? Or, can the execution environment be raised > independently? When moving away from 1.4 one of the main benefits are Generics. That alone would be a good reason to raise it. So, yes, this should be seen as a must. > > 2) Do(/how) the following preferences effect binary compatibility? I can > certainly conjecture from their names what the impact may well be. However, > in the sense of updating the execution environment, if you only update the > classpath and manifest, where do these settings factor in? > -org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=disabled > -org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.2 > -org.eclipse.jdt.core.compiler.compliance=1.4 > -org.eclipse.jdt.core.compiler.source=1.3 > -(others?) > One would only change the EE, which would imply those settings. The immediate breakage happens because users can no longer use Debug with a 1.4 JRE even though it would work, but the bundle will fail to load (satisfy the constraint).
Pushed to master: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=d975f27f12707ae6598994c5e3c6bd5e271d46c4 I'll leave the bug open until we have a build.
We have a build, marking fixed. Any new issues can be opened in their own bug reports.
(In reply to Michael Rennie from comment #7) > We have a build, marking fixed. Any new issues can be opened in their own > bug reports. Bug 422048.
