Review Request: JDK-8011602 - jobjc build failure on Mac (original) (raw)

David Holmes david.holmes at oracle.com
Fri Apr 5 23:51:35 UTC 2013

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

More information about the core-libs-dev mailing list