"Mac OS X includes the full version of J2SE 1.5, pre-installed with
the Java Development Kit (JDK) and the HotSpot virtual machine (VM),
so you don't have to download, install, or configure anything."
Apple also preinstalled Apache, Perl, Python, ... but there are cases
where it makes sense to build packages your own, to install libraries
the way you want, not least for the simple reason that you understand
your platform better.
First I'd like to configure the Java environment myself and not by
some IDE, second I want to make sure that I do the
package/dependencies management right, third I don't want to make
different, the contrary is the case, I'd like to Learn from the Pros.
1. Basic JDK Installation
Apparently Java 5 is preinstalled. So is the SDK? Where is the root
folder for the actual Java Installation? I can't find the SDK files.
The SDK, or rather the JDK is built into the same jars and
distribution as the JRE. On Mac OS X, we have included the full JDK
with every Mac, instead of making developers download a separate
If I run
$ ls -al `which java`
that gives me the following path
I also think softlinks are useful, but links-to-links-to...?!
Is this the root foder:
Do you eventually have some tricks to make this link jungle somehow
actually not the real Java command line executables. They are dynamic
re-executors that actually run the real commands inside of
JavaVM.framework/Versions/1.x.x/Home/bin. The "switchable command
line" binaries in JavaVM.framework/Versions/A/Commands follow whatever
the user preference is set to in /Applications/Utilities/Java/Java
The first symlink in /usr/bin points to the "ideal" location of the
binary, and the second symlink is a standard Mac OS X framework
symlink which allows major frameworks revisions (A, B, C), and while
generally not used - the symlink is always present.
"Some applications look for Java's home directory (JAVA_HOME) on the
users system, especially during installation. If you need to
explicitly set this, in a shell script or an installer, set it to
This will set $JAVA_HOME to what Apple defines as the "Current JDK",
or the best Java for all of our customers on that particular release
of Mac OS X. If you need to set it to point to, say Java SE 6, the
value should be "/System/Library/Frameworks/JavaVM.framework/Versions/
-- If Apple writes "so you don't have to download, install, or
configure anything" why is JAVA_HOME not defined? Both "echo
$JAVA_HOME" give me no results.
Where should we set it for you? If there is a reasonable location we
could set this for you so that it is present in all shells, and to
graphical processes at login, please file an enhancement request at http://bugreporter.apple.com
, and we will be happy to consider it.
/Library/Java/Home is simply a convenience for those who simply need
to set $JAVA_HOME, and don't particularly care about which version it
is, or where it lives. It is an ideal value that works across every
version of Mac OS X.
-- And what is the difference between 'Versions/A' and 'Versions/
'Versions/A' is a proper Mac OS X framework, with resources, an
Info.plist, sub-frameworks, and headers that native applications link
against when they wish to instantiate a Java virtual machine in their
'Versions/1.5.0' is more of a "JDK bundle", which is not linked
against, but is a location for all code, resources, and classes that
are specific to particular version of Java. It should be a very close
analog to what you obtain from Sun when you download a JRE or JDK for
another platform. Ideally, all of the "JDK bundles" should be moved
out from JavaVM.framework/Versions, and put in a more descriptive
location like "/System/Library/Java/JavaVirtualMachines", and should
have names like "1.5.0_13", or "1.6.0_05". They should also have more
of a standard JDK layout, and contain a "bundle" directory for any
resources that need to be inside of a proper Mac OS X bundle. As
always, any suggestions about this layout or ideas about how to make
the user and developer experience easier to understand are greatly
appreciated (and potentially implemented if filed at http://bugreporter.apple.com
-- Do you define $JAVA_HOME? If yes, where? In .bash_profile?
No, we don't. But you can. If you would like us to, please let us know
I'm not sure if really understood the concept of 'classpath'. It seems
to me that there are different opinions about how to define it. Again
Apple has nothing predefined here. $CLASSPATH is empty. What is your
best practice here? Define it globally in .bash_profile or at compile
in your projects build commands?
Your current working directory is implicitly in your classpath, until
you set it yourself. Usually, when invoking java, javac, javah, etc -
you specify the classpath to the command yourself using the -classpath
argument. The $CLASSPATH environment variable is present as a
convenience, but I don't believe there is any generally accepted usage
or expectation that it is somehow set by the system or JRE installation.
4. Third party Java Libraries like JUnit
How do you manage often used third party libraries like junit? Do you
store the to a 'global' directory, or do you put the in every project?
Do you use specific global variables in .bash_profile like
We provide a number of 3rd party developer tools for Java in /usr/
share. Ant, Maven, and JUnit are all installed by default on Mac OS X
10.5 Leopard. If a developer cares about using a particular version of
JUnit, say, it is fairly common to simply include a copy with their
application. If you know you will be running exclusively on Mac OS X,
you can rely on /usr/share/junit/junit.jar pointing to some version of
I already discussed this topic a bit with other developers. Some of
the work with Maven. I don't know Maven, but it seems like a tool for
preconfigured or precompiled packages. Is it possible to install
almost every library with it? What is your opinion?
These are a lot of questions. If anyone could help me a bit with this,
I would appreciate it very much and if this going somewhere I'll write
an article about it so that it is maybe useful for others.
No problem, that's what we are all here for,
Java Runtime Engineer
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden