Code Review Request: 7126993: JCK test api/java_util/jar/Jarfile jarFile0129 failing [macosx]

[Paul Hohensee]

I think the JVM_ names were intended to be used in platform-independent 
code.

For "change required for the time being", are you referring to a change
to os_bsd.cpp?

Paul

On 1/19/12 3:17 PM, Kurchi Hazra wrote:
>
> I see that O_DELETE is 0x10000 in os_bsd.cpp in 7u4osx too. So basically,
> the only change required for the time being is the one in the webrev 
> below.
>
> This maybe a stupid question, but if O_DELETE is already defined,
> why do we have to use a separate JVM_O_DELETE macro? Why can't we just 
> use
> O_DELETE in ZipFile.c?
>
> If the reason is consistency, that is to have all flags used in open() 
> defined at one place in
> jvm_md.h, then why can't we just use a dummy macro such as O_DEL and 
> define
> it in jvm_md.h as O_DELETE?
>
>
> - Kurchi
>
>
>
> On 1/19/2012 12:02 PM, Paul Hohensee wrote:
>> If this change needs to be make, we should make the same
>> change in os_bsd.cpp.  The original value of O_DELETE in
>> os_bsd.cpp was 0x10000 and hasn't been changed since.
>>
>> Paul
>>
>> On 1/19/12 2:18 PM, Alan Bateman wrote:
>>> On 19/01/2012 18:56, Kurchi Hazra wrote:
>>>>
>>>> Hi,
>>>>
>>>> JCK tests api/java_util/jar/Jarfile and api/java_util/zip/ZipFile 
>>>> were both failing
>>>> on Mac because the OPEN_DELETE flag sets the JVM_O_DELETE flag in 
>>>> native code, and the
>>>> value of JVM_O_DELETE was changed from 0x10000 to0x10000000 for Mac 
>>>> OS.
>>>> The JVM_O_DELETE flag is only used in 
>>>> src/share/native/java/util/zip/ZipFile.c
>>>> and hence this change should be safe.
>>>>
>>>>
>>>> Bug :  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7126993
>>>>
>>>> Webrev : http://cr.openjdk.java.net/~khazra/7126993/webrev.00/
>>> At some point we need to change the zip and other code so that it's 
>>> not using the JVM_ functions (not needed anymore). I checked 
>>> os_bsd.cpp and O_DELETE is defined as 0x10000 so this is the value 
>>> that JVM_O_DELETE needs to have in jvm_md.d. I don't know why it was 
>>> changed to 0x10000000 but it must have had a corresponding change in 
>>> HotSpot at one point.
>>>
>>> -Alan.
>