Re: P1 RFR of build fix (extra small): JDK-8153303
Looks good, thanks Tim! /Erik On 2016-04-01 20:41, Tim Bell wrote: Please review this build fix. One ',' was omitted in the JDK-8153257 changes. Bug report: https://bugs.openjdk.java.net/browse/JDK-8153303 Webrev: http://cr.openjdk.java.net/~tbell/8153303/webrev.00/index.html This is small enough that I am including it here inline: % hg diff common/conf/jib-profiles.js diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -250,7 +250,7 @@ target_cpu: "x86", build_cpu: "x64", dependencies: concat(common.dependencies, "devkit"), -configure_args: concat(common.configure_args, common.configure_args_32bit +configure_args: concat(common.configure_args, common.configure_args_32bit, "--with-zlib=system"), make_args: common.make_args }, Thanks in advance- Tim
Re: Configuration script unable to detect boot JDK's modules support
Yes, we do, if you don't mind. /Erik On 2016-04-02 13:38, Filipp Zhinkin wrote: Hi Erik, thanks for reply. Do we need a JBS's ticket to track this issue? Thanks, Filipp. On Thu, Mar 31, 2016 at 5:23 PM, Erik Joelsson wrote: It seems the test is indeed incorrect at this point. When I added that test, the launcher would accept just -Xpatch:. It seems to now accept -Xpatch:foo so perhaps we should use that for the test. /Erik On 2016-03-31 09:56, Filipp Zhinkin wrote: Hi all, I'm trying to build OpenJDK from latest sources using JDK9-b111 as a boot JDK and configuration script is not able to detect modules support: $ bash configure --enable-option-checking=fatal --with-jvm-variants=server --with-debug-level=release --disable-headful --with-boot-jdk=/home/filipp/Downloads/bootdir/jdk-9 --with-jtreg=/home/filipp/Development/openjdk/jtreg ... $ grep modules build/linux-x86_64-normal-server-release/configure.log checking if Boot JDK supports modules... no I've looked into common/autoconf/boot-jdk.m4 to find out how modules support is detected and we simply pass '-Xpatch:' to JVM [1]: jdk-9/bin/java -Xpatch: -version Bad value for -Xpatch. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Am I missing something or that check should actually pass -Xpatch:blablabla? Regards, Filipp. [1] http://hg.openjdk.java.net/jdk9/jdk9/file/03543a758cd5/common/autoconf/boot-jdk.m4#l308
Re: Provide zipped javadoc archive from make
Hello, There is still an mkdir instead of $(MKDIR). The comments don't read very well, here is a suggestion. "Optional target which bundles all generated javadocs into a zip archive. The dependency on docs is handled in Main.gmk. Incremental building of docs is currently broken so if you invoke zip-docs after docs, the docs are always rebuilt." "Add the core docs as prerequisite to the archive to trigger a rebuild if the core docs were rebuilt. Ideally any doc rebuild should trigger this, but the way prerequisites are currently setup in this file, that is hard to achieve." /Erik On 2016-04-01 16:55, Jiri Vanek wrote: On 03/31/2016 04:18 PM, Erik Joelsson wrote: Hello, https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v3/ https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v3/webrev.zip All should be fixed. *however* I did not tested it. I was working on another machine, and plain jdk8 (without u) was there... And it do not built on f23 anymore. Still I think best test will be to already include it to fedora RPMs and start to work on jdk9's version. The comment has not been updated after the dependencies changed. Please use $(MKDIR), $(RM) -f and $(LN). Right. I was so careful in v1 an now such an mistake. There is no need for the dash before rm since rm -f won't fail and we haven't used it like that before in these makefiles. sure. Please don't remove the assembly dir after zipping. In general, we keep intermediate files around for easier debugging of the build. As you command! On 2016-03-31 15:20, Jiri Vanek wrote: ...snip... Note that the change for 9 will be quite different. The makefiles have evolved quite a bit. good to know :) Yes, dependencies here are broken. I don't expect you to fix it in this patch. It's rare that people build docs incrementally so it hasn't been a priority to fix. For now, I suppose you can add back the COREAPI_INDEX_FILE so that the zip is rebuilt if the coreapi docs were rebuilt, but with a comment that dependencies are actually broken and this is just a reasonable workaround. At least ordering is properly handled in Main.gmk now. Should be done. Again thank you for support J. /Erik * Please don't use temporary directories outside the build output dir. Such directories always risk being left behind by failed builds. We need the build to only create files in the designated output dir. fixed. * --display-globaldots is not a good option to use in this context. It won't work well with file logging of the build and I doubt it's valid for all platforms we build on. sure. Removed. Thanx! J. /Erik On 2016-03-29 18:24, Jiri Vanek wrote: Hello Again! Sorry for delay in reply. There is webrev https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v1/ https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/zip-javadocs/v1/webrev.zip with patch as was (moreover) agreed in this thread for *jdk8* As I was studying the makefiles, I think I did not violated to much conditions by this hunk of code:) I thought that 8 will be much more simple, but at the end it evolved to same "find all roots" as discussed for 9 and modules. The only thing I don't like in this patch is unsuitability of zip to zip directories with stripped path. I went by pushd/popd but I had seen you like cd in make files more. Thanx for any feedback! J. On 03/08/2016 03:50 PM, Erik Joelsson wrote: I wouldn't go that far, but I won't have time to look into it for a while yet at least. /Erik On 2016-03-08 15:34, Jiri Vanek wrote: Ping? Or is this going to be considered closed-wont "fix"? Thanx! J. On 02/29/2016 04:24 PM, Jiri Vanek wrote: On 02/26/2016 08:05 PM, Jonathan Gibbons wrote: On 02/26/2016 03:49 AM, Jiri Vanek wrote: On 02/25/2016 06:34 PM, Jonathan Gibbons wrote: On 02/25/2016 09:23 AM, Jiri Vanek wrote: I must be missing something. Dozens? Of varius runs of javadoc? I thought that javadoc ending at the end in single drectory is one single javadoc for java. If you are referring to javadoc generated by "per module" then one jjoined zip is enough for me. Jiri, If you accept the premise that javadoc writes one stylesheet.css file per run of javadoc, take a look at the following list: Then my goal will be to crate a trget, which takes build/linux-x86_64-normal-server-release/images/docs/ and pack it to build/linux-x86_64-normal-server-release/images/javadoc.zip It should contains also the "smaller api" you are mentioning below? If not, then those should appear in this zip too. $ find build/linux-x86_64-normal-server-release/images/docs/ -name stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css build/linux-x86_64-normal-ser
Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )
[ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code in java.rmi has, then a new small native library is required. http://cr.openjdk.java.net/~chegar/8153286/ https://bugs.openjdk.java.net/browse/JDK-8153286 -Chris.
Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )
Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? /Erik On 2016-04-04 12:26, Chris Hegarty wrote: [ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code in java.rmi has, then a new small native library is required. http://cr.openjdk.java.net/~chegar/8153286/ https://bugs.openjdk.java.net/browse/JDK-8153286 -Chris.
Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )
On 04/04/2016 12:04, Erik Joelsson wrote: Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? Yes, libjava/mapfile-vers will need to be updated too. It otherwise looks okay to me, just a pity that it requires introducing another native library. -Alan
RFR: JDK-8153243: JShell: make docs --- should generate JShell API docs
Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8153243 Javadoc for JShell API should be part of the "make docs". Changes to the top-level repository: http://cr.openjdk.java.net/~jlahoda/8153243/webrev.00/top-level/ Small tweaks to the langtools repository (JShell API javadoc) to avoid errors when building the javadoc: http://cr.openjdk.java.net/~jlahoda/8153243/webrev.00/langtools/ Thanks, Jan
Re: RFR: JDK-8153243: JShell: make docs --- should generate JShell API docs
Looks good to me. /Erik On 2016-04-04 13:36, Jan Lahoda wrote: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8153243 Javadoc for JShell API should be part of the "make docs". Changes to the top-level repository: http://cr.openjdk.java.net/~jlahoda/8153243/webrev.00/top-level/ Small tweaks to the langtools repository (JShell API javadoc) to avoid errors when building the javadoc: http://cr.openjdk.java.net/~jlahoda/8153243/webrev.00/langtools/ Thanks, Jan
Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )
On 04/04/16 12:34, Alan Bateman wrote: > On 04/04/2016 12:04, Erik Joelsson wrote: >> Makefile looks good. >> >> If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of >> libjava, should you also remove it from the mapfile for libjava? >> > Yes, libjava/mapfile-vers will need to be updated too. It otherwise > looks okay to me, just a pity that it requires introducing another > native library. Yes, of course. This just showed up in my testing too. I'll make the change before pushing. -Chris.
Re: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc
Thanks to everyone for reviewing. I've pushed the fix today. Regards, Alexey On 17.03.2016 21:23, Phil Race wrote: +1 -phil. On 02/15/2016 01:02 AM, Erik Joelsson wrote: Looks good. /Erik On 2016-02-12 10:15, Seán Coffey wrote: Approved for jdk8u-dev once you have a peer code review. Regards, Sean. On 12/02/2016 08:19, Alexey Ivanov wrote: I forgot to add jdk8u-dev list... On 11.02.2016 17:19, Alexey Ivanov wrote: Hello, Could you please review the fix for JDK-8147807 and approve push to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ The issue is not relevant to jdk 9. The fix just removes kcms service leaving lcms as the only option which is the default in jdk8. Thanks in advance, Alexey
