Review Request: JDK-8011602 - jobjc build failure on Mac
david.holmes at oracle.com
Fri Apr 5 16:51:35 PDT 2013
Looks okay to me - glad there was a simple solution.
Still wondering why this didn't get picked up during JPRT testing though ??
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!
> 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.
>> 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
>>> 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/
More information about the macosx-port-dev