Sam Pullara wrote:
> ... You might think about laying it out the
>same way or at least having a "fake" JAVA_HOME that looks like the a
>Sun layout but since you have already marked the bug I filed against
>this as "not going to fix" years ago, I can forget about that.
In this case, I suggest refiling it, mainly because the tacit assumption of
"tools.jar" has now appeared in a JSR RI. I also suggest filing a bug
against the RI, pointing out the fallacy of their assumption, or at least
bringing the non-portability of this assumption to their attention.
A work-around is to create an empty "tools.jar" file, located in the
expected place. I have used this trick when other tools assume there's a
separate tools.jar, because the class-loader hierarchy ensures that if the
classes are already in the built-in "JRE" or an extension jar they'll be
found, just not in tools.jar itself. I have yet to see this "empty
tools.jar" trick fail, but I admit I haven't tested it exhaustively: YMMV.
Extending this approach further, it might be worthwhile to start an open
source project on SourceForge whose sole purpose is to provide the scripts
and files needed to make a Mac OS X Java home look enough like a Sun Java
home to pass muster with all the tools that explicitly look for "tools.jar".
The project may have the smallest source-code base on the planet, but by
creating the SourceForge project, writing installer scripts, and generally
documenting things, it makes developers aware of the situation. It also
provides a concrete, if simple, remedy for people who only want an
install-and-go approach. This may seem silly for something so simple, but
there's more to a project than its source.
I considered attaching the source for the empty tools.jar, but figured it
was easy enough to recreate for anyone who wanted it. The instructions,
documentation, and install scripts should be straightforward to write, too.
The unit tests and integration tests, I'm less sure about.
>Possibly I should spend my time lobbying Sun to make this part of the
>specification so it would have to be laid out in a certain way to be
>compliant:
That makes sense, especially if JSR RI's are going to assume it's laid out
in a particular way. Even if you don't succeed in getting the layout
incorporated as a spec, at least Sun should make it clear that the layout
is NOT specified, so programs assuming a layout are wrong to do so.
However, just because something is in a spec doesn't necessarily mean
anything. The long-standing code for parsing jar-manifests STILL assumes
that all line-endings have a LF in them, despite every spec for JARs since
their inception saying that an isolated CR is a valid newline. Compare and
contrast thes JAR specs with the source for Manifest.FastInputStream.readLine():
<http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Name-Value pairs and Sections>
<http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Name-Value pairs and Sections>
<http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Name-Value pairs and Sections>
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
