Community
Participate
Working Groups
https://wiki.eclipse.org/Execution_Environments#Which_Execution_Environment_should_I_use.3F reflects some moment in the past when BREE 1.5 was considered the most appropriate. The static recommendations referring to specific JDK version numbers should be replaced by a time-based policy that would automatically move the recommended BREE forward as time passes. Each next Java version is superior to the previous one. As a general rule, using a newer version of Java makes Eclipse committers and contributors more productive and the code safer. On the other hand Eclipse platform has to support users who for a legitimate reason cannot upgrade to the latest JRE. http://www.oracle.com/technetwork/java/eol-135779.html defines dates of the end of public updates for different JDK versions. For overwhelming majority of Eclipse Platform users who do not have Oracle premium support, there is no legitimate reason to run an old JDK that is no longer receiving updates for security vulnerabilities. This means that Eclipse Platform doesn't need to support JDKs that no longer receive public updates from Oracle. https://wiki.eclipse.org/Execution_Environments#Which_Execution_Environment_should_I_use.3F should be modified to state that individual Eclipse projects are free to decide what BREE to use, but no project should be required to support JDK older than the one receiving public updates from Oracle, unless the project has specific reasons for that.
+1
This is not just a website update. Our policy (Eclipse top-level project / PMC) is always to only update the BREE when really needed, e.g. a project wants to use new APIs or language constructs. We do not want or recommend mass updates to the latest, but as said, when a project has good arguments it can update the BREE. However, when increasing the BREE the project must ensure that no new warnings appear in the official build, e.g. due to raw types when switching form 1.4 to something higher.
For anyone "skim reading", to cross-reference, see bug 459373 that "gave rise" to this bug. That is, "the current policy" is a real and current issue, not something in the abstract. I personally like having a notion of "time" built-in to the policy (whether it's tied to other's versions of JVM or not is another issue?) That is, we want to encourage a certain "length of time of stability" on "common VMs" ... but, at the same time encourage updates and upgrades, as that seems important to the community, especially of contributors. I know the way things are, it is not even that easy to find a version of "Java 1.4" to download, and define to PDE's set of EEs, so that users get accurate content assist, and accurate warnings/errors for using methods that don't exist in Java 1.4. Dani mentioned one "criteria" (no new warnings appear in the official build) but one thing that's unclear to me, is how to specify "no or little impact to others" downstream -- or, even if that's possible. I know at one point, there was talk about moving JFace to use generics (I believe it was JFace) but there was a downstream out cry that was not a good thing, since it caused lots of "errors or warnings" in downstream projects, for little gain, in the case of JFace. I'm simply stating this as a "plea for education" :) if there is a good way to state "minimal impact to others" (or similar), that'd be good to know. As well as, if there is any "change to policy", it should also include "by a certain milestone" (obviously, by API freeze, M6, but wonder if should be even earlier?) ... combined with "notice to the community" so that others at least have a chance of expressing concern, and/or support. (Keeping in mind that we also want to stay "nimble" and encourage rapid improvements, when possible). Much appreciate the efforts to balance "keeping us stable" as well as "keeping us current" -- it's not easy! Can we make it easier? Thanks,
(In reply to David Williams from comment #3) (In reply to David Williams from comment #3) > For anyone "skim reading", to cross-reference, see bug 459373 that "gave > rise" to this bug. That is, "the current policy" is a real and current > issue, not something in the abstract. It is not our job to force people to 1.6 or newer. If someone e.g. knows for sure he runs in a closed environment and his 1.5 JRE just works, then we should not break him, unless, as said, the project has a real need to do so. I know people that run older versions of IE for a good reason, and Windows silently let them do so.
In case it wasn't clear from the comment #0, what is being proposed is a change of policy. The proposal is to change the statically defined BREE 1.5 golden standard by a dynamically defined one that is based on the latest Oracle JDK receiving public updates. If we decide to be really conservative, we can define the standard as the latest JDK receiving public updates minus one. What is important here is that the standard is going to move forward over time. The dynamic standard BREE makes sense because each new version of JDK brings new advantages that make Eclipse committers and contributors more productive and the code safer. Again, the final decision is up to individual projects. A static policy, on the other hand, is like a tax law not indexed for inflation. It may work for some period of time, but is bound to become a source of friction at some point. In case of https://wiki.eclipse.org/Execution_Environments we've already reached that point.
(In reply to Dani Megert from comment #4) > I know people that run older versions of IE for a good reason, and Windows > silently let them do so. This example is flawed. You may be able to run IE6 if you have a Windows XP machine disconnected from the Internet. In every other case running IE6 is likely to make your organization another Anthem® Blue Cross or Target.
(In reply to Dani Megert from comment #4) > It is not our job to force people to 1.6 or newer. If someone e.g. knows for > sure he runs in a closed environment and his 1.5 JRE just works, then we > should not break him, unless, as said, the project has a real need to do so. I guess that's the issue. What counts as "a real need". IMHO, some of "staying as is" would be less painful if we had "EE definitions" for some of the older VM's, such as 1.3, 1.4, and 1.5 (see bug 432047 comment 4). But ... even then ... is it "a real need" if committers/contributors wanted to use "enhanced for loops" (introduced in 1.5, I believe). Or, if they wanted to use Boolean.parseBoolean, (1.5) instead of Boolean.getBoolean? (1.4) The former, having the advantage of accepting "yes", "ok", as well as "true" as all meaning "true". I'm just asking! I can definitely see both sides of the issue. (Well, except we really should develop some EE definitions ... but not sure that's the reason the originator opened this bug.) I think originator wanted more the burden of proof turned around ... is there "a real need" to stay on older VMs.
(In reply to David Williams from comment #7) > (In reply to Dani Megert from comment #4) > > > It is not our job to force people to 1.6 or newer. If someone e.g. knows for > > sure he runs in a closed environment and his 1.5 JRE just works, then we > > should not break him, unless, as said, the project has a real need to do so. > > I guess that's the issue. What counts as "a real need". E.g. the need (or say "wish") to use Generics, need to use new API like nio, new language constructs etc. > > IMHO, some of "staying as is" would be less painful if we had "EE > definitions" for some of the older VM's, such as 1.3, 1.4, and 1.5 (see bug > 432047 comment 4). We do have that safety net! :-) They are called 'API Tools Execution Environment Descriptions'. If those are installed, then API Tools will throw an error if you use APIs outside the defined BREE, even if you have a JRE 7 on the project. The following EEs are installed when you install the descriptions: JRE-1.1, J2SE-1.2, J2SE-1.3, J2SE-1.4, J2SE-1.5, JavaSE-1.6, JavaSE-1.7, JavaSE-1.8, CDC-1.0/Foundation-1.0, CDC-1.1/Foundation-1.1, OSGi/Minimum-1.0, OSGi/Minimum-1.1, OSGi/Minimum-1.2 > I think originator wanted more the burden of proof turned around ... is > there "a real need" to stay on older VMs. Sometimes yes. It depends from which version you change to what version. E.g. from 1.4 to 1.5 or even 1.6 is for almost all bundles a no-brainer. But if we talk about upgrading to JRE 8, it becomes difficult, since there aren't JREs for all architectures available yet.
(In reply to Sergey Prigogin from comment #5) > In case it wasn't clear from the comment #0, what is being proposed is a > change of policy. The proposal is to change the statically defined BREE 1.5 > golden standard by a dynamically defined one that is based on the latest > Oracle JDK receiving public updates. Yes, it definitely makes sense to change the JRE mentioned in 4 Which Execution Environment should I use?
From working a lot with new Eclipse contributors, I can add that contributing to a project is more interesting for contributors if it uses the latest API. Contributing to an OS project (in your unpaid time) is something you do because "it is cool". But programming with outdated / unsupported Java API is not "cool" at all.
I would like to add that a common impression most software engineers get when they see non-generified code in 2015, is that the code is not being maintained. Insistence on compliance with very old JDKs they see as a sign of project stagnation. (In reply to David Williams from comment #7) > I think originator wanted more the burden of proof turned around ... is there > "a real need" to stay on older VMs. Exactly. We want the presumption of moving forward not the presumption of standing still. As a practical step, could please somebody review and submit patches for Bug 442021 - Update org.eclipse.equinox.common to use Java 1.6 and Bug 459373 - Move all Platform Resources plugins to Java 1.6 BREE
(In reply to Lars Vogel from comment #10) > From working a lot with new Eclipse contributors, I can add that > contributing to a project is more interesting for contributors if it uses > the latest API. > > Contributing to an OS project (in your unpaid time) is something you do > because "it is cool". But programming with outdated / unsupported Java API > is not "cool" at all. + 1000 to this. At eclipse we can only learn from the amount of contributors LibreOffice managed to get just by letting them "modernize" the codebase.
+1000 I'm currently facing the stupid issue that I can't get error-free workspace because I have those nice projects below (and much more if looking on [1]) insisting to see 1.4 strictly compatible JRE: org.eclipse.core.filebuffers org.eclipse.ltk.core.refactoring org.eclipse.ltk.ui.refactoring org.eclipse.core.expressions.tests org.eclipse.core.expressions I simply *physically* can't get any compatible 1.4 JRE on my 64 bit Fedora box - one can download the archived 1.4 Java versions from Oracle site but they can't even be extracted/installed and used on modern Linux boxes!!! [1] https://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments
(In reply to Andrey Loskutov from comment #13) > org.eclipse.core.expressions.tests > org.eclipse.core.expressions These fall into the platform.ui project, I'm fine with updating them as long as we do not create new warnings in the build. Can you open a new bug report for them?
(In reply to Lars Vogel from comment #14) > (In reply to Andrey Loskutov from comment #13) > > org.eclipse.core.expressions.tests > > org.eclipse.core.expressions > > These fall into the platform.ui project, I'm fine with updating them as long > as we do not create new warnings in the build. Can you open a new bug report > for them? Bug 460048
I think most of the controversial discussion is about the recommendation of upgrading an existing plug-in. For new plug-ins I think we should state that we recommend Java 1.7 at the moment. I think that this makes sense, as the platform itself moves to Java 1.7 and this version is the lowest one that is currently maintained by Oracle for the general public.
(In reply to Lars Vogel from comment #16) > I think most of the controversial discussion is about the recommendation of > upgrading an existing plug-in. My opinion on this is to recommend Java 1.6 as minimum BREE - reasoning for this is there is no working open source pre Java 1.6 JVM. GCJ, Kaffee, JamVM just can't be counted as such. > > For new plug-ins I think we should state that we recommend Java 1.7 at the > moment. I think that this makes sense, as the platform itself moves to Java > 1.7 and this version is the lowest one that is currently maintained by > Oracle for the general public.
(In reply to Alexander Kurtakov from comment #17) > (In reply to Lars Vogel from comment #16) > > I think most of the controversial discussion is about the recommendation of > > upgrading an existing plug-in. > > My opinion on this is to recommend Java 1.6 as minimum BREE - reasoning for > this is there is no working open source pre Java 1.6 JVM. GCJ, Kaffee, JamVM > just can't be counted as such. Why not Java 1.7?
(In reply to Lars Vogel from comment #18) > (In reply to Alexander Kurtakov from comment #17) > > (In reply to Lars Vogel from comment #16) > > > I think most of the controversial discussion is about the recommendation of > > > upgrading an existing plug-in. > > > > My opinion on this is to recommend Java 1.6 as minimum BREE - reasoning for > > this is there is no working open source pre Java 1.6 JVM. GCJ, Kaffee, JamVM > > just can't be counted as such. > > Why not Java 1.7? I make a strong difference between minimum and recommended. I can see why some people would want to keep working with older jvm versions but having this at the price of having strong requirement to closed source jvm is a bit too much. So to make my statement clear: * Recommended BREE - Java 1.7 * Minimum BREE (if current maintainers have strong reasons for) - Java 1.6
(In reply to Alexander Kurtakov from comment #19) > So to make my statement clear: > * Recommended BREE - Java 1.7 > * Minimum BREE (if current maintainers have strong reasons for) - Java 1.6 I don't find a minimum BREE specified in the wiki. Can you point me to the place? For all: I edit the recommended section to recommend Java 1.7 for new plug-ins, AFAICS we call happily agree to that. Here is the new text, please adjust or revert, if you disagree with the change: https://wiki.eclipse.org/Execution_Environments#Which_Execution_Environment_should_I_use.3F now states: --------------- As discussed above, you should seek to use the smallest EE which give you all the features you require. Practically speaking, when creating a new OSGi bundle J2SE-1.7 is a reasonable starting point. Given that this version is currently actively maintainend by Oracle (see Java support by Oracle and the pervasive use of generics in both the OSGi framework and other libraries, lower EE settings are only practical in very specialized applications. -----------------
(In reply to Lars Vogel from comment #20) > (In reply to Alexander Kurtakov from comment #19) > > So to make my statement clear: > > * Recommended BREE - Java 1.7 > > * Minimum BREE (if current maintainers have strong reasons for) - Java 1.6 > > I don't find a minimum BREE specified in the wiki. Can you point me to the > place? There is none yet. > > For all: I edit the recommended section to recommend Java 1.7 for new > plug-ins, AFAICS we call happily agree to that. Here is the new text, please > adjust or revert, if you disagree with the change: > > https://wiki.eclipse.org/ > Execution_Environments#Which_Execution_Environment_should_I_use.3F now > states: > > --------------- > As discussed above, you should seek to use the smallest EE which give you What I look for is "smallest EE (but not lower than J2SE-1.6 to ensure open source availability of such an environment)" > all the features you require. Practically speaking, when creating a new OSGi > bundle J2SE-1.7 is a reasonable starting point. Given that this version is > currently actively maintainend by Oracle (see Java support by Oracle and the > pervasive use of generics in both the OSGi framework and other libraries, > lower EE settings are only practical in very specialized applications. > -----------------
(In reply to Alexander Kurtakov from comment #21) > What I look for is "smallest EE (but not lower than J2SE-1.6 to ensure open > source availability of such an environment)" I think for new plug-ins BREEs this is a good recommendation. I suggest that you edit the wiki directly and wait if someone disagrees with that change.
(In reply to Alexander Kurtakov from comment #21) I don't think that the notion of the lowest BREE would be productive. Without active project maintenance the lowest BREE rule would be automatically violated and the rules with a lot of de facto violations tend to loose people's respect. It is important to emphasize in the new policy that moving a project to a higher BREE does not require any special justification. A REFUSAL TO MOVE to a BREE corresponding to the oldest JRE receiving public updates does require specific reasons for keeping compatibility with older JREs.
I think we're done here. The suggested starting BREE has been moved to 1.7 and the wiki explicitly says that the BREE should be chosen based on the needs of the bundle/project: The execution environment listed in the table is based on the needs of the bundle and the expected use scenarios for the bundle.
This bug is about replacing a static policy linked to a specific JDK version by a dynamic one that automatically adjusts the baseline JDK version as the time passes. The change made so far, although positive, preserves the static policy by giving it a temporary face lift.
(In reply to Sergey Prigogin from comment #25) > This bug is about replacing a static policy linked to a specific JDK version > by a dynamic one that automatically adjusts the baseline JDK version as the > time passes. The change made so far, although positive, preserves the static > policy by giving it a temporary face lift. I see your point. We will discuss it in our next PMC meeting. How about this: Practically speaking, when creating a new OSGi bundle choose a BREE for which there's an officially supported target environment for the Eclipse release that you code against. [1] https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_5.xml#target_environments
(In reply to Dani Megert from comment #26) > How about this: > Practically speaking, when creating a new OSGi bundle choose a BREE for > which there's an officially supported target environment for the Eclipse > release that you code against. The above sentence sounds pretty cryptic to me. I'd like to propose the following text for the first two paragraphs of the "Which Execution Environment should I use?" section: "As discussed above, you should seek to use the lowest EE, which receives public updates by Oracle (see Java support by Oracle) and gives you all the features you require. For example, as of March 2015 the recommended EE is 1.7 since it is the lowest one receiving public updates at this time. Lower EE settings are only practical in very specialized applications. If your particular bundle requires capabilities from a later EE, then specify a higher EE, but keep in mind this may limit adoption of your bundle for applications using an older Java runtime. Be prepared to move your EE forward on regular basis to avoid forcing your project contributors to use unsupported JDKs." The following section, "I have prerequisites that require version X to run, so shouldn't I require version X too?" also needs revision. Here is a proposed text: "It is not strictly required but is an advisable thing to do. For example, if your project uses 1.4 BREE and it depends on a project that uses 1.7 BREE, that project is prevented from using java.lang.Iterable in any of its public APIs until your and other dependent projects move to at least 1.5 BREE."
(In reply to Sergey Prigogin from comment #27) > (In reply to Dani Megert from comment #26) > > How about this: > > Practically speaking, when creating a new OSGi bundle choose a BREE for > > which there's an officially supported target environment for the Eclipse > > release that you code against. > > The above sentence sounds pretty cryptic to me. > > I'd like to propose the following text for the first two paragraphs of the > "Which Execution Environment should I use?" section: > > "As discussed above, you should seek to use the lowest EE, which receives > public updates by Oracle (see Java support by Oracle) We definitely won't stick this to a particular JRE provider. That's why want to refer to the target env. table. > Be prepared to move your EE forward on regular basis to avoid forcing your > project contributors to use unsupported JDKs." Nope. This does not belong here to that wiki. > if your project uses 1.4 BREE and it depends on a project that uses 1.7 > BREE, that project is prevented from using java.lang.Iterable in any of its > public APIs until your and other dependent projects move to at least 1.5 > BREE." Nope. The required project can add APIs based on 1.7 at will, but if your project wants to use those new APIs then it will simply move to 1.7.
(In reply to Dani Megert from comment #28) > We definitely won't stick this to a particular JRE provider. That's why want > to refer to the target env. table. The link to http://www.oracle.com/technetwork/java/eol-135779.html is already in the document. > > Be prepared to move your EE forward on regular basis to avoid forcing your > > project contributors to use unsupported JDKs." > > Nope. This does not belong here to that wiki. Could you please provide rationale for this opinion. > > if your project uses 1.4 BREE and it depends on a project that uses 1.7 > > BREE, that project is prevented from using java.lang.Iterable in any of its > > public APIs until your and other dependent projects move to at least 1.5 > > BREE." > > Nope. The required project can add APIs based on 1.7 at will, but if your > project wants to use those new APIs then it will simply move to 1.7. There seems to be a misunderstanding here. The proposed text change was intended to make situations like the one encountered in bug 234331 less likely.
(In reply to Sergey Prigogin from comment #29) > (In reply to Dani Megert from comment #28) > > We definitely won't stick this to a particular JRE provider. That's why want > > to refer to the target env. table. > > The link to http://www.oracle.com/technetwork/java/eol-135779.html is > already in the document. Yes, and that's not good, and was only recently added by Lars. > > > Be prepared to move your EE forward on regular basis to avoid forcing your > > > project contributors to use unsupported JDKs." > > > > Nope. This does not belong here to that wiki. > > Could you please provide rationale for this opinion. We want to leave it up to the individual projects to decide, when and how fast they adopt new Java versions. There was never and there should never be a rule that requires a project to update their BREEs.
(In reply to Dani Megert from comment #26) > [1] > https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_5.xml#target_environments > Since this bug wants to get rid of the frozen BREE, here's the dynamic link: https://www.eclipse.org/projects/project-plan.php?projectid=eclipse#target_environments
(In reply to Dani Megert from comment #31) > Since this bug wants to get rid of the frozen BREE, here's the dynamic link: > > https://www.eclipse.org/projects/project-plan. > php?projectid=eclipse#target_environments OK, the link to the project plan will work. We still need to address the BREE stagnation issue for existing projects by emphasizing advantages of moving BREE forward (comment #10) and setting expectation that BREEs of existing plugins should be adjusted at least once a year unless there is an important reason not to do that.
What is the status here? Is there anything still pending?
Closing. In case anyone has anything to finish please make it clear.
