New jre layout broke Maven and Ant

[Jonathan Gibbons]

Phil,

Your questions are about N years out of date, where N is somewhere 
between 5 and 15 :-(

Originally, the only clients of tools.jar were JDK tools like javac, 
javah, etc, and they had launcher support so there was no issue. It's 
only with the advent of additional tools that want to get direct API 
access to tools like javac that we have an issue with folk wanting 
direct access to tools.jar. And even then, it was easier for such tools 
to deal with the existing layout of existing JDK installations than to 
propose and deal with different ways to access everything.

Going forward, JDK 8 will have Jigsaw, which will fix issues like this. 
And that will be fun :-)

-- Jon

On 09/30/2011 05:42 PM, Phil Race wrote:
> So we make people who need to use the code in tools.jar jump through 
> fragile hoops to
> find the classes there ? Why would you *not* add the jars and native 
> libs to the paths
> used by "java" in the JDK directory ?
>
> If tools.jar (and others) are needed by apps, they should be available 
> to them without
> knowing the directory structure of the JDK.
>
> -phil.
>
> On 9/30/11 5:26 PM, Jonathan Gibbons wrote:
>> Phil,
>>
>> If you invoke $JDK/bin/java, you simply end up in $JDK/jre/bin/java.
>>
>> Tools like javac are handled by the launcher and have thier own magic.
>>
>> -- Jon
>>
>>
>> On 09/30/2011 09:23 AM, Phil Race wrote:
>>> I suppose I'm not seeing how this just now arises since I've always 
>>> assumed that apps that need tools.jar -
>>> or the other stuff in the JDK/lib directory should be using 
>>> $JDK/bin/java, not $JDK/jre/bin/java.
>>> I've further supposed that tools.jar is then automatically on the 
>>> classpath.
>>> I assume that "javac" works .. and $JDK/bin, and is finding rt.jar 
>>> is in the JRE subdirectory.
>>>
>>> -phil.
>>>
>>> On 9/30/11 4:01 PM, Eric Richardson wrote:
>>>> Hi,
>>>>
>>>> Some time back, Michael Franz and I experimented with compiling
>>>> Icetea/bsd-port/zero on Mac OSX PowerPC. We ran into the fact that the
>>>> Icetea harness expected a standard JDK/JRE layout on the file system.
>>>> We managed to create a script to symlink and copy some things about
>>>> and Michael managed to make it so the Mac OSX Java 5 could bootstrap
>>>> the system.
>>>>
>>>> Anyway, to make this short, I think it is a good idea if the layout is
>>>> the same across OS platforms if possible - it really reduces
>>>> relearning when moving from one OS to the other.
>>>>
>>>> Just my 2 cents,
>>>> Eric
>>>>
>>>> On Fri, Sep 30, 2011 at 9:21 AM, Henri 
>>>> Gomez<henri.gomez at gmail.com>  wrote:
>>>>>> Yes. the assumption is that you can always walk up one directory 
>>>>>> and find the JDK, but that's no longer true, because the 
>>>>>> 1.7.0.jre bundle has to be an atomic Mac OS X bundle that can be 
>>>>>> placed inside of another app bundle. Ideally, and IDE which 
>>>>>> contains a 1.7.0.jdk bundle will contain all it needs inside of 
>>>>>> itself to generate .jre based app bundles, or whole new copy of 
>>>>>> itself with a .jdk bundle.
>>>>>>
>>>>>> My usual trick would be to make a "jdk" symlink to ../../../ 
>>>>>> inside of 1.7.0.jre/Contents/Home, and have the tools just look 
>>>>>> for a "jdk" directory, but my experience with adding backwards 
>>>>>> pointing symlinks has not been popular with some folks that are 
>>>>>> dependent on zip-based archiving. So, is there a better alternative?
>>>>> I understand and commented JIRA.
>>>>>
>>>>> First proposal :
>>>>>
>>>>> Packaging it differently
>>>>>
>>>>> * OpenJDK 7 OSX atomic bundle (specific package, ie a plain 
>>>>> zip/tarball)
>>>>> * OpenJDK 7 OSX JDK runtime (same layout Windows or Linux)
>>>>>
>>>>> Packagers/Bundlers will more than likely prefer to use .zip/tarball
>>>>> file, not something mounted from DMG/PKG (I got one issue one
>>>>> openjdk-osx-build).
>>>>>
>>>>> So OpenJDK 7 OSX will contains a standard OpenJDK layout + a
>>>>> zip/tarballcontaining atomic Mac OS X bundle ready to use for
>>>>> packagers.
>>>>>
>>>>> Second proposal :
>>>>>
>>>>> Why not just copying 1.7.0.jre content into jre for now ?
>>>>>
>>>
>>
>