Re: RFR: JDK-8028162 - Update Netbeans / Solaris Studio project files
Hi Brad, I use the DevStudio IDE [1] (which builds on top of NetBeans) as my default IDE and I use the project files for JVM development. I'm not sure exactly what your question is, but at least to me it is convenient to have the project already there, configured and ready to go every time I make a new clone of the JDK. If you work on the JDK libraries the project won't be as useful. You can still browse and build of course, but symbol lookup is not configured properly for the Java source. That's why the project is called nb_native (native as in C++). As far as I know there is currently no way to set up a project that works for both Java and C++. /Jesper [1] http://www.oracle.com/technetwork/server-storage/developerstudio/downloads/index-jsp-141149.html Den 29/6/16 kl. 20:18, skrev Bradford Wetmore: Jesper, This is not a review comment, but could you tell us how these netbeans projects are supposed to be used? To do my JDK debugging, I usually create an exploded JDK build using the normal make files, then in Netbeans created a new platform that pointed at the build/*/jdk directory, then created a test file as a regular project and assigned the just-created platform to it. I can then run the test and step through the JDK code, recompiling using an external make if I need to iterate. Very convenient. What does this Netbeans project file do that I won't get with my current approach? Brad On 6/23/2016 3:55 PM, Jesper Wilhelmsson wrote: Hi, Please review this patch to update the NetBeans project files for JDK 9. Several big changes in the code base (Jigsaw, GC restructuring, etc) have made the old NBproject in need of an update. Vladimir Kvashin in the Studio IDE team has kindly helped us to update the project files on all platforms. I have reviewed the changes and used the new project on Mac to verify that it works as expected. I'm not sure if I'm a reviewer or a Reviewer in this part of the JDK forest. One more Reviewer is needed. Webrev: http://cr.openjdk.java.net/~jwilhelm/8028162/webrev.01/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8028162 https://bugs.openjdk.java.net/browse/JDK-8028163 https://bugs.openjdk.java.net/browse/JDK-8028164 Thanks, /Jesper
Re: RFR: JDK-8028162 - Update Netbeans / Solaris Studio project files
Jesper, This is not a review comment, but could you tell us how these netbeans projects are supposed to be used? To do my JDK debugging, I usually create an exploded JDK build using the normal make files, then in Netbeans created a new platform that pointed at the build/*/jdk directory, then created a test file as a regular project and assigned the just-created platform to it. I can then run the test and step through the JDK code, recompiling using an external make if I need to iterate. Very convenient. What does this Netbeans project file do that I won't get with my current approach? Brad On 6/23/2016 3:55 PM, Jesper Wilhelmsson wrote: Hi, Please review this patch to update the NetBeans project files for JDK 9. Several big changes in the code base (Jigsaw, GC restructuring, etc) have made the old NBproject in need of an update. Vladimir Kvashin in the Studio IDE team has kindly helped us to update the project files on all platforms. I have reviewed the changes and used the new project on Mac to verify that it works as expected. I'm not sure if I'm a reviewer or a Reviewer in this part of the JDK forest. One more Reviewer is needed. Webrev: http://cr.openjdk.java.net/~jwilhelm/8028162/webrev.01/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8028162 https://bugs.openjdk.java.net/browse/JDK-8028163 https://bugs.openjdk.java.net/browse/JDK-8028164 Thanks, /Jesper
Re: JDK-8071693 Introspector ignores default interface methods
Hello, This review should be sent to the beans-dev mailing list. The build-dev mailing list is for issues concerning building OpenJDK. (I can't forward since I'm not a member of the beans-dev list) /Erik On 2016-06-29 20:04, Lukáš Kvídera wrote: I think I have found a solution for a bug JDK-8071693. The problem is the Introspector does scan only in super classes and does not know about default methods. I just added condition method.isDefault() and manual testing proves my idea does work. I did NOT run junit tests. Can you please review this patch in attachment? LK Bug: https://bugs.openjdk.java.net/browse/JDK-8071693
JDK-8071693 Introspector ignores default interface methods
I think I have found a solution for a bug JDK-8071693.
The problem is the Introspector does scan only in super classes and does not
know about default methods.
I just added condition method.isDefault() and manual testing proves my idea
does work. I did NOT run junit tests.
Can you please review this patch in attachment?
LK
Bug: https://bugs.openjdk.java.net/browse/JDK-8071693
--- jdk/src/share/classes/java/beans/Introspector.java 2014-03-04 03:57:57.0 +0100
+++ Introspector.java 2016-06-29 19:39:28.309976038 +0200
@@ -1294,21 +1294,19 @@
result = clz.getMethods();
for (int i = 0; i < result.length; i++) {
Method method = result[i];
-if (!method.getDeclaringClass().equals(clz)) {
-result[i] = null; // ignore methods declared elsewhere
-}
-else {
+if (method.getDeclaringClass().equals(clz) || method.isDefault()) {
try {
method = MethodFinder.findAccessibleMethod(method);
-Class type = method.getDeclaringClass();
+final Class type = method.getDeclaringClass();
result[i] = type.equals(clz) || type.isInterface()
? method
: null; // ignore methods from superclasses
-}
-catch (NoSuchMethodException exception) {
+} catch (NoSuchMethodException exception) {
// commented out because of 6976577
// result[i] = null; // ignore inaccessible methods
}
+} else {
+ result[i] = null; // ignore methods declared elsewhere
}
}
declaredMethodCache.put(clz, result);
Re: RFR: JDK-8160571: Bootcycle builds still broken with server jvm on Windows 32bit
Erik: In JDK-8160285 I tried to fix the bootcycle build on 32bit windows when only the server jvm is being built. It appears I only verified the fix on a release build. In my JPRT job I forgot to enable only the server jvm so it ran with client. We are now faced with more similar failures in the fastdebug build. The javac server process is set to use mx1500M and fails all the time in that configuration. The JAVA_FLAGS_BIG config fails intermittently with not being able to allocate enough memory. My suggested fix is to further reduce the maximum amount of heap from 1100 to 1024 to avoid the intermittent failures and to replace the override of the "javac server jvm args" with the same set of args as have already been calculated for "java big". I have run this configuration through JPRT with client disabled. I have also run several builds locally without failure. Bug: https://bugs.openjdk.java.net/browse/JDK-8160571 Webrev: http://cr.openjdk.java.net/~erikj/8160571/webrev.top.01/ Looks good to me. /Tim
RFR: JDK-8160571: Bootcycle builds still broken with server jvm on Windows 32bit
In JDK-8160285 I tried to fix the bootcycle build on 32bit windows when only the server jvm is being built. It appears I only verified the fix on a release build. In my JPRT job I forgot to enable only the server jvm so it ran with client. We are now faced with more similar failures in the fastdebug build. The javac server process is set to use mx1500M and fails all the time in that configuration. The JAVA_FLAGS_BIG config fails intermittently with not being able to allocate enough memory. My suggested fix is to further reduce the maximum amount of heap from 1100 to 1024 to avoid the intermittent failures and to replace the override of the "javac server jvm args" with the same set of args as have already been calculated for "java big". I have run this configuration through JPRT with client disabled. I have also run several builds locally without failure. Bug: https://bugs.openjdk.java.net/browse/JDK-8160571 Webrev: http://cr.openjdk.java.net/~erikj/8160571/webrev.top.01/ /Erik
Re: random jdk9-dev build error
I suspect it's another instance of https://bugs.openjdk.java.net/browse/JDK-8158629 /Erik On 2016-06-29 16:55, Jim Laskey (Oracle) wrote: After a clean got dtrace: failed to compile script /Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot_jni.h.d: line 1: empty D program translation unit second time worked fine.
random jdk9-dev build error
After a clean got dtrace: failed to compile script /Projects/jdk9-dev/build/macosx-x86_64-normal-server-fastdebug/hotspot/variant-server/support/dtrace/hotspot_jni.h.d: line 1: empty D program translation unit second time worked fine.
Re: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib
Sundar, Erik: Looks good Yes, nashorn will not get any native tests. -Sundar On 6/29/2016 4:25 PM, Erik Joelsson wrote: Looks ok to me. Thank you for the reviews. It's unlikely that nashorn will ever get native tests so just removing this functionality is a good solution. If we expected nashorn to need native tests anytime soon, it would likely be better to just create a placeholder directory in the test image instead. Rather than do that (create a placeholder), I took the path established in other directories of 100% Java code, like langtools and jaxp. Tim /Erik On 2016-06-29 03:39, Tim Bell wrote: All- When using jib to run jtreg tests in an automated setting, TEST_IMAGE_DIR is set for those test suites having native code. Refer to jdk/test/Makefile or hotspot/test/Makefile for two examples. The nashorn repo does not have any native tests, so nashorn/test/Makefile should not consider TEST_IMAGE_DIR. Bug report: https://bugs.openjdk.java.net/browse/JDK-8160505 Webrev: http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ Tested by hand before and after applying the suggested fix. Thanks in advance- Tim
RFR: JDK-8160490: "installer-only" top level target is broken
Hello, A while ago, in JDK-8155689, a workaround was put in place because a temporary broken Jib configuration file. The Jib configuration has since been fixed and the workaround can now safely be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8160490 Patch: diff -r 20f1ee2fe834 make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -933,10 +933,6 @@ - -# workaround issue when building open targets when closed jib-profiles.js is used -installer: product-images test-image - .PHONY: $(ALL_TARGETS) FRC: # Force target /Erik
Re: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib
Looks good Yes, nashorn will not get any native tests. -Sundar On 6/29/2016 4:25 PM, Erik Joelsson wrote: > Looks ok to me. > > It's unlikely that nashorn will ever get native tests so just removing > this functionality is a good solution. If we expected nashorn to need > native tests anytime soon, it would likely be better to just create a > placeholder directory in the test image instead. > > /Erik > > On 2016-06-29 03:39, Tim Bell wrote: >> All- >> >> When using jib to run jtreg tests in an automated setting, >> TEST_IMAGE_DIR is set for those test suites having native code. Refer >> to jdk/test/Makefile or hotspot/test/Makefile for two examples. >> >> The nashorn repo does not have any native tests, so >> nashorn/test/Makefile should not consider TEST_IMAGE_DIR. >> >> Bug report: >>https://bugs.openjdk.java.net/browse/JDK-8160505 >> >> Webrev: >>http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ >> >> Tested by hand before and after applying the suggested fix. >> >> Thanks in advance- >> >> Tim >> >
Re: RFR: 8160505, Automated test runs fail in nashorn because TEST_IMAGE_DIR is set by jib
Looks ok to me. It's unlikely that nashorn will ever get native tests so just removing this functionality is a good solution. If we expected nashorn to need native tests anytime soon, it would likely be better to just create a placeholder directory in the test image instead. /Erik On 2016-06-29 03:39, Tim Bell wrote: All- When using jib to run jtreg tests in an automated setting, TEST_IMAGE_DIR is set for those test suites having native code. Refer to jdk/test/Makefile or hotspot/test/Makefile for two examples. The nashorn repo does not have any native tests, so nashorn/test/Makefile should not consider TEST_IMAGE_DIR. Bug report: https://bugs.openjdk.java.net/browse/JDK-8160505 Webrev: http://cr.openjdk.java.net/~tbell/8160505/nashorn/webrev/ Tested by hand before and after applying the suggested fix. Thanks in advance- Tim
