Hello,
I have just upgraded to Fedora 21. There is only OpenJDK 8 on F21. I need Oracle JDK 7 for Android Development so I have set that as my system default so that I can use it with Android Studio too. Eclipse Luna crashes with JDK 7. As per this bug report [1] Eclipse Luna requires Java 8 on F21. Upstream Eclipse Luna requires JDK 7 or above. How can I use Eclipse Luna on F21 with Oracle JDK 7 as default?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1123853
On 30 October 2014 08:46, Sudhir Khanger ml@sudhirkhanger.com wrote:
Hello,
I have just upgraded to Fedora 21. There is only OpenJDK 8 on F21. I need Oracle JDK 7 for Android Development so I have set that as my system default so that I can use it with Android Studio too. Eclipse Luna crashes with JDK 7. As per this bug report [1] Eclipse Luna requires Java 8 on F21. Upstream Eclipse Luna requires JDK 7 or above. How can I use Eclipse Luna on F21 with Oracle JDK 7 as default?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1123853
-- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Hi,
Why does Android Development require JDK 7? Maybe we can fix it so that you don't need to install a third party JDK.
On 30 Oct 2014, at 10:31, Mat Booth wrote:
On 30 October 2014 08:46, Sudhir Khanger ml@sudhirkhanger.com wrote:
Hello,
I have just upgraded to Fedora 21. There is only OpenJDK 8 on F21. I need Oracle JDK 7 for Android Development so I have set that as my system default so that I can use it with Android Studio too. Eclipse Luna crashes with JDK 7. As per this bug report [1] Eclipse Luna requires Java 8 on F21. Upstream Eclipse Luna requires JDK 7 or above. How can I use Eclipse Luna on F21 with Oracle JDK 7 as default?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1123853
-- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Hi,
Why does Android Development require JDK 7? Maybe we can fix it so that you don't need to install a third party JDK.
I believe Android Studio that is based on Intellij is hitting the issues of swing and awt having bugs/issues that affects Intellij too thus they recommend using Java 7 and even Java 6 if you want to have best experience.
But afaik they *should* run with Java 8. What errors are you getting ?
To solve it though you should be able to setup the actual javavm in the eclipse.ini you launch with.
On 10/30/2014 09:46 AM, Sudhir Khanger wrote:
Hello,
I have just upgraded to Fedora 21. There is only OpenJDK 8 on F21. I need Oracle JDK 7 for Android Development so I have set that as my system default so that I can use it with Android Studio too. Eclipse Luna crashes with JDK 7. As per this bug report [1] Eclipse Luna requires Java 8 on F21. Upstream Eclipse Luna requires JDK 7 or above. How can I use Eclipse Luna on F21 with Oracle JDK 7 as default?
Dont use oracle blob. If you need 7, rebuild f20 openjdk7 packages. Then you will have two jdks, and will be able to switrhc among them via alternatives.
J.
On 30 Oct 2014, at 11:06, Jiri Vanek wrote:
On 10/30/2014 09:46 AM, Sudhir Khanger wrote:
Hello,
I have just upgraded to Fedora 21. There is only OpenJDK 8 on F21. I need Oracle JDK 7 for Android Development so I have set that as my system default so that I can use it with Android Studio too. Eclipse Luna crashes with JDK 7. As per this bug report [1] Eclipse Luna requires Java 8 on F21. Upstream Eclipse Luna requires JDK 7 or above. How can I use Eclipse Luna on F21 with Oracle JDK 7 as default?
Dont use oracle blob. If you need 7, rebuild f20 openjdk7 packages. Then you will have two jdks, and will be able to switrhc among them via alternatives.
Not a viable option for those that want to use i.e. JavaFX.
But just for me to learn - supporting multiple versions of Java is an important part of many java frameworks and applications.
Thus its surprising to me if fedora does not provide access to multiple builds of java for such testing. Does Fedora really only provide *one* Java runtime to install and test against ?
On 10/30/2014 11:20 AM, Max Rydahl Andersen wrote:
Thus its surprising to me if fedora does not provide access to multiple builds of java for such testing. Does Fedora really only provide *one* Java runtime to install and test against ?
Fedora 20 used to have 3 different Java versions (5, 7, 8). OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
On 30 Oct 2014, at 11:46, Mikolaj Izdebski wrote:
On 10/30/2014 11:20 AM, Max Rydahl Andersen wrote:
Thus its surprising to me if fedora does not provide access to multiple builds of java for such testing. Does Fedora really only provide *one* Java runtime to install and test against ?
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ?
(just trying to understand the logic/intent)
----- Original Message -----
From: "Max Rydahl Andersen" manderse@redhat.com To: "Mikolaj Izdebski" mizdebsk@redhat.com Cc: java-devel@lists.fedoraproject.org Sent: Thursday, October 30, 2014 9:24:36 PM Subject: Re: [fedora-java] Eclipse Luna on Fedora 21 and JDK 8 requirement
On 30 Oct 2014, at 11:46, Mikolaj Izdebski wrote:
On 10/30/2014 11:20 AM, Max Rydahl Andersen wrote:
Thus its surprising to me if fedora does not provide access to multiple builds of java for such testing. Does Fedora really only provide *one* Java runtime to install and test against ?
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ?
1. Fedora can not legally redistribute Oracle JDK. 2. Fedora can not distribute something that Fedora developers can not support if there is a problem in it (as it is with Oracle JDK).
Alexander Kurtakov Red Hat Eclipse team
(just trying to understand the logic/intent)
/max http://about.me/maxandersen -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
How does fedora handle it when a package stops being maintained midstream with not proper warning ? Do they get removed or just lets getting be stale ?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
Thus is the answer to that to tell users to have their custom eclipse.ini pointing at the oracle JDK 7 and then launch eclipse pointing to the vm ?
Like 'eclipse --launcher.ini <ini.location>'
As described in https://wiki.eclipse.org/Eclipse.ini and http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.i...
or is there any known problems with that ?
On 31 October 2014 08:18, Max Rydahl Andersen manderse@redhat.com wrote:
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes
- no one volunteered to do it. You know it's always a matter of "who will
do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7
was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not
stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 08:18, Max Rydahl Andersen manderse@redhat.com wrote:
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7
was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not
stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the system. While newer JDKs are able to target older runtimes, there are cases where one can introduce source-incompatible changes that work in a newer JDK, but not in an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For instance, this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 source-compatible, but the actual JDK6 compiler treats as an error. I had to abandon my use of Fedora 20 as a development environment for our project, and revert to CentOS6 in order to guarantee I wasn't introducing source that was incompatible with JDK6. Not making older JDKs (even stale ones) available is likely to discourage Java developers from using Fedora as a development platform.
Personally, unlike the original poster, I don't care which JVM Eclipse is running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do care about which JDKs are available on the system that Eclipse can launch to build projects, because that affects whether I can use Fedora as my development platform on team projects where some team members are using older JDKs (which should be fine, until the project bumps its minimum JVM dependency).
On 31 October 2014 15:37, Christopher ctubbsii-fedora@apache.org wrote:
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 08:18, Max Rydahl Andersen manderse@redhat.com wrote:
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7
was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not
stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the system. While newer JDKs are able to target older runtimes, there are cases where one can introduce source-incompatible changes that work in a newer JDK, but not in an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For instance, this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 source-compatible, but the actual JDK6 compiler treats as an error. I had to abandon my use of Fedora 20 as a development environment for our project, and revert to CentOS6 in order to guarantee I wasn't introducing source that was incompatible with JDK6. Not making older JDKs (even stale ones) available is likely to discourage Java developers from using Fedora as a development platform.
Doesn't Eclipse's "Execution Environments" solve this in your case? When you select the Java 6 EE for example, then Eclipse should tell you when you attempt to use syntax or features that are not available in Java 6. It's arguably a bug in Eclipse if this is not true.
Personally, unlike the original poster, I don't care which JVM Eclipse is running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do care about which JDKs are available on the system that Eclipse can launch to build projects, because that affects whether I can use Fedora as my development platform on team projects where some team members are using older JDKs (which should be fine, until the project bumps its minimum JVM dependency).
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On Fri, Oct 31, 2014 at 11:43 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 15:37, Christopher ctubbsii-fedora@apache.org wrote:
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 08:18, Max Rydahl Andersen manderse@redhat.com wrote:
> Fedora 20 used to have 3 different Java versions (5, 7, 8). >
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7
> was removed from F21 because its support will end before F21 EOL and > we > don't want to ship software not supported by upstream. >
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will
not stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the system. While newer JDKs are able to target older runtimes, there are cases where one can introduce source-incompatible changes that work in a newer JDK, but not in an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For instance, this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 source-compatible, but the actual JDK6 compiler treats as an error. I had to abandon my use of Fedora 20 as a development environment for our project, and revert to CentOS6 in order to guarantee I wasn't introducing source that was incompatible with JDK6. Not making older JDKs (even stale ones) available is likely to discourage Java developers from using Fedora as a development platform.
Doesn't Eclipse's "Execution Environments" solve this in your case? When you select the Java 6 EE for example, then Eclipse should tell you when you attempt to use syntax or features that are not available in Java 6. It's arguably a bug in Eclipse if this is not true.
No, that's the problem. I don't think Eclipse can guarantee compatibility for an older version of Java if it can't find a strictly-compatible "Installed JRE" to use as the Execution Environment. It will map a newer, "compatible", version of Java to build projects which specify the older version, but it will complain with loud warnings about not being able to find a "strictly compatible" JRE ("Build path specifies execution environment XXXXXX. There are no JREs installed in the workspace that are strictly compatible with this environment."). From what I understand, this error message is really warning about the lack of a compatible bootstrap classpath (-bootclasspath) when cross-compiling.
That's precisely why it's so important to have other JDKs available.... so Eclipse can use these as strictly compatible execution environments for cross-compiling to an older version.
Personally, unlike the original poster, I don't care which JVM Eclipse is
running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do care about which JDKs are available on the system that Eclipse can launch to build projects, because that affects whether I can use Fedora as my development platform on team projects where some team members are using older JDKs (which should be fine, until the project bumps its minimum JVM dependency).
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- Mat Booth http://fedoraproject.org/get-fedora
* Christopher ctubbsii-fedora@apache.org [2014-10-31 11:37]:
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 08:18, Max Rydahl Andersen <manderse@redhat.com> wrote: Fedora 20 used to have 3 different Java versions (5, 7, 8). ok, why no Java 6 ? Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :) Fair enough. OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream. So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ? Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM. Yeah, this is similar experience for developers on all other platforms so its expected/assumed. No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ? 1. Fedora can not legally redistribute Oracle JDK. I know - hence why I would think having a openjdk 7 build would make sense. 2. Fedora can not distribute something that Fedora developers can not support if there is a problem in it (as it is with Oracle JDK). so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ? Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the system. While newer JDKs are able to target older runtimes, there are cases where one can introduce source-incompatible changes that work in a newer JDK, but not in an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For instance, this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 source-compatible, but the actual JDK6 compiler treats as an error. I had to abandon my use of Fedora 20 as a development environment for our project, and revert to CentOS6 in order to guarantee I wasn't introducing source that was incompatible with JDK6. Not making older JDKs (even stale ones) available is likely to discourage Java developers from using Fedora as a development platform.
This is a bug -- did you file it with us? If so, what was the conclusion? If -target 1.6 was specified, it should have been able to run it on 6 without issues and any problems encountered are certainly bugs.
Deepak
Personally, unlike the original poster, I don't care which JVM Eclipse is running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do care about which JDKs are available on the system that Eclipse can launch to build projects, because that affects whether I can use Fedora as my development platform on team projects where some team members are using older JDKs (which should be fine, until the project bumps its minimum JVM dependency).
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
* Deepak Bhole dbhole@redhat.com [2014-10-31 11:44]:
- Christopher ctubbsii-fedora@apache.org [2014-10-31 11:37]:
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk wrote:
On 31 October 2014 08:18, Max Rydahl Andersen <manderse@redhat.com> wrote: Fedora 20 used to have 3 different Java versions (5, 7, 8). ok, why no Java 6 ? Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :) Fair enough. OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream. So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ? Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM. Yeah, this is similar experience for developers on all other platforms so its expected/assumed. No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ? 1. Fedora can not legally redistribute Oracle JDK. I know - hence why I would think having a openjdk 7 build would make sense. 2. Fedora can not distribute something that Fedora developers can not support if there is a problem in it (as it is with Oracle JDK). so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ? Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the system. While newer JDKs are able to target older runtimes, there are cases where one can introduce source-incompatible changes that work in a newer JDK, but not in an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For instance, this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 source-compatible, but the actual JDK6 compiler treats as an error. I had to abandon my use of Fedora 20 as a development environment for our project, and revert to CentOS6 in order to guarantee I wasn't introducing source that was incompatible with JDK6. Not making older JDKs (even stale ones) available is likely to discourage Java developers from using Fedora as a development platform.
This is a bug -- did you file it with us? If so, what was the conclusion? If -target 1.6 was specified, it should have been able to run it on 6 without issues and any problems encountered are certainly bugs.
Sorry, I forgot Eclipse uses ecj. I meant that if this happens with javac that is a bug.
Deepak
Deepak
Personally, unlike the original poster, I don't care which JVM Eclipse is running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do care about which JDKs are available on the system that Eclipse can launch to build projects, because that affects whether I can use Fedora as my development platform on team projects where some team members are using older JDKs (which should be fine, until the project bumps its minimum JVM dependency).
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On Fri, Oct 31, 2014 at 11:43 AM, Deepak Bhole dbhole@redhat.com wrote:
- Christopher ctubbsii-fedora@apache.org [2014-10-31 11:37]:
On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth fedora@matbooth.co.uk
wrote:
On 31 October 2014 08:18, Max Rydahl Andersen <manderse@redhat.com>
wrote:
Fedora 20 used to have 3 different Java versions (5,
7, 8).
ok, why no Java 6 ? Besides many technical reason the biggest one is
non-technical in
my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if
someone
jumps in and say "Hey, I'll maintain Java 6, fix
problems/adopt
Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped
in
Fedora) and help them properly set their targets in build
scripts
so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :) Fair enough. OpenJDK 7 was removed from F21 because its support will end
before
F21 EOL and we don't want to ship software not supported by
upstream.
So for users most stable thing is to use Oracle JDK
builds
instead which are and will stay available ? Users can still try to use it but it's something that they
have to
do on their own - download, extract, set PATH, etc. Just
like on
every platform with Oracle JVM. Yeah, this is similar experience for developers on all other
platforms
so its expected/assumed. No separate repo with "binaries that is currently
supported but
will not stay supported for all of fedora 21 lifetime" ? 1. Fedora can not legally redistribute Oracle JDK. I know - hence why I would think having a openjdk 7 build would
make
sense. 2. Fedora can not distribute something that Fedora
developers can
not support if there is a problem in it (as it is with
Oracle JDK).
so *any* package that is known to be marked as EOL sometime in
the
future before the upcoming Fedora EOL's gets removed from that
future
Fedora release ? Even that Java 7 is still the most used and
targeted
Java version ? Maybe I misunderstand the use-case, but your projects can still
target Java
7 even if Eclipse is running on Java 8.
That's not entirely true. This only works if a true JDK7 exists on the
system.
While newer JDKs are able to target older runtimes, there are cases
where one
can introduce source-incompatible changes that work in a newer JDK, but
not in
an older JDK. This matters for collaborating on projects where some team members are not using the newer JDK to target the older runtime. For
instance,
this happened with JDK7/JDK6 on my team... JDK7 allows certain use of
generics
syntax that properly compiles to JDK6 target, and validates in Eclipse
as JDK6
source-compatible, but the actual JDK6 compiler treats as an error. I
had to
abandon my use of Fedora 20 as a development environment for our
project, and
revert to CentOS6 in order to guarantee I wasn't introducing source that
was
incompatible with JDK6. Not making older JDKs (even stale ones)
available is
likely to discourage Java developers from using Fedora as a development platform.
This is a bug -- did you file it with us? If so, what was the conclusion? If -target 1.6 was specified, it should have been able to run it on 6 without issues and any problems encountered are certainly bugs.
There is no issue with -target 1.6; the issue was with strict source compatibility with 1.6. I can't recall the specifics (it had something to do with generic type checking, because 1.7's javac can make better inferences), but that's outside the scope of this issue. The main point, as it relates here, is that there may not be strict compatibility between javac provided by different JDKs, even if javac makes a best effort attempt to parse older source. A more obvious problem is the lack of bootstrap classpaths for older -source/-target, which is known to be likely to create compiled code that is not capable of running in an older JVM (this doesn't matter if you're developing for the latest Fedora, but it matters if you're using the latest Fedora to develop for other platforms, like RHEL or Android).
Deepak
Personally, unlike the original poster, I don't care which JVM Eclipse is running on, itself (OpenJDK 8, or whatever is latest, works for me).
But, I do
care about which JDKs are available on the system that Eclipse can
launch to
build projects, because that affects whether I can use Fedora as my
development
platform on team projects where some team members are using older JDKs
(which
should be fine, until the project bumps its minimum JVM dependency).
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
* Christopher ctubbsii-fedora@apache.org [2014-10-31 14:02]:
On Fri, Oct 31, 2014 at 11:43 AM, Deepak Bhole dbhole@redhat.com wrote:
* Christopher <ctubbsii-fedora@apache.org> [2014-10-31 11:37]: > On Fri, Oct 31, 2014 at 5:35 AM, Mat Booth <fedora@matbooth.co.uk> wrote: > > On 31 October 2014 08:18, Max Rydahl Andersen <manderse@redhat.com> wrote: > > > Fedora 20 used to have 3 different Java versions (5, 7, 8). > > > ok, why no Java 6 ? > > > Besides many technical reason the biggest one is non-technical in > my eyes - no one volunteered to do it. You know it's always a > matter of "who will do the work?". I'm pretty sure that if someone > jumps in and say "Hey, I'll maintain Java 6, fix problems/ adopt > Java 6 to changes in the OS if neeeded, help strengthen the > switching between JREs, go through the Java projects(shipped in > Fedora) and help them properly set their targets in build scripts > so builds properly work on Java 6 and etc" there will be no > objection to having Java 6. :) > > > Fair enough. > > > OpenJDK 7 > was removed from F21 because its support will end before > F21 EOL and > we > don't want to ship software not supported by upstream. > > > So for users most stable thing is to use Oracle JDK builds > instead which > are and will stay available ? > > > Users can still try to use it but it's something that they have to > do on their own - download, extract, set PATH, etc. Just like on > every platform with Oracle JVM. > > > Yeah, this is similar experience for developers on all other platforms > so its expected/assumed. > > > No separate repo with "binaries that is currently supported but > will not > stay supported for all of fedora 21 lifetime" ? > > > 1. Fedora can not legally redistribute Oracle JDK. > > > I know - hence why I would think having a openjdk 7 build would make > sense. > > > 2. Fedora can not distribute something that Fedora developers can > not support if there is a problem in it (as it is with Oracle JDK). > > > so *any* package that is known to be marked as EOL sometime in the > future before the upcoming Fedora EOL's gets removed from that future > Fedora release ? Even that Java 7 is still the most used and targeted > Java version ? > > > > Maybe I misunderstand the use-case, but your projects can still target Java > 7 even if Eclipse is running on Java 8. > > > > That's not entirely true. This only works if a true JDK7 exists on the system. > While newer JDKs are able to target older runtimes, there are cases where one > can introduce source-incompatible changes that work in a newer JDK, but not in > an older JDK. This matters for collaborating on projects where some team > members are not using the newer JDK to target the older runtime. For instance, > this happened with JDK7/JDK6 on my team... JDK7 allows certain use of generics > syntax that properly compiles to JDK6 target, and validates in Eclipse as JDK6 > source-compatible, but the actual JDK6 compiler treats as an error. I had to > abandon my use of Fedora 20 as a development environment for our project, and > revert to CentOS6 in order to guarantee I wasn't introducing source that was > incompatible with JDK6. Not making older JDKs (even stale ones) available is > likely to discourage Java developers from using Fedora as a development > platform. > This is a bug -- did you file it with us? If so, what was the conclusion? If -target 1.6 was specified, it should have been able to run it on 6 without issues and any problems encountered are certainly bugs.
There is no issue with -target 1.6; the issue was with strict source compatibility with 1.6. I can't recall the specifics (it had something to do with generic type checking, because 1.7's javac can make better inferences), but that's outside the scope of this issue. The main point, as it relates here, is that there may not be strict compatibility between javac provided by different JDKs, even if javac makes a best effort attempt to parse older source. A more obvious problem is the lack of bootstrap classpaths for older -source/-target, which is known to be likely to create compiled code that is not capable of running in an older JVM (this doesn't matter if you're developing for the latest Fedora, but it matters if you're using the latest Fedora to develop for other platforms, like RHEL or Android).
Ah, yeah not much we can do (with current setup) where the older rt.jar is needed on bootstrap path :/
Deepak
Deepak > Personally, unlike the original poster, I don't care which JVM Eclipse is > running on, itself (OpenJDK 8, or whatever is latest, works for me). But, I do > care about which JDKs are available on the system that Eclipse can launch to > build projects, because that affects whether I can use Fedora as my development > platform on team projects where some team members are using older JDKs (which > should be fine, until the project bumps its minimum JVM dependency). > > -- > java-devel mailing list > java-devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/java-devel
On Fri, Oct 31, 2014 at 2:30 PM, Deepak Bhole dbhole@redhat.com wrote:
- Christopher ctubbsii-fedora@apache.org [2014-10-31 14:02]:
[snip]
There is no issue with -target 1.6; the issue was with strict source compatibility with 1.6. I can't recall the specifics (it had something
to do
with generic type checking, because 1.7's javac can make better
inferences),
but that's outside the scope of this issue. The main point, as it
relates here,
is that there may not be strict compatibility between javac provided by different JDKs, even if javac makes a best effort attempt to parse older source. A more obvious problem is the lack of bootstrap classpaths for
older
-source/-target, which is known to be likely to create compiled code
that is
not capable of running in an older JVM (this doesn't matter if you're developing for the latest Fedora, but it matters if you're using the
latest
Fedora to develop for other platforms, like RHEL or Android).
Ah, yeah not much we can do (with current setup) where the older rt.jar is needed on bootstrap path :/
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii
* Christopher ctubbsii-fedora@apache.org [2014-10-31 14:55]:
On Fri, Oct 31, 2014 at 2:30 PM, Deepak Bhole dbhole@redhat.com wrote:
* Christopher <ctubbsii-fedora@apache.org> [2014-10-31 14:02]:
[snip]
> There is no issue with -target 1.6; the issue was with strict source > compatibility with 1.6. I can't recall the specifics (it had something to do > with generic type checking, because 1.7's javac can make better inferences), > but that's outside the scope of this issue. The main point, as it relates here, > is that there may not be strict compatibility between javac provided by > different JDKs, even if javac makes a best effort attempt to parse older > source. A more obvious problem is the lack of bootstrap classpaths for older > -source/-target, which is known to be likely to create compiled code that is > not capable of running in an older JVM (this doesn't matter if you're > developing for the latest Fedora, but it matters if you're using the latest > Fedora to develop for other platforms, like RHEL or Android). > Ah, yeah not much we can do (with current setup) where the older rt.jar is needed on bootstrap path :/
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Java 8 EOL is tentatively slated for March 2017, which is well after F22 EOL (assuming F22 is released in mid-2015). Furthermore, that is a tentative date and is contingent on Java 9 being out in early 2016.
In general, Java N will be supported for upto a year after N+1 is out.
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
That is what would have happened had F21 not been delayed. If Fedora sticks to a 6-month release cycle, we should be able to have one version where N is the default and N-1 is provided for legacy, followed by removal of N-1 in subsequent released.
FWIW, we have had Java 8 in Fedora since March 2013 (a stable pre-release) and we are only now making it the default, almost 2 years later. Given our finite resources, I don't think we are jumping the gun here with making 8 the default. If someone in the community wants to pick up and maintain 7, they are always welcome to do so.
Deepak
-- Christopher L Tubbs II http://gravatar.com/ctubbsii
On Sat, Nov 1, 2014 at 12:40 AM, Deepak Bhole dbhole@redhat.com wrote:
If someone in the community wants to pick up and maintain 7, they are always welcome to do so.
What makes Eclipse Luna in F21 not run on JDK 7 installed manually? And what can be done to make it work?
On 31 October 2014 20:41, Sudhir Khanger ml@sudhirkhanger.com wrote:
On Sat, Nov 1, 2014 at 12:40 AM, Deepak Bhole dbhole@redhat.com wrote:
If someone in the community wants to pick up and maintain 7, they are always welcome to do so.
What makes Eclipse Luna in F21 not run on JDK 7 installed manually? And what can be done to make it work?
What prevents you from running Eclipse on OpenJDK 8 but still targeting your manually installed Oracle JDK 7 by adding it under "Installed JREs" in your Eclipse preferences?
What makes Eclipse Luna in F21 not run on JDK 7 installed manually? And what can be done to make it work?
A quick look at the class files shows that only batik, and sac are targeting 1.8, so if those packages could be rebuilt to target a lesser version it might be possible. Also, org.eclipse.jdt.annotation v2 targets 1.8 but it seems it has a BREE of 1.8 so Matt mentioned it should be disabled.
Could a rebuild of batik, and sac be all that's needed ?
Cheers,
----- Original Message -----
From: "Roland Grunberg" rgrunber@redhat.com To: "Sudhir Khanger" ml@sudhirkhanger.com Cc: java-devel@lists.fedoraproject.org Sent: Friday, October 31, 2014 11:38:26 PM Subject: Re: [fedora-java] Eclipse Luna on Fedora 21 and JDK 8 requirement
What makes Eclipse Luna in F21 not run on JDK 7 installed manually? And what can be done to make it work?
A quick look at the class files shows that only batik, and sac are targeting 1.8, so if those packages could be rebuilt to target a lesser version it might be possible. Also, org.eclipse.jdt.annotation v2 targets 1.8 but it seems it has a BREE of 1.8 so Matt mentioned it should be disabled.
Could a rebuild of batik, and sac be all that's needed ?
And verifying that their dependencies are also properly targetting. And this work must go upstream as maintaining such patches is not something I look for espesially with projects migrating their source version and due to not setting target *boo* your build is broken. As soon as someone gets this fix properly in upstream batik/sac/whatever and next version is released the fedora rebuild will just do the proper thing.
Alex
Cheers,
Roland Grunberg
java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
+1 for allowing cross compilation without having to resort to using oracle jdk unless really necessary.
/max http://about.me/maxandersen
On 31 Oct 2014, at 19:55, Christopher ctubbsii-fedora@apache.org wrote:
On Fri, Oct 31, 2014 at 2:30 PM, Deepak Bhole dbhole@redhat.com wrote:
- Christopher ctubbsii-fedora@apache.org [2014-10-31 14:02]:
[snip]
There is no issue with -target 1.6; the issue was with strict source compatibility with 1.6. I can't recall the specifics (it had something to do with generic type checking, because 1.7's javac can make better inferences), but that's outside the scope of this issue. The main point, as it relates here, is that there may not be strict compatibility between javac provided by different JDKs, even if javac makes a best effort attempt to parse older source. A more obvious problem is the lack of bootstrap classpaths for older -source/-target, which is known to be likely to create compiled code that is not capable of running in an older JVM (this doesn't matter if you're developing for the latest Fedora, but it matters if you're using the latest Fedora to develop for other platforms, like RHEL or Android).
Ah, yeah not much we can do (with current setup) where the older rt.jar is needed on bootstrap path :/
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
----- Original Message -----
From: "Christopher" ctubbsii-fedora@apache.org To: "Deepak Bhole" dbhole@redhat.com Cc: "Fedora Java Development List" java-devel@lists.fedoraproject.org Sent: Friday, October 31, 2014 8:55:39 PM Subject: Re: [fedora-java] Eclipse Luna on Fedora 21 and JDK 8 requirement
On Fri, Oct 31, 2014 at 2:30 PM, Deepak Bhole < dbhole@redhat.com > wrote:
- Christopher < ctubbsii-fedora@apache.org > [2014-10-31 14:02]:
[snip]
There is no issue with -target 1.6; the issue was with strict source compatibility with 1.6. I can't recall the specifics (it had something to do with generic type checking, because 1.7's javac can make better inferences), but that's outside the scope of this issue. The main point, as it relates here, is that there may not be strict compatibility between javac provided by different JDKs, even if javac makes a best effort attempt to parse older source. A more obvious problem is the lack of bootstrap classpaths for older -source/-target, which is known to be likely to create compiled code that is not capable of running in an older JVM (this doesn't matter if you're developing for the latest Fedora, but it matters if you're using the latest Fedora to develop for other platforms, like RHEL or Android).
Ah, yeah not much we can do (with current setup) where the older rt.jar is needed on bootstrap path :/
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
So do you also sign for doing the work needed incl. the security fixes and etc.? There is no policy that we should ship only single JDK as far as I know, it's a result of the resources available from my POV. To keep it on Eclipse side even if two JDKs are available in fedora I would test and target only the latest one with Eclipse unless someone joins to share the burden of verifying it works on the other one.
Alexander Kurtakov Red Hat Eclipse team
-- Christopher L Tubbs II http://gravatar.com/ctubbsii
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
So do you also sign for doing the work needed incl. the security fixes and etc.?
No I'm not and neither are you for any other non-maintained packages that might get disbanded are you ?
I'm asking to understand how things tend to work since it just seems weird we don't try at least be as broadly compatible as we can by i.e. setting default target to java7.
One part is the compile setting, the other is what runtime is supported. Those does not need to absolutely match up 1-to-1.
There is no policy that we should ship only single JDK as far as I know, it's a result of the resources available from my POV. To keep it on Eclipse side even if two JDKs are available in fedora I would test and target only the latest one with Eclipse unless someone joins to share the burden of verifying it works on the other one.
Sure, but right now the default setup prevents even testing out with Java 7.
On 18 November 2014 13:06, Max Rydahl Andersen manderse@redhat.com wrote:
[snip]
Well, what we could do is rethink the policy about not packaging currently supported JDKs, just because they are expected to not have further updates at some future time. That policy's going to bite us anyway, if the pace of Java ever reaches a point where a version of Java is released *and* EOL'd during the same window (hypothetically, Java 8 is expected to EOL during F22, and Java 9 is expected to be released and EOL'd during F22; would that mean F22 cannot include any Java version?).
Personally, I like the idea of shipping the latest as default, and the next most recent (so long as it is currently supported) as available as an SDK/devel package and just stop updating it when there aren't any more upstream updates and drop it from the next release.
So do you also sign for doing the work needed incl. the security fixes and etc.?
No I'm not and neither are you for any other non-maintained packages that might get disbanded are you ?
I'm asking to understand how things tend to work since it just seems weird we don't try at least be as broadly compatible as we can by i.e. setting default target to java7.
We mostly try to respect the compile settings used by the individual upstream projects.
If there is a non-Eclipse package that contains java 8 bytecode that you think doesn't need to contain java 8 bytecode due to poorly chosen or missing compilation settings, then please open a bug with a patch and if you CC me, I can probably find time to apply it.
One or two Eclipse bundles contain java 8 bytecode, but this is intentional and the OSGi runtime should exclude these if you run Eclipse on java 7.
One part is the compile setting, the other is what runtime is supported. Those does not need to absolutely match up 1-to-1.
There is no policy that we should ship only single JDK as far as I know,
it's a result of the resources available from my POV. To keep it on Eclipse side even if two JDKs are available in fedora I would test and target only the latest one with Eclipse unless someone joins to share the burden of verifying it works on the other one.
Sure, but right now the default setup prevents even testing out with Java 7.
/max http://about.me/maxandersen
-- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
On 31 Oct 2014, at 10:35, Mat Booth fedora@matbooth.co.uk wrote:
removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
Maybe I misunderstand the use-case, but your projects can still target Java 7 even if Eclipse is running on Java 8
Need java7 Libs to compile against and runtime to test with.
Hi Max,
* Max Rydahl Andersen manderse@redhat.com [2014-10-31 04:18]:
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes
- no one volunteered to do it. You know it's always a matter of "who will
do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
Oracle JDK7 and OpenJDK 7 will both EOL in April 2015: http://www.oracle.com/technetwork/java/eol-135779.html
So they will expire within the lifetime of Fedora 20 and 21, and it again comes down to volunteer for maintainership at that point.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
That is not the case. OpenJDK7 will EOL before 20 and 21, and despite that, we will support it in 20. OpenJDK7 has been removed only from Fedora 21.
How does fedora handle it when a package stops being maintained midstream with not proper warning ? Do they get removed or just lets getting be stale ?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
Security is the biggest reason for not doing this. Java has CPUs each quarter at the least, so within 3 months we would end up with a version with major security issues.
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
We shouldn't recommend users to use an unsupported, insecure version. I understand that that is not the case right now, but it will be within a few months of F21 being released.
The appropriate solution IMO is that users file bugs for 8 and we fix them so that everyone can benefit.
(Will let Alex answer about Eclipse part below).
Cheers, Deepak
Thus is the answer to that to tell users to have their custom eclipse.ini pointing at the oracle JDK 7 and then launch eclipse pointing to the vm ?
Like 'eclipse --launcher.ini <ini.location>'
As described in https://wiki.eclipse.org/Eclipse.ini and http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.i...
or is there any known problems with that ?
/max http://about.me/maxandersen -- java-devel mailing list java-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/java-devel
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
Oracle JDK7 and OpenJDK 7 will both EOL in April 2015: http://www.oracle.com/technetwork/java/eol-135779.html
So they will expire within the lifetime of Fedora 20 and 21, and it again comes down to volunteer for maintainership at that point.
My point is that Oracle JDK 7 is just one of many many packages you have that actually declare when they will EOL.
Other packages just stops being maintained, but still are included since it was not known the support/maintanence would stop.
Just seems like it would be good if there was a way to have these packages made available despite it is known it will stop being maintained.
- Fedora can not distribute something that Fedora developers can
not support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
That is not the case. OpenJDK7 will EOL before 20 and 21, and despite that, we will support it in 20. OpenJDK7 has been removed only from Fedora 21.
I asked if any package gets removed and you say openjdk7 will be removed. How about other packages ? just wondering if the jdk package is treated specially because there is a public EOL date on it?
How does fedora handle it when a package stops being maintained midstream with not proper warning ? Do they get removed or just lets getting be stale ?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
Security is the biggest reason for not doing this. Java has CPUs each quarter at the least, so within 3 months we would end up with a version with major security issues.
which is why I suggested having these made available separately somehow.
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
We shouldn't recommend users to use an unsupported, insecure version. I understand that that is not the case right now, but it will be within a few months of F21 being released.
The appropriate solution IMO is that users file bugs for 8 and we fix them so that everyone can benefit.
Can't really fix issues with other projects code that are dependent on Java 7 because of changes in Java 7 by fixing Java 8 :)
* Max Rydahl Andersen manderse@redhat.com [2014-11-18 07:11]:
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
Oracle JDK7 and OpenJDK 7 will both EOL in April 2015: http://www.oracle.com/technetwork/java/eol-135779.html
So they will expire within the lifetime of Fedora 20 and 21, and it again comes down to volunteer for maintainership at that point.
My point is that Oracle JDK 7 is just one of many many packages you have that actually declare when they will EOL.
Other packages just stops being maintained, but still are included since it was not known the support/maintanence would stop.
Just seems like it would be good if there was a way to have these packages made available despite it is known it will stop being maintained.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
That is not the case. OpenJDK7 will EOL before 20 and 21, and despite that, we will support it in 20. OpenJDK7 has been removed only from Fedora 21.
I asked if any package gets removed and you say openjdk7 will be removed. How about other packages ? just wondering if the jdk package is treated specially because there is a public EOL date on it?
It is a combination of EOL date and effort required for maintenance. Our work in Fedora is not just limited to security backports, but also to bug fixes and significant testing. Each release is TCK tested to ensure that it meets the spec.
While our team cannot take on this additional load as it is not priority, if someone from the community wants to step up and take responsibility for maintaining an older version as a secondary JDK, we have no issues with that.
How does fedora handle it when a package stops being maintained midstream with not proper warning ? Do they get removed or just lets getting be stale ?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
Security is the biggest reason for not doing this. Java has CPUs each quarter at the least, so within 3 months we would end up with a version with major security issues.
which is why I suggested having these made available separately somehow.
Separately how? As a secondary non-default JDK you mean, or a separate 3rd party repo like copr?
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
We shouldn't recommend users to use an unsupported, insecure version. I understand that that is not the case right now, but it will be within a few months of F21 being released.
The appropriate solution IMO is that users file bugs for 8 and we fix them so that everyone can benefit.
Can't really fix issues with other projects code that are dependent on Java 7 because of changes in Java 7 by fixing Java 8 :)
I understand. As I said above, if someone is willing to accept the responsibility for doing timely security backports and maintenance, they are welcome to do so :)
Deepak
?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
Security is the biggest reason for not doing this. Java has CPUs each quarter at the least, so within 3 months we would end up with a version with major security issues.
which is why I suggested having these made available separately somehow.
Separately how? As a secondary non-default JDK you mean, or a separate 3rd party repo like copr?
Yes. whatever works ;)
My point was that it just seemed sad that Java 7 support is being dropped because there is publicly announced EOL for it and thus gets removed upfront vs when a component just stops getting maintained then it stays in Fedora (unmaintained).
Thats at least what I got from the thread here.
I would just like to be able to say using Fedora is a good option for Java developers, and if the fedora community do not have resources to maintain OpenJDK 7 fixes should not "scorn" users trying to use Oracle JDK 7 binaries since that is basically the only practical option left for them.
That is just my opinion :)
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
We shouldn't recommend users to use an unsupported, insecure version. I understand that that is not the case right now, but it will be within a few months of F21 being released.
The appropriate solution IMO is that users file bugs for 8 and we fix them so that everyone can benefit.
Can't really fix issues with other projects code that are dependent on Java 7 because of changes in Java 7 by fixing Java 8 :)
I understand. As I said above, if someone is willing to accept the responsibility for doing timely security backports and maintenance, they are welcome to do so :)
Yeah I know ;)
----- Original Message -----
From: "Max Rydahl Andersen" manderse@redhat.com To: "Aleksandar Kurtakov" akurtako@redhat.com Cc: java-devel@lists.fedoraproject.org Sent: Friday, October 31, 2014 10:18:00 AM Subject: Re: [fedora-java] Eclipse Luna on Fedora 21 and JDK 8 requirement
Fedora 20 used to have 3 different Java versions (5, 7, 8).
ok, why no Java 6 ?
Besides many technical reason the biggest one is non-technical in my eyes - no one volunteered to do it. You know it's always a matter of "who will do the work?". I'm pretty sure that if someone jumps in and say "Hey, I'll maintain Java 6, fix problems/adopt Java 6 to changes in the OS if neeeded, help strengthen the switching between JREs, go through the Java projects(shipped in Fedora) and help them properly set their targets in build scripts so builds properly work on Java 6 and etc" there will be no objection to having Java 6. :)
Fair enough.
OpenJDK 7 was removed from F21 because its support will end before F21 EOL and we don't want to ship software not supported by upstream.
So for users most stable thing is to use Oracle JDK builds instead which are and will stay available ?
Users can still try to use it but it's something that they have to do on their own - download, extract, set PATH, etc. Just like on every platform with Oracle JVM.
Yeah, this is similar experience for developers on all other platforms so its expected/assumed.
No separate repo with "binaries that is currently supported but will not stay supported for all of fedora 21 lifetime" ?
- Fedora can not legally redistribute Oracle JDK.
I know - hence why I would think having a openjdk 7 build would make sense.
- Fedora can not distribute something that Fedora developers can not
support if there is a problem in it (as it is with Oracle JDK).
so *any* package that is known to be marked as EOL sometime in the future before the upcoming Fedora EOL's gets removed from that future Fedora release ? Even that Java 7 is still the most used and targeted Java version ?
How does fedora handle it when a package stops being maintained midstream with not proper warning ? Do they get removed or just lets getting be stale ?
If removed - why couldn't that be done for Java7 ?
If just letting get stale - why couldn't that be done for Java7 ?
And I assume the answers is you just don't have time/power to maintain it and thats is fully grokkable - but then it seems to me it would be good for users if we at least explain how they can use another Java 7 in fedora eclipse context (which was the initial question here)
Thus is the answer to that to tell users to have their custom eclipse.ini pointing at the oracle JDK 7 and then launch eclipse pointing to the vm ?
Like 'eclipse --launcher.ini <ini.location>'
As described in https://wiki.eclipse.org/Eclipse.ini and http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.i...
or is there any known problems with that ?
The problem is that eclipse uses third party libraries (xml-commons, xerces, apache-commons*, jetty, batik, etc.) and many Java projects do not care to set their target bytecode in the build scripts. This results in if some of this projects ends up being rebuild with Java 8 it might start using Java 8 bytecode resulting in some parts of Eclipse not working or even not starting at all. I'm not staying that this is constantly a problem but it is something that has to be monitored and kept track of if we are going to tell users they can try that. And this is something that again no one with interest towards Oracle JDK 7 (my team has zero such interest) has committed to maintain. That's the main reason from my side to not care about Oracle JDK - it needs resources which I can better spend on fixing real issues.
Alex
On 11/01/2014 04:05 PM, Aleksandar Kurtakov wrote:
The problem is that eclipse uses third party libraries (xml-commons, xerces, apache-commons*, jetty, batik, etc.) and many Java projects do not care to set their target bytecode in the build scripts. This results in if some of this projects ends up being rebuild with Java 8 it might start using Java 8 bytecode resulting in some parts of Eclipse not working or even not starting at all.
I consider this as bugs in individual packages. If someone wants to make effort to list Eclipse dependencies (or Fedora Java packages, in general) which are compiled with default source/target and thus defaulting to 1.8 then I am willing to fix or help fixing these bugs.
On 1 Nov 2014, at 16:05, Aleksandar Kurtakov wrote:
Thus is the answer to that to tell users to have their custom eclipse.ini pointing at the oracle JDK 7 and then launch eclipse pointing to the vm ?
Like 'eclipse --launcher.ini <ini.location>'
As described in https://wiki.eclipse.org/Eclipse.ini and http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.i...
or is there any known problems with that ?
The problem is that eclipse uses third party libraries (xml-commons, xerces, apache-commons*, jetty, batik, etc.) and many Java projects do not care to set their target bytecode in the build scripts. This results in if some of this projects ends up being rebuild with Java 8 it might start using Java 8 bytecode resulting in some parts of Eclipse not working or even not starting at all. I'm not staying that this is constantly a problem but it is something that has to be monitored and kept track of if we are going to tell users they can try that. And this is something that again no one with interest towards Oracle JDK 7 (my team has zero such interest) has committed to maintain. That's the main reason from my side to not care about Oracle JDK - it needs resources which I can better spend on fixing real issues.
This really aren't about Oracle JDK 7, its about Java 7.
Same issue occurs if you try use a non-oracle jdk 7.
Eclipse on F21 won't be able to start with it because the target is default set to minimum Java 8. If build had set default to java7 bytecode target things probably would have been better for the enduser, right ?
And yes, I understand that is a due to resource limits but this means users that need to target Java 7 best option is to use Oracle JDK 7 binaries which actually will have the latest fixes since as far as I hear you say openjdk 7 is not being maintained for Fedora 21.
Correct ?
java-devel@lists.fedoraproject.org