Review Request: JDK-8011602 - jobjc build failure on Mac

[David Holmes]

Dan,

Looks okay to me - glad there was a simple solution.

Still wondering why this didn't get picked up during JPRT testing though ??

Thanks,
David

On 6/04/2013 9:21 AM, Dan Xu wrote:
> Right. Even the generated native headers from jobjc are saved into its
> own directory.
>
> Thank you for your review!
>
> -Dan
>
>
> On 04/05/2013 04:15 PM, Mandy Chung wrote:
>> Thumbs up.  Thanks for fixing it quickly.  The macosx jobjc build has
>> its own special build logic that brought some surprise when I merged
>> it with jigsaw at one time.
>>
>> Mandy
>>
>> On 4/5/2013 3:35 PM, Dan Xu wrote:
>>> Hi All,
>>>
>>> Please review the change to fix the build issue on mac platformat
>>> http://cr.openjdk.java.net/~dxu/8011602/webrev/. It removes the
>>> un-necessary @Native annotation from
>>> src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java.
>>> Therefore, the objc compilation will not dependon the new
>>> java.lang.annotation.Native interfacethat is only introduced in jdk8.
>>>
>>> For the normal build process, even though @Native annotationis added
>>> to many other java classes to replace @GenerateNativeHeader, the
>>> langtool has the capability to handle that when building with jdk7.
>>> But on Mac platform, objc compilation is a special process, where the
>>> magic of langtool to handle new jdk8 interface in old jdk7 cannot be
>>> applied. Since Coder.java already has a native method,
>>> getNativeFFITypePtrForCode(), declared, @Native is not necessary to
>>> be present, and it is safe to remove them. The other change in file,
>>> src/share/classes/sun/java2d/opengl/OGLContext.java, is only a format
>>> correction. I have tested this fix in jprt with boot jdk as jdk7
>>> across all platforms. Thanks!
>>>
>>> webreve: http://cr.openjdk.java.net/~dxu/8011602/webrev/
>>>
>>> -Dan
>>
>