java.library.path fix for MacOS X (7145798)

Daniel D. Daugherty daniel.daugherty at
Fri Feb 17 16:47:52 PST 2012

On 2/17/12 5:36 PM, Mike Swingler wrote:
> On Feb 17, 2012, at 2:57 PM, Daniel D. Daugherty wrote:
>> Thanks Paul!
>> If I could get one more person with "Reviewer" status
>> that would be great!
>> Mike Swingler or someone else from Apple, come on down!
> I don't feel comfortable reviewing this in terms of the potential security impact, which should be evaluated by an Oracle engineer.

Hey Mike!

Not a problem. I did get a third reviewer so this changeset
is already in flight to RT_Baseline for HSX-24-B01...
That means that I can't add you as a reviewer... Sorry.

I'm looking at the process that I have to follow to get this
changeset into JDK7u4/HSX-23... I should be ready to start
that process shortly...

>  From a purely technical point of view, the patch does exactly what it says it does,

Glad we're on the same page.

> though I'd prefer to shorten the comment to simply:
> // Appending "." to maintain compatibility with Apple's previous JDKs,
> // which prepend "." to the java.library.path. This is an intentional
> // variation from Linux and Solaris, and also matches Windows behavior.

Obviously with the changeset in flight, I can't change it, but...
while yours is shorter, I think mine conveys more of the possible
compatibility issues and how to deal with them.

And thanks for addressing the AppStore question below...


> On Feb 17, 2012, at 3:52 PM, Michael Hall wrote:
>> On Feb 17, 2012, at 5:35 PM, Daniel D. Daugherty wrote:
>>> On 2/17/12 4:13 PM, Michael Hall wrote:
>>>> On Feb 17, 2012, at 4:43 PM, Daniel D. Daugherty wrote:
>>>>> On 2/17/12 3:36 PM, James Melvin wrote:
>>>>>>> Are there any security issues with using dot on a search path?
>>>>>> Yes.  But if I told you, I'd have to delete you.  :)
>>>>> Ahhhhh.... security geek humor...
>>>>> It brings back fond memories...
>>>> More or less curiosity.
>>>> One thing I was wondering about, this is specific to OS X java ongoing, was whether or not there would be any concerns with however accessing native libs is handled in relation to applications ending up in the Apple app store?
>>> I'm having trouble parsing the above paragraph...
>>> Rather than me guessing, can you repost the question?
>> I'm not looking to be a spokes person for anyone. If Mike Swingler is going to review maybe he could just generally address any app store issues he can think of.
>> But to try and clarify my statement, my understanding is that Apple has in the past had an unfortunate tendency to reject java applications because they bundle java. I have seen passing comments on the macosx-port list that issues like this are being kept in mind so that developers will be more successful with submitted java applications in the future.
>> I wondered if there might any concerns for successful submissions depending on what JNI or how JNI is bundled for getting an application into the app store?
> The Mac App Store rejects applications that use deprecated or optionally installed technologies. Java SE 6, as provided by Apple, is both deprecated and optionally installed. Apps that bundle their own JRE don't have this problem. That's it.
> Apps from the Mac App Store can load additional libraries, however I think it is only prudent for them to restrict their loading to libraries within their own code signed bundle.
> Mike Swingler
> Apple Inc.

More information about the hotspot-runtime-dev mailing list