I've been really bad about preparing the FC5 release notes for java. I wrote the followup up today, which I think covers the number 1 issue. Comments?
AG
Fedora Core does not include "Java(tm)", but it does include a tools suite and execution environment based on Free Software technologies that is capable of building and running many useful programs written in the Java programming language, including the Eclipse IDE, Tomcat, and OpenOffice.org.
In addition to the Free Software stack, Fedora Core is designed to let you install multiple Java implementations and switch between them using the "alternatives" command line tool. However, every Java system you install must be packaged using the JPackage Project's packaging guidelines.
No proprietary Java vendor currently ships their products in JPackage compatible RPMs. Do not install RPMs from vendors such as Sun Microsystems, IBM or BEA without first repackaging them using the appropriate JPackage wrapper or compatibility package. Failure to do so will lead to unpredictable results.
Once installed properly, however, the root user should be able to switch between "java" and "javac" implementations using the "alternatives" command ("alternatives --config java" and "alternatives --config javac").
Instructions on repackaging proprietary Java implementations may be found here: http://www.fedorafaq.org/fc3/custom_java.html
AG
BTW: slightly off-topic -- I'm wondering why the objections to Mono being included in the core suddenly went away. I'm on the fedora-devel list also, but saw no significant discussion on this prior to the story on slashdot some time ago.
Does this represent some change in policy by Redhat/Fedora? And if so could this facilitate the inclusion of the Sun VM in the core?
Joe.
On 1/30/06, Anthony Green green@redhat.com wrote:
Fedora Core does not include "Java(tm)", but it does include a tools suite and execution environment based on Free Software technologies that is capable of building and running many useful programs written in the Java programming language, including the Eclipse IDE, Tomcat, and OpenOffice.org.
Well, Sun _knows_ why the Sun JRE/DK doesn't get included in most distros: because the Sun redistribution license explicity requires the distributor to accept liability for damage, etc caused by the runtime. This is pretty much incompatible with the "no warranty whatsoever" set. They are working to change the license with Mustang to make it more compatible with Linux distros.
I will refrain from commenting on the Mono situation. :P
On 1/30/06, Joe Desbonnet jdesbonnet@gmail.com wrote:
BTW: slightly off-topic -- I'm wondering why the objections to Mono being included in the core suddenly went away. I'm on the fedora-devel list also, but saw no significant discussion on this prior to the story on slashdot some time ago.
Does this represent some change in policy by Redhat/Fedora? And if so could this facilitate the inclusion of the Sun VM in the core?
Joe.
On 1/30/06, Anthony Green green@redhat.com wrote:
Fedora Core does not include "Java(tm)", but it does include a tools suite and execution environment based on Free Software technologies that is capable of building and running many useful programs written in the Java programming language, including the Eclipse IDE, Tomcat, and OpenOffice.org.
-- fedora-devel-java-list mailing list fedora-devel-java-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
-- :Robert "kebernet" Cooper ::kebernet@gmail.com "To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge." --Rear Admiral Grace Hopper http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9E8759F8
"Joe" == Joe Desbonnet jdesbonnet@gmail.com writes:
Joe> BTW: slightly off-topic -- I'm wondering why the objections to Mono Joe> being included in the core suddenly went away. I'm on the fedora-devel Joe> list also, but saw no significant discussion on this prior to the Joe> story on slashdot some time ago.
All I know is what was on the list. My understanding is that, even if I did know, I couldn't say anyway. Sorry.
Joe> And if so Joe> could this facilitate the inclusion of the Sun VM in the core?
Unfortunately, the Sun VM is not open source. So, no.
Tom
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> I've been really bad about preparing the FC5 release notes Anthony> for java. I wrote the followup up today, which I think Anthony> covers the number 1 issue. Comments?
Just a nit ...
Anthony> Fedora Core does not include "Java(tm)", but it does include a tools Anthony> suite
I think it reads a bit more naturally to say 'tool suite' and not 'tools suite'. What do you think?
Nice phraseology BTW.
Tom
On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote:
Fedora Core does not include "Java(tm)", but it does include a tools suite and execution environment based on Free Software technologies that is capable of building and running many useful programs written in the Java programming language, including the Eclipse IDE, Tomcat, and OpenOffice.org.
Why the term "execution environment" rather than the "runtime environment" most Java users are familiar with from JRE?
If changed, would "capable of building and executing" then sound better?
In addition to the Free Software stack, Fedora Core is designed to let you install multiple Java implementations and switch between them using the "alternatives" command line tool.
I think the phrase "using the "alternatives" command line tool" is redundant at this point, given the later explanation of how to switch.
However, every Java system you install must be packaged using the JPackage Project's packaging guidelines.
No proprietary Java vendor currently ships their products in JPackage compatible RPMs. Do not install RPMs from vendors such as Sun Microsystems, IBM or BEA without first repackaging them using the appropriate JPackage wrapper or compatibility package. Failure to do so will lead to unpredictable results.
The word "must" in the first part bothers me, as I don't think it's strictly true.
How about something like:
The Java tools and software provided by Fedora Core follow the JPackage Project's packaging guidelines. Installing RPM or binary packages directly from vendors such as Sun Microsystems, IBM, or BEA, without first repackaging them using the appropriate JPackage wrapper or compatibility package, can lead to serious installation conflicts between implementations with unpredictable results.
Once installed properly, however, the root user should be able to switch between "java" and "javac" implementations using the "alternatives" command ("alternatives --config java" and "alternatives --config javac").
Instructions on repackaging proprietary Java implementations may be found here: http://www.fedorafaq.org/fc3/custom_java.html
I would say "If installed properly" ... rather than subconsciously push them to other implementations :)
Anyhow, despite my nits above, my real question is if there will also be something to the effect of:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. Users wishing to maintain a supported environment, by using the Free Java tools shipped with Fedora, are thus advised to only update their systems with Java packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they plan to switch to a proprietary Java runtime. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
I fell victim to the above, as once I saw that FC4 was built on top of JPackage, the first thing I did was to rush out and update to the latest and greatest from their Yum repo. The JPackage site, being geared toward proprietary JVM's, conveniently provided me with Yum instructions for my FC4 distro, with no mention of the possible hazards to my shiny new Free Java setup.
Chris Hubick wrote:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. Users wishing to maintain a supported environment, by using the Free Java tools shipped with Fedora, are thus advised to only update their systems with Java packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they plan to switch to a proprietary Java runtime. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
Amen!
On 1/31/06, Ian Pilcher i.pilcher@comcast.net wrote:
Chris Hubick wrote:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. Users wishing to maintain a supported environment, by using the Free Java tools shipped with Fedora, are thus advised to only update their systems with Java packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they plan to switch to a proprietary Java runtime. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
Amen!
Has anyone noticed the implicit contradiction between "you should use the JDK from the JPackage repo" and "you should not use the JPackage repo"?
-- Weiqi Gao (高为奇) weiqigao@gmail.com http://www.weiqigao.com/blog/
On Tue, 2006-01-31 at 14:04 -0600, Weiqi Gao wrote:
Has anyone noticed the implicit contradiction between "you should use the JDK from the JPackage repo" and "you should not use the JPackage repo"?
I tried to consistently use the specific terms "application software" versus "runtime environment" to minimize this confusion. An additional explicit note might be a good idea:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to application software packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. So although Fedora recommends the use of JPackage for installing alternate Java Runtime Environments, JPackage is not necessarily recommended for the Java application software packages which use that runtime. Users wishing to maintain a supported software platform, by using the Free Java Runtime Environment shipped with Fedora, are advised to only update their systems with Java application software packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they also plan to switch to one of their alternate/proprietary Java runtimes. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
Chris Hubick wrote:
So although Fedora recommends the use of JPackage for installing alternate Java Runtime Environments...
It's designed to _allow_ the use of alternative JREs from JPackage but I wouldn't say it _recommends_ it. As far as I'm concerned Fedora recommends using the Free Software runtime and development environment and working with us to fix any bugs or deficiencies you find.
...there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora.
There is also a good chance that unmodified JPackage applications will work just fine. GCJ 4.1's lazy loading and the fast improving Swing implementation mean that it is rapidly becoming the case that the only applications that will not work are those that use undocumented and unsupported calls to Sun-specific classes.
Cheers, Gary
On Tue, 2006-01-31 at 14:04 -0600, Weiqi Gao wrote:
Has anyone noticed the implicit contradiction between "you should use the JDK from the JPackage repo" and "you should not use the JPackage repo"?
The relationship between JPackage and Fedora Core is complicated. I wish it were simpler.
What we really have in FC is a fork of JPackage where we've removed all dependencies on non-free software, so we're only partly compatible with the JPackage repository.
From what I can tell the JPackage project is moving in that same
direction as well. They appear to be dropping "non-free" dependencies from their "free" packages. Can anybody confirm that this is their actual plan?
AG
On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote:
I've been really bad about preparing the FC5 release notes for java. I wrote the followup up today, which I think covers the number 1 issue. Comments?
We moved some of the content around to come up with this:
http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java
I'm doing clean-up for the test3 snapshot, so your changes are JIT.
Now, if you could give me some good news about packaging FOP for Extras ...
Chris Hubick -- got your comments. The content has changed since your original reply. Can you look back at the page and see which of your concerns still exist? Feel free to edit the Wiki directly. If you think you need your changes vetted, make sure that sundaram@redhat.com remains on the Cc: (though he is probably on this list already.)
- Karsten
On Wed, 2006-02-01 at 13:22 -0800, Karsten Wade wrote:
On Mon, 2006-01-30 at 15:05 -0800, Anthony Green wrote:
I've been really bad about preparing the FC5 release notes for java. I wrote the followup up today, which I think covers the number 1 issue. Comments?
We moved some of the content around to come up with this:
Chris Hubick -- got your comments. The content has changed since your original reply. Can you look back at the page and see which of your concerns still exist?
The last note says:
Jpackage is a Java software repository compatible with Fedora.
I think this language could lead to exactly the problem I had with FC4, where users will read this and run out an do a yum update from the JPP repository, not knowing it will mess up their FC Java.
Avoid installing third-party packages that are not compatible with the JPackage repository.
Do not install RPM packages from vendors such as Sun Microsystems, IBM, or BEA without first repackaging them using the appropriate JPackage wrapper or compatibility package. Failure to do so leads to unpredictable results.
I also think this language is a little strong/absolute sounding. I personally would offer more of a "doing so *can* lead to problems with the shipped solutions" stance (if you don't know what you are doing). That is to say, if you do go ahead and take a stock FC5 box and install Sun's RPM and non-jpackage Java software, as long as your path's are right, it *will* probably work.
The other thing I notice is the complete lack of another note clause resembling the proposed:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to application software packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. So although Fedora allows the use of JPackage for installing alternate Java Runtime Environments, JPackage is not necessarily recommended for the Java application software packages which use that runtime. Users wishing to maintain a supported software platform, by using the Free Java Runtime Environment shipped with Fedora, are advised to only update their systems with Java application software packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they also plan to switch to one of their alternate/proprietary Java runtimes. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
Do people not think this is a good idea then? Too verbose?
I hesitate to edit the wiki myself, as historically I have been just a lowly Fedora user, I don't know what you dev's want, and don't want to step on anyones toes, and lastly as a programmer, my spelling, punctuation, capitalization, and grammar skills need some... ehh... refinement (as if you couldn't tell already :).
On Wed, 2006-02-01 at 15:05 -0700, Chris Hubick wrote:
The last note says:
Jpackage is a Java software repository compatible with Fedora.
I think this language could lead to exactly the problem I had with FC4, where users will read this and run out an do a yum update from the JPP repository, not knowing it will mess up their FC Java.
Totally agreed. JPackage is only partially compatible with FC.
Avoid installing third-party packages that are not compatible with the JPackage repository.
Do not install RPM packages from vendors such as Sun Microsystems, IBM, or BEA without first repackaging them using the appropriate JPackage wrapper or compatibility package. Failure to do so leads to unpredictable results.
I also think this language is a little strong/absolute sounding. I personally would offer more of a "doing so *can* lead to problems with the shipped solutions" stance (if you don't know what you are doing). That is to say, if you do go ahead and take a stock FC5 box and install Sun's RPM and non-jpackage Java software, as long as your path's are right, it *will* probably work.
I like the strong wording. My understanding is that the Sun RPM won't work for certain things if you have SELinux enabled because they don't set the file attributes during install. This is something we can fix in the JPackage wrapper. I also think it's in everybody's best interest if Sun, IBM, BEA _did_ package their systems using the JPackage guidelines, so spreading the meme that it is a requirement is a good idea. In a sense, it also "breaks" alternatives, since users may put /opt/whatever in their path. Why encourage something that is just bad practice?
The other thing I notice is the complete lack of another note clause resembling the proposed:
"Please note that despite utilizing the JPackage installation guidelines, several of the Java application software packages shipped with Fedora have been slightly modified from those provided by JPackage, in order to work out of the box with the included compiler and runtime environment. Additionally, the Fedora packages also include pre-compiled fast and optimized native binary code alongside the original Java bytecode JAR files. As a result, if you modify your Yum configuration and update to application software packages shipped directly through the JPackage Yum repository, you will end up with an unpredictable mix of bytecode and binary software. So although Fedora allows the use of JPackage for installing alternate Java Runtime Environments, JPackage is not necessarily recommended for the Java application software packages which use that runtime. Users wishing to maintain a supported software platform, by using the Free Java Runtime Environment shipped with Fedora, are advised to only update their systems with Java application software packages provided through the Fedora and Fedora Extras Yum repositories, and not directly through JPackage unless they also plan to switch to one of their alternate/proprietary Java runtimes. The Fedora provided application software packages should continue to work with other Java Runtime Environments which follow JPackage guidelines, but as stated above, there is a good chance unmodified JPackage applications will not work with the default Runtime Environment shipped with Fedora."
Do people not think this is a good idea then? Too verbose?
I'd like to hear some other opinions on this. Personally, I wish there was a way to say something similar in fewer words... How about...
* A note about the JPackage Project RPM repository. Fedora Core includes many packages derived from the excellent JPackage Project. These packages have been forked to remove non-free software dependencies and to make use of GCJ's ahead-of-time compilation feature. Fedora users should use the Fedora repositories for updates to these packages, and the JPackage repository for packages not provided by Fedora.
????
AG
Anthony Green wrote:
- A note about the JPackage Project RPM repository. Fedora Core
includes many packages derived from the excellent JPackage Project. These packages have been forked to remove non-free software dependencies and to make use of GCJ's ahead-of-time compilation feature. Fedora users should use the Fedora repositories for updates to these packages, and the JPackage repository for packages not provided by Fedora.
At the very least, it need to clearly state that blindly adding the JPackage repo to one's yum configuration can have "bad consequences".
On Wed, 2006-02-01 at 17:13 -0600, Ian Pilcher wrote:
Anthony Green wrote:
- A note about the JPackage Project RPM repository. Fedora Core
includes many packages derived from the excellent JPackage Project. These packages have been forked to remove non-free software dependencies and to make use of GCJ's ahead-of-time compilation feature. Fedora users should use the Fedora repositories for updates to these packages, and the JPackage repository for packages not provided by Fedora.
At the very least, it need to clearly state that blindly adding the JPackage repo to one's yum configuration can have "bad consequences".
Does this set the right tone?
http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java
Please adjust as you see fit.
Technically this content is frozen for translation, but if we can get in a good version early enough tomorrow, I know I can squeeze it into the files being translated.
Thanks - Karsten
"Karsten" == Karsten Wade kwade@redhat.com writes:
Karsten> Does this set the right tone? Karsten> http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java
I think this is the correct URL:
http://fedoraproject.org/wiki/Docs/Beats/PackageNotesJava
This content looked reasonable to me.
BTW there is a typo in the JavaFAQ wiki page -- it says "wierd" and not "weird".
Tom
On Mon, 2006-02-06 at 12:30 -0700, Tom Tromey wrote:
"Karsten" == Karsten Wade kwade@redhat.com writes:
Karsten> Does this set the right tone? Karsten> http://fedoraproject.org/wiki/Docs/Beats/PackageNotes/Java
I think this is the correct URL:
Thanks, I had to rename it last night.
BTW there is a typo in the JavaFAQ wiki page -- it says "wierd" and not "weird".
Fixed.
Let me know what your Wiki username is, and I'll add you to the EditGroup for the future.
- Karsten
Karsten - is too late to make changes to the wiki?
I want to add a note about how people should include the results of
"which java && java -version && which javac && javac -version"
in all their java related bug reports. It's important to know what alternative somebody is using before we start looking into problems with Eclipse, etc.
AG
On Fri, 2006-02-10 at 12:34 -0800, Anthony Green wrote:
Karsten - is too late to make changes to the wiki?
It's never too late.
We take regularly scheduled snapshots for the release notes.
The shipping release notes always point to the latest snapshot, at the very top of the notes.
I want to add a note about how people should include the results of
"which java && java -version && which javac && javac -version"
in all their java related bug reports. It's important to know what alternative somebody is using before we start looking into problems with Eclipse, etc.
Since we have snapped the Wiki for test3 but are still working on fixing our build of it, I'll insert this request directly into the XML and a matching one on the Wiki.
Cheers - Karsten
Anthony> I also think it's in everybody's best interest if Sun, IBM, Anthony> BEA _did_ package their systems using the JPackage Anthony> guidelines, so spreading the meme that it is a requirement is Anthony> a good idea. In a sense, it also "breaks" alternatives, Anthony> since users may put /opt/whatever in their path. Why Anthony> encourage something that is just bad practice?
I think we ought to make a strong attempt to push this, while it could still have some effect. We can always soften it later if we don't convince upstream.
Tom
java-devel@lists.fedoraproject.org
-
Anthony Green -
Chris Hubick -
Gary Benson -
Ian Pilcher -
Joe Desbonnet -
Karsten Wade -
Robert "kebernet" Cooper -
Tom Tromey -
Weiqi Gao