New jre layout broke Maven and Ant

[Phil Race]

So jigsaw will break such apps as these that rely on particular ways of 
finding tools.jar, even on other platforms?
Do they have to do something else, or nothing ?
If something else, that breakage better have big benefits too ..

Anyway this has got off the point. What should happen in JDK 7 on OS X 
to fix this ?


-phil.

On 9/30/11 8:30 PM, Jonathan Gibbons wrote:
> The separation between JDK and JRE will become blurred with Jigsaw -- 
> you'll have a JRE + installed modules, and Jigsaw will locate and use 
> the modules your app depends on.
>
> Jigsaw is relevant because it will supersede the use of jar files 
> going forward for JDK 8 and beyond, including, in particular, 
> tools.jar, which was the origin of this thread.  In JDK 8, there will 
> be no tools.jar.
>
> -- Jon
>
>
> On 09/30/2011 07:52 PM, Phil Race wrote:
>>
>> I honestly don't see how jigsaw is relevant. It might have a side 
>> effect of providing a way of expressing
>> a dependency, but it sounds like we already provide jars but no 
>> standard way to even find them. Please
>> tell me why this is so hard or unimportant ...
>>
>> -phil.
>>
>> On 9/30/11 6:58 PM, Jonathan Gibbons wrote:
>>> 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 ?
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>