Community
Participate
Working Groups
All EPP packages define a minimum Java version in their eclipse.ini file with the osgi.requiredJavaVersion argument. If this version requirement cannot be met, the package cannot be started and an error dialog is shown to the user. With bug 401310 we incremented this minimum requirement from 1.5 to 1.6. Oracle does not provide public updates for Java 6 SE since Feb 2013 [1]. In a recent discussion on epp-dev [2] there was a lot of agreement that we should move forward. With this request I propose to increment this setting again for all packages to Java 7 for the Luna release. [1] http://www.oracle.com/technetwork/java/eol-135779.html [2] http://dev.eclipse.org/mhonarc/lists/epp-dev/msg02837.html
Normally I do not like restrictions unless there is a reason for it (as, sounds like there is for some packages, such as cdt and linux tools) ... I know I still use by IBM VM v6 sometimes ... but do not know anyone else who does :) -- i.e. do not know if there are "adopter requirements" for it. so 1) I'd suggest there be a "reason" stated (a reason other than one vendor's VM policy ... I've no idea what others say or what other options there are) ... but there should be a reason like "less maintenance work for committers" or something and 2) suggest the change be made early (for M4?) so plenty of time for community feedback.
To me, reason number one is that I believe it makes sense to define a minimum that is *the same for all packages*. AFAIK JRE version 7 is provided by all major JRE vendors, and my assumption is that it is being used by the majority of our users. My old colleagues from IBM's JTC deliver it since Oct 2011 [1], the majority of Windows users are probably downloading theirs from Oracle, many/most Linux distributors are shipping their distros with an OpenJDK, Mac OSX users should have a JRE with level 7 as well. All in all I don't see that this minimum version requirement would do harm. But some of the packages seem to require at least version 7 of Java. If there's a package that contains bundles with a BREE 1.7 and a user starts this package on a JRE <1.7, these bundles won't be started. Silently and without user feedback. To me this user experience is much worse compared to a message dialog with a warning that this package can only be run on a JRE >=1.7. CDT and LinuxTools are just two examples. By looking into the current Luna repository I find additional projects that deliver 1.7-only bundles, e.g. Gyrex and Jetty. (Before s.o. is asking: No, I haven't checked if those bundles are part of any package.) Reason number two is that there may be security holes in these old JRE versions, and without updates to these old versions no one will be fixing them. Maybe there are "adopter requirements". I don't know the best way to get their feedback. The best I can think of is a discussion on a bug report and a change early in the release cycle to give them time to object. [1] https://www.ibm.com/developerworks/java/jdk/lifecycle/
(In reply to David Williams from comment #1) > but there should be a reason like "less maintenance work for > committers" or something I think that's a no brainer. If we set the minimum JRE version to Java 7 for all packages than we don't need to test anymore on Java 6. Markus, do you know if there is a possibility in the launcher to bring up a pop up if the Java version is too low?
(In reply to Gunnar Wagenknecht from comment #3) > Markus, do you know if there is a possibility in the launcher to bring up a > pop up if the Java version is too low? Yep, there is... you can test/simulate it yourself. Change the entry in the eclipse.ini of any package to -Dosgi.requiredJavaVersion=1.8 and start it with a JRE 1.7. Then you'll get an error dialog "Incompatible JVM" and a message such as "Version 1.7.x of the JVM is not suitable for this product. Version: 1.8 or greater is required."
As a reminder if we decide to use 1.7 as minimum requirement: - eclipse.ini files of packages need to be updated - http://wiki.eclipse.org/Eclipse/Installation needs some changes and - the "Hint" on the download page needs to be adjusted (http://www.eclipse.org/downloads/)
(In reply to Gunnar Wagenknecht from comment #3) > (In reply to David Williams from comment #1) > > but there should be a reason like "less maintenance work for > > committers" or something > > I think that's a no brainer. If we set the minimum JRE version to Java 7 for > all packages than we don't need to test anymore on Java 6. > > > Markus, do you know if there is a possibility in the launcher to bring up a > pop up if the Java version is too low? Could this imply that the platform bundles can all move to Java 1.7? That would also be useful IMHO so that we can use the same coding standards and methods in all platform code? I think SWT and JFace might be lower as it can be used without the platform but the rest could potentially be alligned to Java7. Is this possible?
(In reply to Lars Vogel from comment #6) > Could this imply that the platform bundles can all move to Java 1.7? > ... > Is this possible? Possible... yes. Advisable... most likely no. Changing the BREE of the Platform bundles affects a lot of adopters and has more implications and side effects than any one of us can think of. The BREE is a decision of a project, and the target audience of the Platform bundles is different from the users of the EPP packages.
(In reply to Markus Knauer from comment #7) > Possible... yes. Advisable... most likely no. Thanks for the clarification, makes sense.
If the EPP packages contain bundles that require Java 7 then I definitely agree with changing the value in eclipse.ini. As Markus says it is a better user experience to get the direct message than to get random failures. I also think it makes sense on our download page and our documentation to say Java 7 is the recommended version. However I don't like the idea of arbitrarily limiting this for a package where Java 6 actually runs fine. The idea that we are limiting it for the user's own good isn't strong enough IMO. Oracle and others do still provide paid support for Java 6 and people might have valid reasons for using it. Either way I don't think there is much impact for downstream adopters. They almost surely define their own products and have the freedom to specify this independently.
This proposal has been discussed in the 2013-12-11 Planning Council meeting. I'm copying the main part of the comment from the wiki page [1] - see the wiki for the complete summary. > There were concerns raised, and it is the advise of the Planning Council that > "minimum required" set in eclipse.ini file be set on a package-by-package > basis, based on that package's needs, instead of having same requirement for > every package, even when not needed. But, it is formally up to the EPP project > and its committers (and package maintainers) to decide, not the Planning > Council ... we are just giving advise. [1] http://wiki.eclipse.org/Planning_Council/December_11_2013#Luna_Planning
FWIW, I think having different requirements for each package will create confusion for the end user. I do hope that all packages can agree on a common Java 7 requirement.
Along with moving towards Java 7, we should keep an eye on bug 361628. It's about that p2 fails to install nested jar files when the platform is running on top of Java 7. When doing the same thing with Java 6 everything works fine. Obviously, people will be face to this issue only when they are trying to use Eclipse projects or components that contain bundles with nested jars. Admittedly, only a small number of projects and components do so. But if people need to install one of them for whatever reason AND the Eclipse Platform or the Eclipse package they are using requires Java 7 then this bug can become pretty blocking for them!
Are we in agreement on this one? Will Java 7 be required for Luna?
There were a lot of concerns raised - from the Planning Council [1] and from the Eclipse Platform team, far too many concerns to call this an agreement yet. I think we've got two options: (1) Use Java 1.7 as a minimum requirement only in the package(s) that contain bundles with this BREE requirement, or (2) Use Java 1.7 as a minimum requirement consistently in all EPP packages, independent from their content. The reasons for (2) to me are still the same: Better user experience because all packages define the same requirements and users with a Java >= 1.7 won't notice anything (Java <= 1.6 users will get a feedback about the problem. They can either choose to upgrade their JVM, or they can risk changing a single line in the eclipse.ini). (And we should keep in mind that p2 does not constrain installation based on BREE of bundles, i.e. you can install something requiring Java 1.7 running on a Java 1.6 that won't be activated after installation. I just wanted to mention this here because it hasn't been mentioned so far on this bug.) [1] http://wiki.eclipse.org/Planning_Council/December_11_2013
I would be in favor of all packages to use Java 7 only. Java 6 has been EOL for more than a month now, but it's not Eclipse contributor's responsibility (and wish) to support very old stuff as part of newer versions. There is a time when we need to move forward to be more productive and innovative, and we should not be slowed down by a few users who are reluctant to change. If they're ok to stick with old Java, they'll probably be OK to stick with Kepler... So big +1 for Java 7 in EPP packages, and allow all Eclipse projects to move to Java 7 when they can benefit from it.
There are other Java 6 implementations that are still in support. There are customers who *can't* move off Java 6 yet; its not just reluctance. To force all packages to require Java 7, even when they don't need to, seems somewhat draconian, so -1.
(In reply to John Pitman from comment #16) > There are customers who *can't* move off Java 6 yet; its not just reluctance. And can't those customer stick with Luna or earlier, and we say that Eclipse projects and packages are free to use Java 7 after that? It would seem fair for everyone (commercial providers who have expected Luna to run on Java 6, and contributors who want to get to next step ASAP). > To force all packages to require Java 7, even when they don't need to, seems > somewhat draconian, so -1. It's a chicken-egg problem, if package don't give green light to support Java 7, included projects won't move to Java 7; if projects don't move to Java 7, package will never need to move to Java 7.
I agree 100% with what John said in comment #9. It's ok to simplify the message on the website but we shouldn't force everyone to put unnecessary constraints in. What if someone wants to start using Java 8? Will we force all the packages to require Java 8 then? I don't think so. (In reply to Markus Knauer from comment #14) > I think we've got two options: > > (1) Use Java 1.7 as a minimum requirement only in the package(s) that > contain bundles with this BREE requirement, or > (2) Use Java 1.7 as a minimum requirement consistently in all EPP packages, > independent from their content. > > The reasons for (2) to me are still the same: Better user experience because > all packages define the same requirements That's a website / communication thing. "Recommending" Java 7 sounds good to me. > and users with a Java >= 1.7 won't > notice anything (Java <= 1.6 users will get a feedback about the problem. They wouldn't have a problem if we don't require Java 7 unnecessarily.
By looking at the changes that were approved by the package maintainers, it looks like we end up with a mix: Some package maintainers decide to require Java 1.7, mostly because they deliver bundles with that version requirement. As a reference see the changes in Gerrit. Some of them were accepted by the package maintainers, others have been rejected, (and others haven't given any feedback yet): https://git.eclipse.org/r/26174 Require Java 7 in order to start the automotive package https://git.eclipse.org/r/26176 Require Java 7 in order to start the cpp package https://git.eclipse.org/r/26177 Require Java 7 in order to start the dsl package https://git.eclipse.org/r/26178 Require Java 7 in order to start the java package https://git.eclipse.org/r/26179 Require Java 7 in order to start the jee package https://git.eclipse.org/r/26180 Require Java 7 in order to start the modeling package https://git.eclipse.org/r/26181 Require Java 7 in order to start the parallel package https://git.eclipse.org/r/26182 Require Java 7 in order to start the php package https://git.eclipse.org/r/26183 Require Java 7 in order to start the rcp/rap package https://git.eclipse.org/r/26184 Require Java 7 in order to start the reporting package https://git.eclipse.org/r/26185 Require Java 7 in order to start the scout package https://git.eclipse.org/r/26186 Require Java 7 in order to start the standard package https://git.eclipse.org/r/26187 Require Java 7 in order to start the testing package
Packages that have been updated to require Java 1.7 or higher by their package maintainers: * automotive * cpp * parallel * php * rcp * scout * standard * testing Packages that are still using the old settings (and require at least Java 1.6). Package maintainer will decide on a case by case basis in future release if and when the change their requirements: * dsl * java * jee * modeling * reporting Closing this bug for Luna.
(In reply to Markus Knauer from comment #2) > Mac OSX users should have a JRE with level 7 as well... This is not true. Users of Mac OS X Snow Leopard (10.6) are still stuck with Apple-branded Java 1.6. Installing of 1.7 from Oracle is possible, but only using a hack that involves editing of the installation bundle properties and assembling the bundle again – that is not something a common user would do. Mac OS X Snow Leopard is still in use by high percentage of Apple customers because the newer OS versions are too heavy to be run on 4+ year-old machines. Please reconsider this decision.
Java 6 is no longer supported by neither Oracle nor Apple thus if you are okey using old software use the old Eclipse that works with Java 6. About Snow Leopard this seem to be an Oracle bug of not wanting to support Snow Leopard but can be worked around with http://stackoverflow.com/questions/13536667/how-to-install-java-jdk-7-on-snow-leopard I highly recommend using Java 7 this way rather than not letting Eclipse latest dev not update to Java 7 and use Java 7 features.
Adjusting title to better describe what has been done.
