Community
Participate
Working Groups
Nobody should be running Java 1.5 and lower since Oracle no longer supplies updates for security vulnerabilities in those Java versions.
A proposed patch is in https://git.eclipse.org/r/#/c/41369/
I realize I'm sort of old fashioned about this, and represent a minority point of view (but that doesn't mean I'm wrong :) ... but the BREE is not supposed to be set based on "what it's running on". For several reasons -- most of all, it limits others from using in environments "we" might not know anything about (that is, to set it "high" based on what "we" think it will be running on is an extra, unnecessary constraint). See https://wiki.eclipse.org/Execution_Environments#Which_Execution_Environment_should_I_use.3F Also, Oracle is not the only vendor that makes "VMs" and even they will provide support for it ... it's just you have to pay for it then. So, I don't that company's business policies should dictate the BREE levels we use. All that said, if there is a technical reason to move higher, I think that's fine ... as long as no known use cases that would inhibit it, but a) I think should be widely announced when such a "low level" component increase it's BREE (by two steps, or more) ... and ... Dani and Tom should be aware of it -- so have I've added them to CC. That is, they might know if there are use cases that would inhibit it, or they might know that it's "fine". At a minimum, I think the technical reasons to increase it need to be the motivation behind the bug, not that "the VM is no longer supported by Oracle". I'll also point out (which many people tend to forget) is we are not really making "an application" (which, obviously, as a whole, requires Java 6 or even 7, now ... if not Java 8 for maximum functionality) ... but we are making *components* ... that others are free to "mix and match" ... sometimes even from different development streams, if that suits their needs So I think care is needed before making this change.
(In reply to David Williams from comment #2) > > Also, Oracle is not the only vendor that makes "VMs" and even they will > provide support for it ... it's just you have to pay for it then. So, I > don't that company's business policies should dictate the BREE levels we > use. Do you have a particular JVM vendor in mind that doesn't support Java 1.6? > At a minimum, I think the technical reasons to increase it need to be the > motivation behind the bug, not that "the VM is no longer supported by > Oracle". The technical reason is pretty straightforward. Each next Java version is superior to the previous one. I don't think there is a need to provide examples here since everybody knows them. As a general rule, using a newer version of Java makes Eclipse committers and contributors more productive and code safer. On the other hand we need to support users who for a legitimate reason cannot upgrade to the latest JRE. The claim made here is that there is no legitimate reason for anybody to run Java before 1.6. This claim is very conservative, since even Java 1.6 by Oracle has not been receiving public updates since Feb 2013. Instead of assuming that in some dark corner of the world there is some secret Java vendor that still hasn't moved beyond 1.5 and that the JVMs from that vendor have to be supported, could you please provide an example of such a vendor or an organization that cannot move beyond 1.5. If you cannot provide such an example, you don't have a legitimate reason to object to this feature request. The whole discussion, frankly speaking, looks to me like an exercise in masochism. Eclipse needs an official policy for JVM support similar to http://www.oracle.com/technetwork/java/eol-135779.html so that discussions like this one never happen again and don't waste valuable time of the people involved.
Sounds like I have accidentally touched a "sort spot" here. Really, all I was trying to say it this deserved wider discussion and "community involvement". As far a "policy", I think the document I linked too earlier is the policy for the Eclipse Platform Project: https://wiki.eclipse.org/Execution_Environments#Which_Execution_Environment_should_I_use.3F I'll quote a few phrases that catch my eye: = = = = "Once a particular EE has been chosen, it should be left alone unless there is a clear advantage to moving up. Increasing your EE can create a lot of work with no real value, such as exposing your code to new warnings, deprecations, etc." "Projects should not leave these choices to chance. Dependency structures are key parts of an architecture. For example, the Eclipse Project has explicitly identified EEs for all of their bundles. These choices are documented in the project plan. The execution environment listed in the table is based on the needs of the bundle and the expected use scenarios for the bundle. For example, all of the bundles key to RCP scenarios target only J2SE-1.5." [See original for links] = = = = Perhaps you are saying that document is wrong? If so ... fine, please open a bug to have it corrected. If you mean you'd like a policy for "all projects at the Eclipse Foundation", I think they do have a policy, even if it is not one you like or agree with, and that policy is "every project's committers and PMC can decide". If you want to change that, that goes way beyond the scope of this bug. And, please, don't get me wrong ... wider discussion and community notice is all I'm asking for. In some cases, I can see lots of advantages to increasing the BREE level. I am not that familiar with "the resource layer" nor what work people have planned there. Perhaps those discussions have taken place elsewhere? And one last point, to clarify what may be misconceptions. You said: > Instead of assuming that in some dark corner of the world there is some > secret Java vendor that still hasn't moved beyond 1.5 and that the JVMs from > that vendor have to be supported, could you please provide an example of such > a vendor or an organization that cannot move beyond 1.5. If you cannot > provide such an example, you don't have a legitimate reason to object to this > feature request. It's not a matter that a "VM Vendor has moved beyond 1.5", but more a matter if there is a product (built on Eclipse platform) that still supports Java 1.5. And, I do certainly know of those (old versions of Websphere app server) -- but, as far as I know, they are not using Eclipse 4.5! I think all I have to say is "I do not know" how the many adopters of Eclipse plan to make use of 4.5 (how could any of us know?). Hence, the reason for the wider discussion and community involvement. Plus, you misunderstand if you think I am objecting to the feature request. All I am saying it this type of feature request should go through a certain process before being decided. Wide discussion and community involvement. I'll "butt out" now, and probably not respond further, because I don't want to seem like I am arguing for or against the change, and certainly not arguing against improvements even if "merely" for the sake of committers and contributors! Just saying, to repeat, it should go through a particular process before deciding. I know we are all in favor of making things easier for committers and contributors, and if that is your reason for this request, I think you should emphasize that more up front, because the stuff about "end of life" by some vendors for some VMs doesn't carry any (or, much) weight, because a "BREE" is not really about "what will the plugin be running on" ... it's more about "what is the spec level of Java used for that bundle". So, please, do keep working to make things easier for committers and contributors. It is much appreciated. I think I've said all I can and all I need to. I sincerely hope you find at least some of my comments constructive, perhaps to better "make your case", and if not, feel free to ignore them. But do let me know if I can be of help in any way.
(In reply to David Williams from comment #4) Thank you, David. Filed bug 459399.
New Gerrit change created: https://git.eclipse.org/r/41369
Additional justification for this change is contained in bug 459399, in particular https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c0, https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c10, and https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c11
Sergey, can you please explain which new language constructs you want to use in all resources bundles that are not available in current BREE? We can increase the BREE if there is a need for it for a particular bundle, but we shouldn't increase it for all bundles just because the existing BREE is old.
(In reply to Szymon Ptaszkiewicz from comment #8) The primary goal for moving to 1.6 BREE is to change the image of the code as not being maintained and to encourage community contributions. The rationale for this is described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c10 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c12. In terms of specific language constructs I'd like to be able to add @Override annotations to methods implementing interfaces. They improve readability and add extra protection when making changes. In fact, few @Override annotations have already been added in the proposed Gerrit patch. I would also like to be able to replace usages of LinkedList with ArrayDeque, which is more efficient. Please notice that org.eclipse.core.filesystem is currently at 1.4 BREE, so moving it forward enables generification, enhanced for-loops, @Override annotations and more. Generification has already been done in the proposed Gerrit patch.
(In reply to Sergey Prigogin from comment #9) > (In reply to Szymon Ptaszkiewicz from comment #8) > > The primary goal for moving to 1.6 BREE is to change the image of the code > as not being maintained and to encourage community contributions. The > rationale for this is described in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c10 and > https://bugs.eclipse.org/bugs/show_bug.cgi?id=459399#c12. This is not a valid argument because simply increasing BREE does not mean the code is maintained more actively or that is is modern. On the contrary, if you increase it, but you don't actually modernize the existing code base, then the overall outcome is worse than before changing BREE because you get a project with e.g. BREE=1.5 but its code remains non-generified and full of new warnings which is repellent. And, unfortunately, org.eclipse.core.tests.resources is one such example where BREE was updated but the code was never modernized which is worse than just letting the code be old because we pretend to make it look more modern than it actually is. Increasing BREE for that project didn't make anyone more productive and didn't produce safer code. > In terms of specific language constructs I'd like to be able to add > @Override annotations to methods implementing interfaces. They improve > readability and add extra protection when making changes. In fact, few > @Override annotations have already been added in the proposed Gerrit patch. > I would also like to be able to replace usages of LinkedList with > ArrayDeque, which is more efficient. So, if you do intend to use new language constructs to modernize code and you commit yourself to do that after/together with BREE update, then it will be highly appreciated and we can increase BREE as needed on per project basis. If this was only for the sake of increasing BREE to make it look more modern without actually modernizing the code, then this would be a no-go. > Please notice that org.eclipse.core.filesystem is currently at 1.4 BREE, so > moving it forward enables generification, enhanced for-loops, @Override > annotations and more. Generification has already been done in the proposed > Gerrit patch. Since the one big change is hard to review, my proposal is that we can do in steps: 1. Use this bug as an umbrella bug to contain justification and cover modernizing all Resources projects. 2. Open a bug for each project and block this bug. 3. Propose a Gerrit change for each of the new bugs. The change would contain BREE update as needed, required annotations (e.g. @Override, @Deprecated) and generification. 4. Then, when we are done if all the above steps, if needed, we can open separate bugs to modernize the code even more e.g. to use new classes which are more perfromant etc. but this will require separate discussion and benchmarking or referring to existing benchmarks. This way we can keep the work going per project without holding the whole modernization. Does it sound good?
(In reply to Szymon Ptaszkiewicz from comment #10) > Does it sound good? No it doesn't because it creates unnecessary work for filing 9 per-project bugs and splitting the Gerrit change into 9 separate ones. Please review and submit the Gerrit change attached to this bug as the first step. Further code cleanups will follow.
Two PMC members approved the change, so please concentrate on going forward instead of discussing it to a dead end. Thanks.
New Gerrit change created: https://git.eclipse.org/r/43122
Gerrit change https://git.eclipse.org/r/43122 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=0c67910e71af04408dd2571066d9a70b3ce0bcc2
Fixed.
(In reply to Sergey Prigogin from comment #15) > Fixed. You probably didn't have the API Tools baseline set, otherwise you've noticed the error on org.eclipse.core.filesystem.provider.FileInfo.compareTo(IFileInfo). From an API POV this is a newly added method. I've fixed that with http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=df51aad3bdc4c4e8072d517ed125b2fc74872214
(In reply to Dani Megert from comment #16) Sorry for the oversight. Thank you for fixing.
