Hi David,
Thanks for your review. When I tested it in JPRT run, I added "-boot
jdk1.8.0" to use jdk8 as the boot jdk. I did not realize that being able
to build with jdk7 is a requirement. I will push the fix now. Thanks!
-Dan
On 04/05/2013 04:51 PM, David Holmes wrote:
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
