Re: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64

On 01/03/2018 22:53, Brian Burkhalter wrote: I think shorter is better: http://cr.openjdk.java.net/~bpb/8198834/webrev.01/ I’ll hold off pushing until Alan comments again. libInheritedLauncher.c looks okay (although still very strange

Re: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64

On 01/03/2018 20:21, Brian Burkhalter wrote: On Mar 1, 2018, at 12:17 PM, Alan Bateman <alan.bate...@oracle.com <mailto:alan.bate...@oracle.com>> wrote: The C source file beginning with “lib” is a requirement of the jtreg native test build. Okay, we might have to live wit

Re: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64

On 01/03/2018 20:06, Brian Burkhalter wrote: On Mar 1, 2018, at 11:52 AM, Alan Bateman <alan.bate...@oracle.com <mailto:alan.bate...@oracle.com>> wrote: The rename of Launcher.c looks a bit strange, the original name looks better to me. The C source file beginni

Re: RFR 8198834: (ch) Enable java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java on linux-x64

On 01/03/2018 18:44, Brian Burkhalter wrote: On Feb 28, 2018, at 8:34 AM, Alan Bateman <alan.bate...@oracle.com <mailto:alan.bate...@oracle.com>> wrote: This look okay but I think we should looking at creating this .so in the build, like we do for libDirectIO.so to create the sh

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

On 28/02/2018 18:25, Lance Andersen wrote: Hi all, This RFR request moves the javax.transaction.xa package out of the java.sql module and into its own module java.transaction.xa. One of the motivators for this change is due to the fact JSR 907 1.3 MR indicated that the javax.transaction.xa

Re: JDK10 build problem: "--module-path"?

On 15/02/2018 06:32, Ted Neward wrote: Really?!? I thought the javac -help only listed -modulepath. Not to disbelieve you *grin*, but are you sure? The reason I ask is (barring some really bizarre misconfiguration) I should be using the OpenJDK9 as the boot JDK for this, and I'm getting the

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

On 12/02/2018 11:42, Magnus Ihse Bursie wrote: Why would hidden files be confusing? Or, rephrased, how is this any more confusing than other hidden directories, such as .idea or .jib? I modelled the behaviour on jib. In fact, I was considering using the same directory (.jib), but since the

Re: RFR: JDK-8196356: Changes to m4 files don't trigger autoconf execution at build time

On 08/02/2018 17:49, Erik Joelsson wrote: The check for when to generate the generated configure script is not working quite as expected. It currently only compares timestamps if the local repository has any local changes in the make/autoconf directory. This used to make sense when we had a

Re: RFR 8190378: Java EE and CORBA modules removal

On 07/02/2018 16:57, Lance Andersen wrote: Hi all, I think we are at a point where we are ready to start reviewing the changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188, has been targeted to JDK 11. The CSR for removing the modules has been approved:

Re: RFR: JDK-8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@'

On 07/02/2018 16:42, Erik Joelsson wrote: It seems my recent changes has caused yet another build failure. I'm puzzled over why this worked in our internal CI builds but fails in other situations. Some toolchains must simply be accepting @LIBZ_CFLAGS@ on the command line. Anyway, the fix is

Re: RFR: JDK-8196911: Windows build fails with not finding zlib.h

On 07/02/2018 14:13, Thomas Stüfe wrote: Could this also explain what we see in some of our nightlies? The builds broke on some platforms for us (e.g. linux ppcle). It seems that "@LIBZ_CFLAGS@" does not get expanded correctly and finds its way into the makefile, confusing the compiler: (

Re: RFR: JDK-8194141: Remove JDK9Wrappers

On 03/01/2018 22:42, Jonathan Gibbons wrote: Updated webrev, reverting unnecessary change to generated-configure.sh http://cr.openjdk.java.net/~jjg/8194141/webrev.01/ This cleanup looks good to me. -Alan

Re: bash configure fails on missing javah

On 03/01/2018 04:05, Martin Buchholz wrote: I agree configure should not fail if javah is not found. A high quality configure test would first check if javac -h works, then fall back to javah if that works, regardless of the boot jdk's version. JDK-8193512 removes the check for javah from

Re: RFR: JDK-8193512: remove remnants of javah from jdk/jdk10 repo

On 19/12/2017 21:52, Jonathan Gibbons wrote: Please review these changes to remove the remnants of javah (and in a couple of tests, some remnants of apt and an earlier version of javap) from the repo, now that the tool itself has been removed. JBS:

Re: 8193503: javah launcher was not removed by JDK-8191054

On 14/12/2017 09:21, Erik Joelsson wrote: Looks good! /Erik I'll get this in now and also create another issue to remove the other remnants of javah from the build (they won't impact the build output but will need to be cleaned up). -Alan

8193503: javah launcher was not removed by JDK-8191054

Jon removed the code for javah from the jdk.compiler module with JDK-8191054 but the build still creates a launcher that is now DOA with "Error: Could not find or load main class com.sun.tools.javah.Main in module jdk.compiler". This is caught by one of the launcher tests that checks the

Re: Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API

On 28/11/2017 01:50, mandy chung wrote: This is a follow-up on JDK-8189611 that defines a new public API to return a stream of versioned entries and to return the real name of a JAR entry.  JDK-8189611 leaves jdeps untouched because jdeps is compiled with the boot JDK. This patch includes:

Re: OpenJDK9/10 : sawindbg.dll / sawindbg.dll.manifest

On 17/11/2017 17:15, Erik Joelsson wrote: I don't know what the manifest file is for, but if it's in the wrong place I would blame jlink for messing it up. jlink doesn't know anything about Windows manifests files. I think the issue here is that jdk.hotspot.agent.jmod contains

Re: RFR: JDK-8190744: xattr: No such file LICENSE files

On 08/11/2017 00:58, Erik Joelsson wrote: After my recent changes to the install-file macro and using of SetupCopyFiles to generate the mac specific images, we have started seeing errors like this in the build on mac: xattr: No such file:

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

On 30/10/2017 12:38, coleen.phillim...@oracle.com wrote: : I don't know why Java_java_io_UnixFileSystem uses JVM_MAXPATHLEN since it's not calling the JVM interface as far as I can tell. I think it should be changed to PATH_MAX. This code used to use the JVM_* functions (dates back to

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

On 17/10/2017 20:20, Martin Buchholz wrote: : Wow, --limit-modules sure is a good trick.  So now we have two possible replacements for the demise of -Xbootclasspath/p: --patch-module --limit-modules combined with renamed replacement modules The trick works for the unique scenario of

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

On 17/10/2017 17:53, Martin Buchholz wrote: I tried to figure out how this patch actually works.  At first I thought we were "shading" (renaming all the packages in the source files) but now I think we're merely renaming the modules by appending ".interim" to the names.  But that looks like

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

On 16/10/2017 19:53, Martin Buchholz wrote: What's the canonical way to list all upgradeable modules? There's a list in JEP 261, but naturally we can't consider it authoritative. make/common/Modules.gmk has the list (look for UPGRADEABLE_MODULES and UPGRADEABLE_TOOL_MODULES). I was

Re: RFR: JDK-8189094: Change required boot jdk to JDK 9

On 16/10/2017 16:41, Martin Buchholz wrote: The difficulties encountered trying to run langtools10 in a jdk9 suggests that the jdk9 module model is too restrictive. I've long lobbied for treating langtools as just another collection of ordinary programs that happen to be written in java and

Re: RFR: JDK-8189222 Remove make/corba/Makefile

On 12/10/2017 12:15, Magnus Ihse Bursie wrote: We should remove make/corba/Makefile. This should have been done long time ago by JDK-8076060. "Patch": $ hg st R make/corba/Makefile Bug: https://bugs.openjdk.java.net/browse/JDK-8189222 Looks okay to me. One thing to keep in mind is that

Re: running tests from make causes spurious repo changes

On 25/09/2017 21:35, Maurizio Cimadamore wrote: On 25/09/17 20:58, Alan Bateman wrote: On 25/09/2017 20:11, Jonathan Gibbons wrote: Erik, It could be a feature of the build (i.e. test makefiles) to verify that no source-controlled files were modified in the course of a test run

Re: running tests from make causes spurious repo changes

On 25/09/2017 20:11, Jonathan Gibbons wrote: Erik, It could be a feature of the build (i.e. test makefiles) to verify that no source-controlled files were modified in the course of a test run. Something fishy in this thread as these tests have historically not changed the permissions of

Re: RFR 8148371: Remove policytool

On 06/09/2017 05:17, Weijun Wang wrote: Hi All Please review the change, which spans to root, jdk and langtools repos. http://cr.openjdk.java.net/~weijun/8148371/ I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path

Re: some config files out of conf directory

On 04/08/2017 07:59, Jiri Vanek wrote: Hello! I'm packaging openjdk9 for Fedora, and following files: jdk/lib/security/blacklisted.certs jdk/lib/security/default.policy Seems to be config files. Still, they are in lib/security, whether all other config files were (finally! Thank you!)

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

On 23/07/2017 14:37, Claes Redestad wrote: Hi, java.lang.CharacterDataLatin1 and others are generated at build time by the GenerateCharacter tool, which has a -string mode to generate lookup tables as Strings literals rather than arrays directly. This serves multiple purposes: 1. it

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

On 03/07/2017 19:27, Jonathan Gibbons wrote: Looks good to me. -- Jon Thumbs up from me too. -Alan

Re: Build Failure on Master

On 17/06/2017 12:39, Claes Redestad wrote: http://hg.openjdk.java.net/jigsaw/jake/ - but it was recently synced to jdk9/dev (as in a few hours ago) and should be effectively the same. With some luck there'll not be much if any difference between them going forward. The changes that were

Re: RFR(10): 8181147: JNU_GetStringPlatformChars should have a fast path for UTF-8

On 15/06/2017 17:26, Chris Hegarty wrote: : Claes, This is the first test in the core area that will now use a test specific native library, which will need to be built ( by the build system, which it does ), and pointed to when executing jtreg from the command line, e.g. jtreg ...

Re: Request Review JDK-8182029: Make the top-level docs index.html to a HTML-level redirect to the API overview page

On 13/06/2017 06:21, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8182029/webrev.00/ JBS issue: https://bugs.openjdk.java.net/browse/JDK-8182029 This patch replaces the top-level docs index.html to a HTML-level redirect to the API overview page. We can come back to

Re: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc

On 31/05/2017 15:34, Roger Riggs wrote: Please review javadoc markup change to update to html5 acceptable to doclint. The table formatting is updated to html5 markup. The Docs build is updated to require doclint html5. Webrev: jdk:

Re: Review Request: JDK-8179035: Include tool modules in unified docs

On 20/04/2017 19:37, Mandy Chung wrote: A few modules are missing in the unified docs such as jdk.jcmd, jdk.jdwp.agent, jdk.jstatd, etc. Some tool modules are providers and they were in the initial set. The modules that are neither a provider nor exporting any API package are missed in the

Re: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory

On 20/04/2017 17:47, Mandy Chung wrote: In this case, which module should jdwp-protocol.html spec belong to? Not jdk.jdwp.agent then. The suggestion of the modular specs layout in the docs bundle may not apply. jdwp-protocol.html is the JDWP protocol so it's implemented by both the debugger

Re: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory

On 20/04/2017 17:26, Mandy Chung wrote: JDI and JDWP are not Java SE and no need to handle that. Just a small correction to this. The JDWP spec is Java SE. JDI is course JDK-specific, as is the JDWP transport interface. -Alan

Re: RFR: JDK-8179022 Add serialization spec as markdown

On 20/04/2017 14:49, Magnus Ihse Bursie wrote: Here's the first step towards fixing JDK-8177434 . A framework is added for converting markdown specs to html using pandoc. The Java serialization spec is added in markdown format as a proof of

Re: RFR: JDK-8178038, JDK-8178039, JDK-8178316 Javadoc specs directory

On 20/04/2017 08:37, Magnus Ihse Bursie wrote: : I have two suggestions, but I don't know if either of them is possible: 1) Move the JDWP.java file to jdk.jdwp.agent, and make sure it's properly exported from jdk.jdwp.agent to jdk.jdi. (From my point of view, this seems like the logical thing

Re: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java

On 19/04/2017 13:54, Magnus Ihse Bursie wrote: With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes/module-info.java instead. I also took

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 03/04/2017 19:41, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. In DefaultImageBuilder.storeFiles then

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 03/04/2017 22:38, Simon Nash wrote: : My comment was regarding the change of value for OS_NAME. Given that there is no compatibility issue here, does it make sense for the new value to be something that is no longer current in Apple terminology? Just on compatibility then just to say

Re: 8174823: Module system implementation refresh (3/2017)

On 23/03/2017 22:24, Mandy Chung wrote: REQUIRED_OS_NAME was used as OS_NAME in `release` file. Previously it was “Darwin” which is inconsistent with the value of “os.name” system property (“Mac OS X”). This change made OS_NAME to contain the same value as “os.name” system property. Right,

Re: RFR: JDK-8176172: Imported FX modules have have residual_imported.marker file

As a short term solution then this looks okay to me. -Alan On 07/03/2017 08:51, Erik Joelsson wrote: Hello, The jmods for the imported javafx modules end up with _imported.marker files in them. The root cause of this issue is that we don't have a coherent naming scheme for our touch/marker

Re: RFR: JDK-8174172: Race when building java.base.jmod

On 08/02/2017 11:33, Erik Joelsson wrote: When building java.base.jmod, we use --hash-modules to include hashes of all the non upgradeable jmods in java.base.jmod. The make dependencies are setup to make sure all non upgradeable jmods are built before java.base.jmod. In some cases, this risks

Re: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent

On 02/02/2017 22:27, Mandy Chung wrote: libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ This patch also takes out the qualified exports of

Re: Review Request: JDK-8173608: Separate JDK management agent from java.management module

On 30/01/2017 23:48, Mandy Chung wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html Just catching up this. It looks like the native methods for jdk.internal.agent.FileSystemImpl have been moved to libmanagemtn_rmi.so, shouldn't this be

Re: RFR: JDK-8170483: Remove modules_src_jake workaround for JavaFX transition to new module-info syntax

On 26/01/2017 14:36, Erik Joelsson wrote: When the last jake->jdk9 push was done, a temporary workaround for dealing with Javafx was needed. Javafx has now been fully updated to only deliver the new format so the workaround should be removed. Bug:

Re: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11

On 22/01/2017 19:27, Xueming Shen wrote: The assumption is the remove of the version tag can help us to easily get the diffs from the webrev directly in future upgrade. Here is the webrev with the diff by listing old and new files in a webrev list file.

Re: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11

On 21/01/2017 20:41, Xueming Shen wrote: Erik, Alan Here is the webrev that dropped the version number from the name. http://cr.openjdk.java.net/~sherman/8173140/webrev Switching to zlib looks good although it's impossible to see the changes in this webrev because all the files show up as

Re: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11

On 20/01/2017 20:15, Xueming Shen wrote: Hi, Please review the change to upgrade the zlib bundled in jdk repo from v1.2.8 to v1.2.11. jdk9 by default has been configured to build by using the native/ platform/os's zlib on all non-windows platform [1] So the change will only have effect on

Re: RFR: 8172709 Upgrade to jtreg 4.2 b05

On 12/01/2017 10:43, Staffan Larsen wrote: jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test

Re: RFR: JDK-8171249: modules_legal from imported modules are not read by the build

On 15/12/2016 10:40, Erik Joelsson wrote: Hello, Please review this small fix following up JDK-8169925. That change forgot to add AC_SUBST for the new import modules variables. By adding those I have verified that modules_legal from imported modules are linked into the images. Bug:

Re: Review Request: JDK-8171201 & JDK-8171202: Drop java.compact$N aggregator modules

On 14/12/2016 16:19, Mandy Chung wrote: : Fixed. All looks good to me. -Alan

Re: Review Request: JDK-8171201 & JDK-8171202: Drop java.compact$N aggregator modules

On 14/12/2016 06:49, Mandy Chung wrote: JDK-8171201: Drop java.compact$N aggregator modules JDK-8171202: Rename jdk.crypto.pkcs11 and jdk.pack200 to end with Java letters http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171201%2b8171202/webrev.00/ The hg moves are showing up as new files in

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

On 07/12/2016 21:28, Mandy Chung wrote: : Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169925/webrev.00/ I went over the changes to the jmod tool, jlink, and the new plugin to dedup legal notices. It looks straight-forward, I just wondering about the sym links hat

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

On 08/12/2016 09:44, Erik Joelsson wrote: : In make/InterimImage.gmk, -J-Djlink.debug=true looks like left over debug code. I'd prefer to keep this as t's really hard to debug issues when jlink fails in the build. -Alan.

Re: RFR: JDK-8168924: Add jdk.unsupported to the compact profile builds

On 30/11/2016 14:18, Erik Joelsson wrote: This patch adds the jdk.unsupported module to the compact profile images. Looks fine.

Re: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory

On 22/11/2016 21:07, Mandy Chung wrote: This patch moves src.zip and jrt-fs.jar from the top-level into the `lib` directory in the run-time image as we proposed [1]. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ This looks good. A minor point in

Re: RFR: JDK-8170279: Langtools test/Makefile ignores failed tests

On 23/11/2016 12:29, Erik Joelsson wrote: After JDK-8167354, when a test fails in jtreg, the langtools test/Makefile ignores the result and exits with 0. This causes (at least) JPRT jobs to not fail when langtools tests fail. The reason for this is the added "| tee" construct which overrides

Re: RFR: JDK-8170184 Remove incorrect comments about generated jvmt.h

On 22/11/2016 13:56, Magnus Ihse Bursie wrote: The inclusion of the generated jvmti.h was fixed in JDK-8063154, however the comments still state that this does not work. Bug: https://bugs.openjdk.java.net/browse/JDK-8170184 Patch inline: diff --git a/make/gensrc/GensrcJvmti.gmk

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

On 28/10/2016 09:34, Erik Joelsson wrote: but maybe jlink is able to strip the debug info from java classes now? In that case we could consider globally enabling -g for product builds. Yes, it can, `jlink --strip-debug` (or `-G`). A good test would be to build with `javac -g` and then strip

Re: [9] RfR: 8167187: Exported elements referring to inaccessible types in jdk.jsobject

On 26/10/2016 21:05, David DeHaven wrote: Please review these fairly trivial patches for: https://bugs.openjdk.java.net/browse/JDK-8167187 It was decided that since getWindow is deprecated and likely to be removed in a future release that it's not worth changing the signature which would

Re: RFR: JDK-8167195: VM fails to initialize intermittently when running jmod to create some images

On 05/10/2016 16:47, Erik Joelsson wrote: Hello, Please review this small patch, which should fix an issue introduced by JDK-8166948. At least on Windows, running jmod on the exploded image may fail if the new optimization target is running concurrently. I had missed adjusting the

Re: RFR: JDK-8166948: Exploded image too slow to be usable

On 30/09/2016 09:03, Erik Joelsson wrote: During the build process, we create an exploded image as an interim step before linking the real JDK and JRE images. This exploded image is used both for running certain build tools during the build but is also used by developers when needing a quick

Re: RFR: JDK-8166948: Exploded image too slow to be usable

On 30/09/2016 10:43, Chris Hegarty wrote: Ooh, this is quite clever, levering the already computed packages list from the running VM to add the packages attribute to the module info. One minor concern ( which I think should be ok ) is the updating of the module-info.class files of the running

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

On 27/09/2016 13:42, Jan Lahoda wrote: Hi, Any feedback on the top-level repository changes? http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/ This looks okay to me. Some of these should be looked at and I wonder if you have created any bugs. In passing I see recipes for

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:27, Sundararajan Athijegannathan wrote: jjs does not yet support module related options. So, user modules can not be scripted directly with jjs as of now. Only way is to use to launcher with -mp along with -m for jjs main class. With the change, only module name needs to be

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:10, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8165595/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165595 I'm not sure that asking users to use -m is right here, esp. when the modules contains launchers. Also

Re: Tool to create OpenJDK compact profiles for x86_64 platform

On 02/09/2016 06:44, Waldek Kozaczuk wrote: During my research about OpenJDK 8 compact profiles I found out it is almost close to impossible to find pre-built images of those profiles for x86_64 platform. By analyzing the openJDK build process I came to the conclusion that it should be

Re: Missing sources stepping through Jigsaw code?

On 29/07/2016 11:54, Andrew Dinn wrote: : Well, that's very interesting but it wasn't this code that was missing, rather a significant swathe of the core JDK runtime classes. From what I can tell then src.zip, going back to JDK 1.1 at least, didn't ever include all .java sources. Aside from a

Re: Missing sources stepping through Jigsaw code?

On 29/07/2016 10:43, Andrew Dinn wrote: : As Alan indicated, this is, of course, merely an artefact the EA Jigsaw releases being Oracle builds. The build system can be configured to include the missing sources in src.zip and seems to be so configured by default. I cannot see Red Hat being happy

Re: Missing sources stepping through Jigsaw code?

On 28/07/2016 19:04, Jason T. Greene wrote: : Wow! That's very unfortunate. If there's no way to correlate a source snapshot to an OpenJDK binary; that's going to be a very strong motivator for using a thirdparty build. The `release` file in the top-level directory has the hg tips used in

Re: Missing sources stepping through Jigsaw code?

On 28/07/2016 17:58, Andrew Dinn wrote: : 2) More pertinently, is this merely a reflection of Oracle's policy regarding distribution of sources or is this also the policy adopted for OpenJDK builds? Yes, it's a policy issue (outside of our control, and not specific to Jigsaw EA builds). If

Re: conf vs. lib

On 27/07/2016 12:38, Wang Weijun wrote: : Yes. Or just CACERTS? This will be ambiguous. It would be but do do you really want to use a token here? : How much is creating a new name or a new option worth? Do we plan to move cacerts again? Unless we backport it (I believe back porting a

Re: conf vs. lib

On 27/07/2016 10:45, Wang Weijun wrote: : I suggest we create a new special -keystore value "<>" which acts like an alias of the cacerts file. Creating a new option means we have to document its relation with the existing -keystore option. The new name can also work with the -importkeystore

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

This looks right but I'm curious why it was initially implemented to use VERSION_NUMBER. -Alan On 26/07/2016 13:20, Volker Simonis wrote: Forwarding to build-dev in the hope to get a review there :) More details can be found in the bug description. Thank you and best regards, Volker

Re: RFR: 8154399, 8159096, export packages containing standard javadoc doclet

On 17/06/2016 03:28, Jonathan Gibbons wrote: Please review this simple fix for two related aspects of the same problem: Export the "standard doclet" used by javadoc, such that it is possible to derive alternative doclets, either by delegation or subtyping. In JDK 9, javadoc has a "new"

Re: RFR: JDK-8055735: JDK_FILTER is broken

On 09/06/2016 13:18, Claes Redestad wrote: On 2016-06-09 14:11, Erik Joelsson wrote: You have a point, we should avoid relying on uninitialized variables being empty. http://cr.openjdk.java.net/~erikj/8055735/webrev.top.02/ Thanks, looks good to me! This looks okay to me too. -Alan.

Re: RFR: JDK-8155786: Determine modules depending on upgradeable modules directly and indirectly

On 23/05/2016 13:27, Ivan Krylov wrote: (perhaps this question belongs to the jigsaw-dev list..) How upgradable modules are defined. JEP-261 uses this term but does not define it AFAICS. make/commons/Modules.gmk defines the list of upgradeable modules, look for UPGRADEABLE_MODULES. A module is

Re: RFR: JDK-8157507: JDK-8157348 broke gensrc of imported modules

Looks okay to me. On 21/05/2016 13:55, Erik Joelsson wrote: In JDK-8157348 I made build time modifications of module-info.java more restrictive by only adding exports if the exported package actually exists. This existence check missed looking in imported prebuilt classes and because of that,

Re: RFR: JDK-8155786: Determine modules depending on upgradeable modules directly and indirectly

On 18/05/2016 15:39, Erik Joelsson wrote: This patch replaces the list of indirectly upgradeable modules with a generated list. Bug: https://bugs.openjdk.java.net/browse/JDK-8155786 Webrev: http://cr.openjdk.java.net/~erikj/8155786/webrev.top.01/index.html This looks good to me. -Alan

Re: RFR: 8156756: Enable build-time use of resource ordering plugin

On 12/05/2016 09:37, Erik Joelsson wrote: Assuming you meant [1] and that you actually tried it, this looks fine, thanks! /Erik [1] http://cr.openjdk.java.net/~redestad/8156756/webrev.02/ I'm happy too. -Alan.

Re: RFR: 8156756: Enable build-time use of resource ordering plugin

On 11/05/2016 16:56, Claes Redestad wrote: Hi, please review this change to enable the --order-resources plugin during build, which helps cold start scenarios by improving locality Bug: https://bugs.openjdk.java.net/browse/JDK-8156756 Webrev:

Re: RFR: 8156560: Remove AddJsum

On 09/05/2016 18:12, Claes Redestad wrote: Hi, AddJsum is no longer needed/used and could be removed. Webrev: http://cr.openjdk.java.net/~redestad/8156560/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156560 Looks fine.

Re: RFR: JDK-8153685: Parfait integration missing in the new tools (jmod and jlink)

On 09/05/2016 12:50, Erik Joelsson wrote: Hello, These are open changes necessary for running the build with an Oracle internal tool. This patch moves the definitions of the make variables JLINK and JMOD to configure so that custom configure logic may override and change them. I also

Re: RFR: 8150044: Generate classlists at build-time

On 04/05/2016 15:05, Ioi Lam wrote: : Regarding the JDK changes, in HelloClasslist.java: Maybe add a comment about how/why you choose this particular set of operations? When the JDK evolves in the future, how should this file be changed? I notice that no GUI classes are used. Is the

Re: small changes, long build time

On 03/05/2016 02:48, David Holmes wrote: So what build target will ensure the exploded image is created and up to date? `make` without any target, that has always been the default. -Alan

Re: small changes, long build time

On 02/05/2016 03:14, David Holmes wrote: So jlink basically copies what is needed for a given configuration into the "image" destination? So where previously this was handled in the makefile and only what had changed needed copying, jlink will re-copy everything? Class files and resources

Re: small changes, long build time

On 01/05/2016 05:21, David Holmes wrote: The native code - java.c. Can't see any reason for jmods to be recreated every time I recompile that! The packaged modules contain the tools/launcher for that module. So if you touch java.c then the launchers for every tool are re-generated and thus

Re: small changes, long build time

On 30/04/2016 09:52, Ioi Lam wrote: Maybe the build system can generate more fine grained dependencies? If only private or non exported classes/packages are updated, no other modules need to be rebuilt If only an exported package is updated, then only other modules that import this package

Re: small changes, long build time

On 30/04/2016 08:32, David Holmes wrote: Just to add my concerns here, I was changing the launcher and building images and that caused the jmods to be rebuilt as well. I would not expect that so do we have missing dependency information in the build? By "changing the launcher" then do you

Re: small changes, long build time

On 30/04/2016 00:46, Pete Brunet wrote: Even small edits to code in the jdk source tree result in very long time build times now that jigsaw is merged in. Is anyone working on trying to improve that? Is there a workaround? When you touch code in a module then you can use "make " to just

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 27/04/2016 10:04, Chris Hegarty wrote: On 26 Apr 2016, at 18:21, Alan Bateman <alan.bate...@oracle.com> wrote: I took a second pass over it. One thing that I'm wondering about is whether BaseExtendedSocketOptions + Support should be collapsed into one abstract

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 26/04/2016 10:16, Chris Hegarty wrote: On 26 Apr 2016, at 09:20, Alan Bateman <alan.bate...@oracle.com> wrote: On 25/04/2016 22:01, Chris Hegarty wrote: One of the remaining open issues in JEP 200 [1] is that the base module exports the jdk.net package, thereby violating Princ

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 25/04/2016 22:01, Chris Hegarty wrote: One of the remaining open issues in JEP 200 [1] is that the base module exports the jdk.net package, thereby violating Principle 4 of JEP 200: a Java SE module must not export any non-SE API packages without qualification.

Re: RFR: JDK-8154430: Imported modules rebuilt on second run when nothing has changed

On 18/04/2016 10:08, Erik Joelsson wrote: When building a configuration with imported modules, the first incremental build will often rebuild all the imported modules module-info.java. This is caused by the recipe for copying the pre compiled imported classes deleting the vardeps file for

Re: (urgent) RFR: JDK-8154292: jdk9-dev: All SE builds failed on 2016-04-14

On 15/04/2016 16:49, Erik Joelsson wrote: This is currently breaking RE builds in 9-dev. None of our normal build reviewers are available today. Looking for help. I've skimmed through the changes and see how --enable-jtreg-failure-handler is implemented considered it Reviewed. -Alan.

Re: RFR: JDK-8154070: Configuration script unable to detect boot JDK's modules support

On 12/04/2016 14:07, Erik Joelsson wrote: It's the exact same change I just did in that file in jake so should merge fine. Luckily the format -Xpatch:foo=bar is already accepted in JDK 9 for the purpose needed here. I don't want to wait with this patch as it's needed for other work. Okay, I

<    1   2   3   4   5   6   7   >