Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
Thanks, Douglas Myers-Turnbull
On Sat, Jul 23, 2011 at 02:00:24PM -0700, Douglas Myers–Turnbull wrote:
Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
The alpha change deadline is a week and three days away so this is very likely too late. If you want to try to get an exception to get this in, you need to get the Java SIG excited to do it, get the Feature page finished (with estimates of how much time it will take to finish and who will do the work) and put it before FESCo/Feature Wrangler to see if they'll grant an exception.
Judging by the state things are in now, I don't know that it looks too hopeful unless you get some Java SIG people to commit to working on it.
Maybe a better idea would be to try to make your contingency plan into a Fedora 16 feature and Java 7 as default for all of our java applications a Fedora 17 feature (that would still need a fesco exception for a late feature but if the Java 7 stack didn't affect the rest of the software on the system, it would largely be a Feature needing release notes instad of a feature needing coordination between maintainers. Those are easier to grant exceptions for.)
-Toshio
* Toshio Kuratomi a.badger@gmail.com [2011-07-23 20:03]:
On Sat, Jul 23, 2011 at 02:00:24PM -0700, Douglas Myers–Turnbull wrote:
Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
The alpha change deadline is a week and three days away so this is very likely too late. If you want to try to get an exception to get this in, you need to get the Java SIG excited to do it, get the Feature page finished (with estimates of how much time it will take to finish and who will do the work) and put it before FESCo/Feature Wrangler to see if they'll grant an exception.
Judging by the state things are in now, I don't know that it looks too hopeful unless you get some Java SIG people to commit to working on it.
This is doable by the Alpha deadline. The main holdup for us has been a lack of OpenJDK TCK for v7. The actual RPM can be written fairly quickly. We were hopeful that we'd be able to push a more tested initial version. But given the deadlines, it appears we will have to push whatever we have right now and modify/fix it as needed when we have the TCK.
Cheers, Deepak
Maybe a better idea would be to try to make your contingency plan into a Fedora 16 feature and Java 7 as default for all of our java applications a Fedora 17 feature (that would still need a fesco exception for a late feature but if the Java 7 stack didn't affect the rest of the software on the system, it would largely be a Feature needing release notes instad of a feature needing coordination between maintainers. Those are easier to grant exceptions for.)
-Toshio
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jul 25, 2011 at 11:30:23AM -0400, Deepak Bhole wrote:
- Toshio Kuratomi a.badger@gmail.com [2011-07-23 20:03]:
The alpha change deadline is a week and three days away so this is very likely too late. If you want to try to get an exception to get this in, you need to get the Java SIG excited to do it, get the Feature page finished (with estimates of how much time it will take to finish and who will do the work) and put it before FESCo/Feature Wrangler to see if they'll grant an exception.
Judging by the state things are in now, I don't know that it looks too hopeful unless you get some Java SIG people to commit to working on it.
This is doable by the Alpha deadline. The main holdup for us has been a lack of OpenJDK TCK for v7. The actual RPM can be written fairly quickly. We were hopeful that we'd be able to push a more tested initial version. But given the deadlines, it appears we will have to push whatever we have right now and modify/fix it as needed when we have the TCK.
Note: The *Feature deadline* is already passed. That's why I use the word "exception" in what I wrote.
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Hope that helps in creating a Feature plan that FESCo can grant an exception to in good conscience,
-Toshio
* Toshio Kuratomi a.badger@gmail.com [2011-07-25 15:18]:
On Mon, Jul 25, 2011 at 11:30:23AM -0400, Deepak Bhole wrote:
- Toshio Kuratomi a.badger@gmail.com [2011-07-23 20:03]:
The alpha change deadline is a week and three days away so this is very likely too late. If you want to try to get an exception to get this in, you need to get the Java SIG excited to do it, get the Feature page finished (with estimates of how much time it will take to finish and who will do the work) and put it before FESCo/Feature Wrangler to see if they'll grant an exception.
Judging by the state things are in now, I don't know that it looks too hopeful unless you get some Java SIG people to commit to working on it.
This is doable by the Alpha deadline. The main holdup for us has been a lack of OpenJDK TCK for v7. The actual RPM can be written fairly quickly. We were hopeful that we'd be able to push a more tested initial version. But given the deadlines, it appears we will have to push whatever we have right now and modify/fix it as needed when we have the TCK.
Note: The *Feature deadline* is already passed. That's why I use the word "exception" in what I wrote.
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Ah, thank you for the clarification. I wasn't aware of the above distinction in exception cases.
Hope that helps in creating a Feature plan that FESCo can grant an exception to in good conscience,
Thanks, Deepak
-Toshio
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
Bill
* Bill Nottingham notting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Opinions from others are welcome..
Cheers, Deepak
On 09:33:51 Monday 25 July 2011 Deepak Bhole wrote:
- Bill Nottingham notting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
The less duplicating packages we have - the better :). I'm all for reducing the number of jvms we ship (assuming that OpenJDK 7 doesn't break many things).
Alexander Kurtakov
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Opinions from others are welcome..
Cheers, Deepak
On 07/25/2011 04:04 PM, Deepak Bhole wrote:
- Bill Nottinghamnotting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Have you seen the list of incompatibilities?
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
Cheers, Omair
* Omair Majid omajid@redhat.com [2011-07-29 10:32]:
On 07/25/2011 04:04 PM, Deepak Bhole wrote:
- Bill Nottinghamnotting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Have you seen the list of incompatibilities?
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
Thanks. I hadn't seen the full list, but I knew it'd fairly small given how much importance compatibility has been given in the past and for 7.
Unfortunately it is not possible to gauge how much Fedora will be affected by that :/ My biggest concern would be for apps using sun.* APIs. As mentioned above though, it should be a small percentage.
Cheers, Deepak
On 07/29/2011 04:55 PM, Deepak Bhole wrote:
- Omair Majid omajid@redhat.com [2011-07-29 10:32]:
On 07/25/2011 04:04 PM, Deepak Bhole wrote:
- Bill Nottinghamnotting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Have you seen the list of incompatibilities?
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
Thanks. I hadn't seen the full list, but I knew it'd fairly small given how much importance compatibility has been given in the past and for 7.
Unfortunately it is not possible to gauge how much Fedora will be affected by that :/ My biggest concern would be for apps using sun.* APIs. As mentioned above though, it should be a small percentage.
Cheers, Deepak
I found different warning about Java 7 changes: http://www.lucidimagination.com/search/document/1a0d3986e48a9348/warning_ind...
Does it impact also our Java? Anyway you will need exception if you want Java 7 as a feature for F-16.
On 08/01/2011 11:28 AM, Marcela Mašláňová wrote:
I found different warning about Java 7 changes: http://www.lucidimagination.com/search/document/1a0d3986e48a9348/warning_ind...
That's not a Java 7 change, it's a new VM bug. The real cause is that optimizations used in an older VM are enabled by default. I still think we'll have to ship 6 and 7 in parallel.
Andrew.
On Monday 01 August 2011 13:49:38 Andrew Haley wrote:
That's not a Java 7 change, it's a new VM bug. The real cause is that optimizations used in an older VM are enabled by default. I still think we'll have to ship 6 and 7 in parallel.
As far as I know there are fixes for these bugs in OpenJDK, though. It's just that Oracle won't deliver them in their distribution of Java before update 2.
Lars
On 10:55 Fri 29 Jul , Deepak Bhole wrote:
- Omair Majid omajid@redhat.com [2011-07-29 10:32]:
On 07/25/2011 04:04 PM, Deepak Bhole wrote:
- Bill Nottinghamnotting@redhat.com [2011-07-25 15:54]:
Toshio Kuratomi (a.badger@gmail.com) said:
Robyn and I have talked about how the feature process could be adapted to allow for more late work to occur however none of that talk has turned into anything solid yet. One point that bears on this is that the Feature Owners must be willing to commit to doing all the work involved in coordination when they submit something late. In other words, if Java 7 update went in well before the feature deadline, the expectation would be that packagers whose packages depended on Java would need to adapt to Java 7. The expectation now that the Feature Freeze has passed is that the people pushing Java 7 into the repos would also need to seek out and fix all the packages that depend on them that are broken.
Would we actually be shipping only 7, or both 6 and 7?
This hasn't been debated yet, but I am very much in favour of having only 7 in Fedora 16.
If the reason for asking was w.r.t re-builds, it is unlikely that most applications will need a rebuild -- only those using deprecated APIs (which would have been deprecated for years now) and private APIs would be affected. That would likely be a small subset.
Have you seen the list of incompatibilities?
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
Thanks. I hadn't seen the full list, but I knew it'd fairly small given how much importance compatibility has been given in the past and for 7.
Unfortunately it is not possible to gauge how much Fedora will be affected by that :/ My biggest concern would be for apps using sun.* APIs. As mentioned above though, it should be a small percentage.
The old com.sun jpeg libraries would be the obvious ones to spring to mind.
Whatever list Oracle has come up with doesn't really compare to real-world use and testing.
I think we should offer both in F16.
Cheers, Deepak -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
This hasn't been debated yet, but I am very much in favour of having
only 7 in Fedora 16.
This is probably the preferred situation for everyone. Java 7 really shouldn't introduce any backwards-incompatible changes with Java 6, so I imagine it should be fine unless significant issues arise during testing. I'd also bet that's something that can be decided relatively last-minute.
Is there a list of deprecated APIs (presumably from Java 5 or earlier) that were removed in Java 7? It could help sort through what packages (by age of creation and last update) are most likely to be affected, and searches for those method calls, etc. could be performed on the packages' sources.
Thanks for all this good conversation.
Regards, Douglas
* Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbhole@redhat.com wrote:
- Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without "target=1.6", they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC:
1) Blacklist openjdk 7 from build roots for f16 -- this means that it doesn't get tested very well, though.
2) Ensure all java packages use target=1.6 -- there's no standard way to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed.
3) Drop openjdk 6 from F16 entirely
It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things.
Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16.
Thanks,
--Andy
On Fri, Aug 26, 2011 at 9:18 AM, Andy Grimm agrimm@gmail.com wrote:
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbhole@redhat.com wrote:
- Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without "target=1.6", they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC:
- Blacklist openjdk 7 from build roots for f16 -- this means that it
doesn't get tested very well, though.
- Ensure all java packages use target=1.6 -- there's no standard way
to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed.
- Drop openjdk 6 from F16 entirely
It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things.
Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16.
Thanks,
--Andy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I personally think OpenJDK 7 should become the default. I would like to have OpenJDK 6 remain in the repository, but it shouldn't be included on the DVD for installation. There are some older packages that simply won't work yet with OpenJDK 7. However, as far as I know, those packages are not included in Fedora. I don't see a good reason to enforce an OpenJDK 6 environment when OpenJDK 7 is working well with most modern Java packages. The troubles involved in having both OpenJDK 6 and OpenJDK 7 in the default Java environment is simply not worth it either.
I say that for Fedora 16, OpenJDK 7 should be on the DVD and the preferred Java environment. However, I think that OpenJDK 6 shouldn't be removed from the repositories until Fedora 17. If this isn't feasible, I'd say that Fedora should completely drop OpenJDK 6 in favor of OpenJDK 7.
Unlike some of the earlier major Java revisions, Java 7 doesn't break most modern Java applications. However, the API cleanup between Java 6 and Java 7 may contribute to some older applications no longer working as expected. As far as I know, most Java applications in Fedora don't seem to have this problem. Java 7 will also begin offering a more consistent experience on Linux, Mac OS X, and Windows because they will be using the same codebase now, since Apple is no longer maintaining their own JRE and JDK. This alone makes Java 7 more appealing to me than continuing to use Java 6.
* Andy Grimm agrimm@gmail.com [2011-08-26 10:18]:
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbhole@redhat.com wrote:
- Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
Hi Andy,
After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without "target=1.6", they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC:
- Blacklist openjdk 7 from build roots for f16 -- this means that it
doesn't get tested very well, though.
This would only be a short term solution. As soon as a package that needs Java 7 is added/updated, it will require OpenJDK7 to be removed from the blacklist.
- Ensure all java packages use target=1.6 -- there's no standard way
to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed.
Agreed. This would be too tedious.
- Drop openjdk 6 from F16 entirely
I think this is the best, but unfortunately not easily doable at the moment. Alex (akurtakov) has been working on removing 1.6.0 dependencies and has encountered cases (e.g. tomcat5) where it is not easily possible due to interfaces having changed in Java 7.
Regardless though, we need to make all packages build with 1.7 because as more packages build with 1.7, packages that require 1.6 explicitly will fail to build as the 1.6 javac won't be able to load 1.7 compiled classes.
Dropping 6 is also problematic because we don't have a TCK for 7 yet, which means 6 is the only TCK tested version in Fedora atm.
Nonetheless, I think #3 is the only realistic option that will be most permanent.
Cheers, Deepak
It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things.
Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16.
Thanks,
--Andy
* Deepak Bhole dbhole@redhat.com [2011-08-26 10:46]:
- Andy Grimm agrimm@gmail.com [2011-08-26 10:18]:
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbhole@redhat.com wrote:
- Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
Hi Andy,
After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without "target=1.6", they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC:
- Blacklist openjdk 7 from build roots for f16 -- this means that it
doesn't get tested very well, though.
This would only be a short term solution. As soon as a package that needs Java 7 is added/updated, it will require OpenJDK7 to be removed from the blacklist.
- Ensure all java packages use target=1.6 -- there's no standard way
to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed.
Agreed. This would be too tedious.
- Drop openjdk 6 from F16 entirely
I think this is the best, but unfortunately not easily doable at the moment. Alex (akurtakov) has been working on removing 1.6.0 dependencies and has encountered cases (e.g. tomcat5) where it is not easily possible due to interfaces having changed in Java 7.
Regardless though, we need to make all packages build with 1.7 because as more packages build with 1.7, packages that require 1.6 explicitly will fail to build as the 1.6 javac won't be able to load 1.7 compiled classes.
Dropping 6 is also problematic because we don't have a TCK for 7 yet, which means 6 is the only TCK tested version in Fedora atm.
Nonetheless, I think #3 is the only realistic option that will be most permanent.
Andrew Haley and I just had a chat about this.
We both agree that weaning off the 1.6 dependency is the best long-term solution. We essentially want it so that nothing in Fedora needs 1.6.
That said, we will continue to ship 1.6 since 3rd party apps may need it. We will however remove the alternatives for 1.6, so using them will require the user to manually set JAVA_HOME to /usr/lib/jvm/java-1.6.0..../ and call the java binary from that dir. This will prevent someone from accidentally switching the system alternative to 1.6 and having (1.7 built) apps fail.
Are there any major objections to the above?
In the mean time, I am going to start building all java packages currently in F16 against 1.7 only to see the scope of changes that will be needed.
Cheers, Deepak
Cheers, Deepak
It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things.
Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16.
Thanks,
--Andy
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, Aug 26, 2011 at 11:29:33AM -0400, Deepak Bhole wrote:
Andrew Haley and I just had a chat about this.
We both agree that weaning off the 1.6 dependency is the best long-term solution. We essentially want it so that nothing in Fedora needs 1.6.
That said, we will continue to ship 1.6 since 3rd party apps may need it. We will however remove the alternatives for 1.6, so using them will require the user to manually set JAVA_HOME to /usr/lib/jvm/java-1.6.0..../ and call the java binary from that dir. This will prevent someone from accidentally switching the system alterne ative to 1.6 and having (1.7 built) apps fail.
Look into environment-modules as a possible aid to the end user :
http://fedoraproject.org/wiki/Packaging:EnvironmentModules
I've always wondered why we used alternatives for java when it seems like it's a per user or per application setting rather than a per-host setting anyway.
Are there any major objections to the above?
Yeah, I'm with Peter Robinson that this change is coming too late in the cycle. Alpha has already shipped. FESCo could disagree but it *must* go to FESCo for them to give you permission.
In the mean time, I am going to start building all java packages currently in F16 against 1.7 only to see the scope of changes that will be needed. to east
Do you need a separate build tag setup so you can do this testing without disturbing normal builds?
-Toshio
* Toshio Kuratomi a.badger@gmail.com [2011-08-26 11:58]:
On Fri, Aug 26, 2011 at 11:29:33AM -0400, Deepak Bhole wrote:
Andrew Haley and I just had a chat about this.
We both agree that weaning off the 1.6 dependency is the best long-term solution. We essentially want it so that nothing in Fedora needs 1.6.
That said, we will continue to ship 1.6 since 3rd party apps may need it. We will however remove the alternatives for 1.6, so using them will require the user to manually set JAVA_HOME to /usr/lib/jvm/java-1.6.0..../ and call the java binary from that dir. This will prevent someone from accidentally switching the system alterne ative to 1.6 and having (1.7 built) apps fail.
Look into environment-modules as a possible aid to the end user :
http://fedoraproject.org/wiki/Packaging:EnvironmentModules
I've always wondered why we used alternatives for java when it seems like it's a per user or per application setting rather than a per-host setting anyway.
With Fedora, we currently only distribute GCJ and OpenJDK6, and OpenJDK6 is fully capable of running everything GCJ can (on supported archs), so there is no situation where one app needs one and another needs the other.
Introduction of 1.7 is the first such case where this may hold true. And even then, we would like the overlap to be as little as possible and switch over to Java 7 completely.
Frankly, there is little if any need for alternatives for java in Fedora given that there is only OpenJDK. However we keep it in case users want to install 3rd party JDKs/JREs via the jpackage-wrapper RPM.
Are there any major objections to the above?
Yeah, I'm with Peter Robinson that this change is coming too late in the cycle. Alpha has already shipped. FESCo could disagree but it *must* go to FESCo for them to give you permission.
Oh definitely. I intend to get FESCo approval before making the change. I just wanted to see if there were any objections here first..
In the mean time, I am going to start building all java packages currently in F16 against 1.7 only to see the scope of changes that will be needed. to east
Do you need a separate build tag setup so you can do this testing without disturbing normal builds?
I am just using mock. Since it is just to test if Java 7 can build it, I was going to install all BRs of packages that need java to build, and then just build them one after another. It might be faster this way than doing individual builds given the # of packages.
I will let you know if anything changes and I do need the tag though. Thanks for the offer!
Cheers, Deepak
-Toshio
On Fri, 2011-08-26 at 11:29 -0400, Deepak Bhole wrote:
Andrew Haley and I just had a chat about this.
We both agree that weaning off the 1.6 dependency is the best long-term solution. We essentially want it so that nothing in Fedora needs 1.6.
That said, we will continue to ship 1.6 since 3rd party apps may need it. We will however remove the alternatives for 1.6, so using them will require the user to manually set JAVA_HOME to /usr/lib/jvm/java-1.6.0..../ and call the java binary from that dir. This will prevent someone from accidentally switching the system alternative to 1.6 and having (1.7 built) apps fail.
Are there any major objections to the above?
In theory, in the long run, no. In the short term, it sounds worrying: remember the schedule -
http://rbergero.fedorapeople.org/schedules/f-16/f-16-devel-tasks.html
there are less than two months until final freeze (2011-10-17), after which you'll have no chance to mess with this stuff as none of it is going to be taken as blocking final release. That seems like quite a short time frame to make sure everything, or at least all the major things, in Fedora build and work against Java 7.
I'd say go with the 'everything is Java 7 by default and Java 6 is only around for backwards compatibility with 3rd-party stuff' plan only if you're pretty confident you can have everything building and working against Java 7, to an acceptable level of functionality, by mid-October. And be really honest with yourself about the likelihood of that happening.
And I agree with Toshio that this has to go through FESCo. It would be good to present them with as comprehensive and realistic a survey as possible of the pros and cons of the various possible approaches.
On Fri, Aug 26, 2011 at 3:18 PM, Andy Grimm agrimm@gmail.com wrote:
On Wed, Aug 3, 2011 at 6:00 PM, Deepak Bhole dbhole@redhat.com wrote:
- Douglas Myers–Turnbull dmyersturnbull@gmail.com [2011-07-25 20:53]:
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Please do!
The only work I've done (literally) is on the feature page, but feel free let me know if you need anything from me.
Hi Douglas,
Thank you once again for creating the page. I have started updating it and will add docs and other links tomorrow: https://fedoraproject.org/wiki/Features/Java7
For anyone and everyone interested, a Java 7 build is now available in the Fedora 16. I will build for rawhide in the coming days as well: http://koji.fedoraproject.org/koji/buildinfo?buildID=257034
Cheers, Deepak
After some discussion on #fedora-java over the past 24 hours, I was asked to continue the discussion here regarding the implications of openjdk 6 and 7 coexisting in F16. Right now, java packages are being built for F16 using openjdk 7, and if they are built without "target=1.6", they will fail to load under openjdk 6. (One simple example of this is xalan, see https://bugzilla.redhat.com/show_bug.cgi?id=733686 ). Some possible solutions proposed over IRC:
- Blacklist openjdk 7 from build roots for f16 -- this means that it
doesn't get tested very well, though.
- Ensure all java packages use target=1.6 -- there's no standard way
to do this across ant, mvn, javac, etc. though. You could check for 1.7 bytecode at the end of a build, but packages would still need to be individually fixed.
- Drop openjdk 6 from F16 entirely
It was also mentioned that Fedora is beginning to include some packages which build much more cleanly on openjdk 7 than they do on 6, so enforcing openjdk 6-only build roots might break some things.
Other suggestions are welcome. I don't have a strong opinion about this, just a strong interest in having a sane Java environment in F16.
I think that would have to go to FESCo for approval or at least a decision, its a fairly major change to happen post alpha where all major changes should have landed already and all major mass rebuilds should have been done.
Peter
On Fri, Aug 26, 2011 at 03:46:40PM +0100, Peter Robinson wrote:
I think that would have to go to FESCo for approval or at least a decision, its a fairly major change to happen post alpha where all major changes should have landed already and all major mass rebuilds should have been done.
+1
At this point in the F16 cycle, you have to justify changes like this. Coordinating changes is one of the things that we need to do to get the distro out on a schedule without having bad feelings between package maintainers.
-Toshio
On Mon, Jul 25, 2011 at 4:30 PM, Deepak Bhole dbhole@redhat.com wrote:
- Toshio Kuratomi a.badger@gmail.com [2011-07-23 20:03]:
On Sat, Jul 23, 2011 at 02:00:24PM -0700, Douglas Myers–Turnbull wrote:
Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
The alpha change deadline is a week and three days away so this is very likely too late. If you want to try to get an exception to get this in,
you
need to get the Java SIG excited to do it, get the Feature page finished (with estimates of how much time it will take to finish and who will do
the
work) and put it before FESCo/Feature Wrangler to see if they'll grant an exception.
Judging by the state things are in now, I don't know that it looks too hopeful unless you get some Java SIG people to commit to working on it.
This is doable by the Alpha deadline. The main holdup for us has been a lack of OpenJDK TCK for v7. The actual RPM can be written fairly quickly. We were hopeful that we'd be able to push a more tested initial version. But given the deadlines, it appears we will have to push whatever we have right now and modify/fix it as needed when we have the TCK.
Personally I would much sooner you wait until the feature deadline has passed and we've branched the release and then push it directly to the new F-17 rawhide so a better impact of what it breaks can be seen. If at that point its all fairly minor only then review and see what it would take to push back into F-16. A rushed effort will only cause chaos right when we're suppose to be tightening and stabilising the release.
If java se 7 was going to be in F-16 there should have been RCs in there for some time, the rough date for release has been known for some time and it should be planned.
Peter
On 25 lip 2011, at 17:30, Deepak Bhole wrote:
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Anything new in this topic?
As I'm trying to include JBoss AS7 in Fedora:
https://fedoraproject.org/wiki/JBossAS7
I'm very interested in having JDK7 packaged because it is required to build one of JBoss AS7 dependencies (XNIO).
Thanks!
--Marek
* Marek Goldmann mgoldman@redhat.com [2011-07-28 10:41]:
On 25 lip 2011, at 17:30, Deepak Bhole wrote:
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
I was planning to do this myself .. glad you started it :) I can take over the Feature and doing all the work if you're fine with it...
Anything new in this topic?
As I'm trying to include JBoss AS7 in Fedora:
https://fedoraproject.org/wiki/JBossAS7
I'm very interested in having JDK7 packaged because it is required to build one of JBoss AS7 dependencies (XNIO).
Hi Marek,
Yes, we are just sorting out some stuff on the team side (to figure out most feasible/maintainable approach). As soon as that is done, I will push a java-1.7.0-openjdk package.
The alpha deadline is on Tuesday and I hope (.. :) ) to have it built and in before then.
Cheers, Deepak
On Sat, 2011-07-23 at 14:00 -0700, Douglas Myers–Turnbull wrote:
Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
as I always point out when this comes up, in the hopes that it'll eventually irritate someone enough that they go fix the feature process, the option is open to simply put Java 7 in without it being a 'Fedora feature'. If you do it that way, you could do it right up to, hmm, the post-Beta final freeze without there being any firm policy grounds on which to object to the change. it's only if you declare it to be a Feature that FESCo is clearly empowered to tell you you can't do it. ;)
(I note with interest Toshio's neat caveat to this, which appears later in the thread.)
On Mon, Jul 25, 2011 at 11:22:08PM -0700, Adam Williamson wrote:
On Sat, 2011-07-23 at 14:00 -0700, Douglas Myers–Turnbull wrote:
Hi,
Just something I wanted to bring to attention:
Java 7 is slated for release (after years of hassle and heated debate) on 28 July, 2011. I think this would be an important feature to include for the Fedora 16 release, and the months between Java's release and Fedora 16's 25 October release would allow plenty of time to integrate Java 7. If I'm not mistaken, if Java 7 isn't released this time around, it won't be in Fedora until the Fedora 17 release rolls around, nearly a year (!) after Java 7 is released.
I created an unfinished, skeletal feature page here: http://fedoraproject.org/wiki/Features/Java7 Unfortunately, I don't have the knowledge to help build it. I'm announcing it here in case whoever maintains Java 6 in Fedora, or someone else, is interested.
as I always point out when this comes up, in the hopes that it'll eventually irritate someone enough that they go fix the feature process, the option is open to simply put Java 7 in without it being a 'Fedora feature'. If you do it that way, you could do it right up to, hmm, the post-Beta final freeze without there being any firm policy grounds on which to object to the change. it's only if you declare it to be a Feature that FESCo is clearly empowered to tell you you can't do it. ;)
(I note with interest Toshio's neat caveat to this, which appears later in the thread.)
Actually, I'd consider this to be very bad advice. There have been several Features over the past few releases that FESCo has decided on late. Those things were sometimes made into features only after prompting by people who realized that the changes were unannounced features.
Things that require coordination between maintainers are a feature and FESCo has a right to veto them whether the authors of the feature have followed the feature process or not. The policy encompasses anything defined as a feature:
http://fedoraproject.org/wiki/Features/Policy/Definitions
-Toshio
On Tue, 2011-07-26 at 00:05 -0700, Toshio Kuratomi wrote:
as I always point out when this comes up, in the hopes that it'll eventually irritate someone enough that they go fix the feature process, the option is open to simply put Java 7 in without it being a 'Fedora feature'. If you do it that way, you could do it right up to, hmm, the post-Beta final freeze without there being any firm policy grounds on which to object to the change. it's only if you declare it to be a Feature that FESCo is clearly empowered to tell you you can't do it. ;)
(I note with interest Toshio's neat caveat to this, which appears later in the thread.)
Actually, I'd consider this to be very bad advice. There have been several Features over the past few releases that FESCo has decided on late. Those things were sometimes made into features only after prompting by people who realized that the changes were unannounced features.
Things that require coordination between maintainers are a feature and FESCo has a right to veto them whether the authors of the feature have followed the feature process or not. The policy encompasses anything defined as a feature:
I agree! It is very bad advice, and it wasn't actually meant as advice (apologies for the very bad wording here, I had four hours of sleep last night and wrote that on the tenth hour of a train ride), but more as my traditional monthly snipe at the gap in the feature process. So, I went and did something a bit more productive:
https://fedorahosted.org/fesco/ticket/653
hope that's useful.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Aleksandar Kurtakov -
Andrew Haley -
Andrew Hughes -
Andy Grimm -
Bill Nottingham -
Deepak Bhole -
Douglas Myers–Turnbull -
Lars Seipel -
Marcela Mašláňová -
Marek Goldmann -
Neal Gompa -
Omair Majid -
Peter Robinson -
Toshio Kuratomi