- From: Tom Anderson <twic@xxxxxxxxxxxxxxx>
- Date: Mon, 17 Oct 2011 00:31:05 +0100
On Sun, 16 Oct 2011, Martin Gregorie wrote:
On Sat, 15 Oct 2011 13:04:16 -0700, Roedy Green wrote:
On Fri, 14 Oct 2011 14:20:40 +0100, Tom Anderson <twic@xxxxxxxxxxxxxxx>
wrote, quoted or indirectly quoted someone who said :
That Fedora is much better.
In there anything you would want to tell programmers thinking of
developing Java on Fedora?
http://mindprod.com/jgloss/redhat.html is an entry a bit long in the
Just a bit!
It just works.
That is just about true, but i think it's glossing over some facts worth knowing.
I would identify the following points:
0. You should read:
Out of the box the RedHat distros (RHEL - RedHat Enterprise Linux - and Fedora) use OpenJava,
1. The default Java is OpenJava. I *think* a standard install does not include it, but it's easy enough to install. There is one package for the JRE (ie the 'java' program and supporting cast), called java-1.6.0-openjdk, and one for the rest of the JDK (ie the 'javac' program and supporting cast), called java-1.6.0-openjdk-devel. The javadoc is in a third package, java-1.6.0-openjdk-javadoc.
2. None of the above includes Derby, which is included in the Sun releases. That's a package simply called derby.
though you can easily switch to Oracle/Sun Java by simply downloading and installing it
5. This can be obtained in the usual place, and is an RPM file (there is also a 'compressed binary' - ignore that).
There is an important aside here for those not familiar with package management in Red Hat (or Linux generally). There are two distinct layers to package management. The lower layer is RPM - RPM files and the 'rpm' command, which is all about taking RPM files (which are bundles of files, like a fancy ZIP file) and unpacking them into the filesystem. If you give RPM a file for a package, it will do the unpacking, then remember that it did it, so it can delete the package, replace it with a new version, etc. The upper layer is YUM - repositories and the 'yum' command, which is all about dependencies and downloads. If you give YUM a package name, it will find and download the RPM for it, and also work out all the packages it depends on, and find download RPMs for those too, if necessary. It will then transactionally install all of them (or rather, ask RPM to do so). It will also know to check for updates to these packages.
The upshot of this is that if you install something from an RPM, then all you get is the installation. It is up to you to obtain the installer, install dependencies, install updates when they are released, and so on. Whereas if you install from YUM, the machine does all that for you. The critical bit there is updates: if a new bugfix release of a package is pushed out, an install from RPM does nothing at all, whereas an install from YUM will upgrade to it as a matter of routine. (I feel so sorry for users of operating systems where this is not the norm, such as Windows and most of OS X; Unix users get this wonderful up-to-dateness as standard)
6. OpenJDK is a YUM install and the Sun JDK is an RPM install. So, choosing Sun over OpenJDK means giving up painless automatic updates.
and changing the default search path ($PATH) so that compilers, etc are preferentially loaded from there rather than from OpenJava.
Whilst you can do this:
7. The right way to manage multiple installations of Java is through the standard 'alternatives' mechanism. See:
8. Being the 'default' Java means, amongst other things, that OpenJDK is a dependency of any package which uses Java. Hence, even if you install the Sun JDK, using YUM to install such a package will drag in OpenJDK - even though it won't actually be used! It's possible this won't happen if you have correctly used the alternatives mechanism, as above, but i can't guarantee it.
9. I don't think any standard installation process sets the JAVA_HOME environment variable, so add an export for that to your .bashrc (and make sure your .bash_profile sources your .bashrc - or do something different if you prefer). This is not required, but i often come across bits of software (like JBoss) which either assume or are greatly comforted by its presence.
10. There are loads of Java libraries in the package repositories, all just a few effortless keystrokes away. However! I'm not sure i really recommend getting libraries this way. Although YUM makes getting libraries easy, it doesn't help you distribute code written against the libraries - unless your consumers are also running Fedora, you are going to have to take care of packaging the dependencies yourself. If you instead use something like Ivy to get your jars, you can somewhat reasonably just distribute your ivy.xml file, or if not, use Ivy to build a zip-of-jars to distribute.
11. There are quite a few Java applications in the package repositories, and these don't have the distribution problem of the libraries. I installed Ant, Ivy, and Groovy this way. I once installed IntelliJ IDEA (community edition) this way (modulo some manual bodging of broken dependencies). I once installed Eclipse this way, but that turned out to be a terrible idea, because it couldn't update itself (or install plugins, i think) without being run as root. Essentially, its own package management fought with YUM. Bad.
(getting increasingly random ...)
12. If you use Eclipse and eGit, and do access control by client key, and your key has a passphrase, and you generate or passphrase-protect this key on your shiny new Fedora box, then you will hit a bug where eGit's internal version of SSH cannot understand the key (it only understands 3DES-encrypted keys; the current OpenSSH uses AES). You need to set the GIT_SSH environment variable to point to your ssh binary, ie to /usr/bin/ssh, to override the internal version. This is not really a Fedora-specific problem.
I'll stop now.
Well, traditionally they are the main constituent of boobs. -- Andrzej
Rosa, on why lipids are popular