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 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 class ExtendedSocketOptions (or better name) w

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 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 Principle 4 of JEP 200: a Java SE module

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. http://cr.openjdk.java.net/~c

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 the

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 s

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

On 12/04/2016 13:54, Erik Joelsson wrote: The current configure test for the boot JDKs module support is broken since the -Xpatch argument that is used to detect it has changed format. Related to this, the --with-build-jdk argument is also broken since the version string changed for JDK 9. Bu

Re: RFR: JDK-8153660: jwdp.so/dll missing from JRE image

On 07/04/2016 09:55, Erik Joelsson wrote: Hello, This small patch adds the module jdk.jdwp.agent to the JRE image. Looks good, this was accidentally dropped when we integrated JEP 220. -Alan

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 p

Re: Review request 8153217: javafx modules are not included in the jre

On 31/03/2016 21:03, Mandy Chung wrote: I have yet to understand why the eval doesn’t do its work. This patch includes ReadImportMetaData in make/Images.gmk and make/gensrc/GensrcModuleLoaderMap.gmk. I need to push this fix to unblock jdk9/client testing. http://cr.openjdk.java.net/~mchun

Re: Review request 8153211: Convert build tool to use the new -XaddExports syntax in bootcycle build

On 31/03/2016 17:56, Mandy Chung wrote: A few build tools are using the old -XaddExports syntax that should switch to the new syntax: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153211/webrev.00/ Mandy This looks okay, are you planning to push these to jake or jdk9/dev? -Alan

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

Are you sure your boot JDK is jdk-9+111? If it doesn't support -Xpatch then it's probably older build. In any case, the boot JDK should be JDK 8. Yes, the JDK can build itself but it's can be very fragile to attempt to build it with a JDK 9 that isn't quite in sync (esp. as command-line opti

Re: Review request 8153125: rmic from bootcycle build should launch with -m jdk.rmic/sun.rmi.rmic.Main

On 31/03/2016 03:25, Mandy Chung wrote: diff --git a/make/rmic/RmicCommon.gmk b/make/rmic/RmicCommon.gmk --- a/make/rmic/RmicCommon.gmk +++ b/make/rmic/RmicCommon.gmk @@ -31,7 +31,13 @@ ## -RMIC := $(J

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

On 24/03/2016 12:15, Erik Joelsson wrote: New webrev with shorter lines in SocketOptionRegistry.java.template. http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ This looks good. -Alan.

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants

On 23/03/2016 16:14, Erik Joelsson wrote: : On 2016-03-23 12:13, Erik Joelsson wrote: There are however 3 that, at least on Linux, are defined as an enum and not constants, which makes them unavailable to the preprocessor. These are: IPPROTO_TCP = 6 IPPROTO_IP = 0 IPPROTO_PV6 = 41 I would

Re: RFR 8152268: jjs tool makefile should use --addmods ALL-SYSTEM

On 23/03/2016 08:59, Sundararajan Athijegannathan wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8152268/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152268 This looks okay, similar to what we had to do with appletviewer. -Alan.

Re: RFR: JDK-8149545: Add zlib devel package to devkit sysroot on Linux

On 21/03/2016 14:17, Erik Joelsson wrote: In JDK-8031767, the default for zlib is being changed to system. To support that in our builds at Oracle, we need to add zlib devel package to the sysroots of our devkit. While editing and regenerating the devkit, I noticed that one of the elfutils

Re: RFR(XS): 8151987: jexec should be executable

On 16/03/2016 12:19, Volker Simonis wrote: So here comes a new (and even smaller) version of the patch which fixes jlink in the same way: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987.v1/ Please feel free to pus

Re: RFR(XS): 8151987: jexec should be executable

On 16/03/2016 11:08, Volker Simonis wrote: Hi, can I please have a review for the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987/ https://bugs.openjdk.java.net/browse/JDK-8151987 'jexec' is currently not executable in the created images (i.e. images/{jdk,jre}/lib

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

On 05/03/2016 18:54, David DeHaven wrote: I've updated the webrev, hopefully one last time with feedback from Joe Darcy. http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/ - Relocated package Javadoc to above the package declaration in package-info.java - Reworded the Javadoc on the defau

Re: RFR: JDK-8151297: Class name change for CLDRLocaleDataMetaInfo_jdk_localedata needs updating in makefile

On 04/03/2016 15:45, Erik Joelsson wrote: When the generated class sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo_jdk_localedata changed names to sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo inJDK-8150434 , the make target

Re: [9-dev] RfR: JDK-8132743: Move netscape.javascript package from jdk.plugin to new module

On 04/03/2016 04:54, Mandy Chung wrote: On Mar 3, 2016, at 7:36 PM, David DeHaven wrote: Updated webrev: http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/ Looks fine to me. Thanks for the update. Just reading the javadoc again and I wonder about this statement in the package descri

Re: RFR 8148187 : Remove OS X-specific com.apple.concurrent package

On 01/03/2016 21:16, Brent Christian wrote: For your review is a webrev of this change: http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/ This looks good to me, in particular the move of FileManager.m into the right source tree as it was just wrong for that to be in jdk.deploy.osx when

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 10/02/2016 13:57, Seán Coffey wrote: I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least conside

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 08/02/2016 10:42, Seán Coffey wrote: Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries. JDK-8133206 would be one such example. Jus

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 05/02/2016 18:55, Xueming Shen wrote: Hi Please help codereview the change to build the jdk9 runtime to use the system zlib on Solaris and Linux platforms by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ I'm hap

Re: RFR: JDK-8148955: libjimage.so compiled with wrong flags

On 03/02/2016 13:50, Erik Joelsson wrote: The library libjimage.so consists of C++ source files, but is currently setup to compile using CFLAGS_JDKLIB instead of CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few differences due to the compilers taking very different arguments.

Re: 8035473: [javadoc] Revamp the existing Doclet APIs

On 25/01/2016 15:49, Kumar Srinivasan wrote: HI Alan, Mandy, Does this look right ? + + jdk.javadoc.doclet + + + jdk.javadoc.doclet.taglet + Yes, this looks right. -Alan

Re: 8035473: [javadoc] Revamp the existing Doclet APIs

On 22/01/2016 22:50, Kumar Srinivasan wrote: Hi All, Please review the following build changes: JDK changes: * simple entry point change http://cr.openjdk.java.net/~ksrini/8035473/webrev.07/webrev.jdk.0/ Top forest repo: * configuration changes to use the new javadoc/doclet implementation *

Re: RFR: JDK-8147795 Build system support for BSD

On 20/01/2016 10:54, Magnus Ihse Bursie wrote: During my spare time last autumn, and in the holidays, I've been playing around with the three major BSDs (FreeBSD, OpenBSD and NetBSD), trying to learn something new. (Yeah, I know, this proves that I have no life :-)). And what better way to le

Re: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management)

On 14/12/2015 16:55, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArgum

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 25/11/2015 16:53, Jaroslav Bachorik wrote: Updated webrevs: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.01/top http://cr.openjdk.java.net/~jbachorik/8043138/webrev.01/jdk Thanks to Erik J. for helping me with the build script! Updated version looks good to me. -Alan

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 25/11/2015 09:25, Jaroslav Bachorik wrote: I don't think we can just repackage these interfaces - they are remote API and we would break compatibility (eg. JDK 8 jvmstat would not be able to query JVM exposed via JDK 9 jstatd). You're right. there might be an expectation on interop althou

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 24/11/2015 16:03, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8043138 Webrevs: * top level: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.00/top * jdk: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.00/jdk This p

Re: RFR 8043138: Attach API should not require jvmstat rmi protocol

On 25/11/2015 08:11, Staffan Larsen wrote: On 24 nov. 2015, at 17:03, Jaroslav Bachorik wrote: Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8043138 Webrevs: * top level: http://cr.openjdk.java.net/~jbachorik/8043138/webrev.00/top * jdk: http://cr.openjd

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 16:07, Attila Szegedi wrote: : Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively “provider” seems like a weaker category (exposes a service provider but doesn’t have its own API), so (without knowing the particul

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:43, Sundararajan Athijegannathan wrote: But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. Sure, it could go in either but we mostly treat it as a service provider. -Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk:

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 19/11/2015 23:15, Attila Szegedi wrote: Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API tha

Re: RFR: JDK-8143036: Make install target does not depend on images

On 16/11/2015 09:17, Erik Joelsson wrote: Make install target should depend on images. Somehow this dependency got lost in JDK-8054834. Bug: https://bugs.openjdk.java.net/browse/JDK-8143036 Patch: diff -r 106c06398f7a make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -462,6 +462,8 @@

Re: [9] RFR of 8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build

On 05/11/2015 04:19, Martin Buchholz wrote: Alright, it's a much better situation if we're not giving up on fixing the underlying problem. I don't like temporary fixes. They tend to become permanent. I agree and view this dialing down of the optimization level as temporary until the issue i

Re: RFR: JDK-8141444 Clean up building of JDK launchers

On 05/11/2015 09:41, Magnus Ihse Bursie wrote: If you need to do jigsaw changes, sure, just do what's needed. However, it sounds like you still need a main class, but in addition you also need a module. If that's the case, it seems that you could keep the MAIN_CLASS and just add a MODULE. I

Re: RFR: JDK-8141444 Clean up building of JDK launchers

On 05/11/2015 07:27, Magnus Ihse Bursie wrote: The JDK launchers have been built by a macro which is using positional arguments instead of named argument. This needs to be fixed to be able to properly track what is happening. Some additional TLC for launchers is also needed. To verify the f

Re: RFR: JDK-6512052 remove java-rmi.exe and java-rmi.cgi

On 03/11/2015 10:29, Magnus Ihse Bursie wrote: Here's an old bug from the Good Riddance Dept. The TLDR; version: The java-rmi launcher is broken and irrelevant, at the same time. And has been since JDK6 or so. Bug: https://bugs.openjdk.java.net/browse/JDK-6512052 WebRev: http://cr.openjdk.ja

Re: RFR 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

On 02/11/2015 10:28, Jaroslav Bachorik wrote: On 2.11.2015 09:28, Alan Bateman wrote: On 02/11/2015 08:08, Jaroslav Bachorik wrote: Please, review the following build change Issue : https://bugs.openjdk.java.net/browse/JDK-8140481 Webrev: http://cr.openjdk.java.net/~jbachorik/8140481

Re: RFR 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

On 02/11/2015 08:08, Jaroslav Bachorik wrote: Please, review the following build change Issue : https://bugs.openjdk.java.net/browse/JDK-8140481 Webrev: http://cr.openjdk.java.net/~jbachorik/8140481/webrev.00 Currently, the 'jdk.management' module is not a part of the JRE image even though i

Re: RFR 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer

On 02/11/2015 08:34, Jaroslav Bachorik wrote: On 2.11.2015 09:28, Alan Bateman wrote: On 02/11/2015 08:08, Jaroslav Bachorik wrote: Please, review the following build change Issue : https://bugs.openjdk.java.net/browse/JDK-8140481 Webrev: http://cr.openjdk.java.net/~jbachorik/8140481

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

On 15/10/2015 19:07, Bob Vandette wrote: Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. https://bugs.openjdk.java.net/browse/JDK-8136556 The change involves: 1. Producing “.a”

Re: RFR [9] 8134254: JShell API/tool: REPL for Java into JDK9

On 09/10/2015 20:48, Jan Lahoda wrote: Hi, I'd like to ask for a review of top-level and jdk repository changes needed for the JShell/REPL tool. The top-level repository changes: http://cr.openjdk.java.net/~rfield/jshell_base_webrev_v0/ The jdk repository changes: http://cr.openjdk.java.net/

Re: Building Valhalla

On 02/10/2015 21:36, Maurizio Cimadamore wrote: I believe this has been caused by the latest push... try doing: make jimages afaik that should not run the last verification step ;-) Maurizio Yeah, I'm sure the usages of the classfile API are just convenience at this point. I assume eventual

Re: RFR: JDK-8138636: bootcycle-images build fails

On 30/09/2015 15:58, Erik Joelsson wrote: Please review this small fix for the bootcycle-build, which broke when I removed the interim-corba build. In JDK 9 then we have moved module java.corba to the extension class loader. So if code on the boot class path has a reference to types in the

Re: RFR: JDK-8137088: Drop building of interim_java.corba

On 25/09/2015 14:08, Erik Joelsson wrote: Hello, Please review this change to the build of JDK 9, which drops building of interim-corba. The interim build of java.corba has historically been needed for rmic -iiop but it is no longer needed in the build since the JMX remote API dropped suppo

Re: RFR (XXL): JEP 243: Java-Level JVM Compiler Interface

On 16/09/2015 13:57, Magnus Ihse Bursie wrote: : * modules.xml: Make sure you get sign-off from a Jigsaw developer for modifying this file. The update to modules.xml looks fine. -Alan.

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

On 16/09/2015 14:06, David M. Lloyd wrote: Also I could be wrong but it looks to me like the jigsaw/jake forest's equivalent module graph has evolved somewhat, and thus doesn't quite match this file anyway. jigsaw/jake is currently at jdk9-b81. There may be changes backed up in jdk9/dev that

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

On 16/09/2015 14:04, Magnus Ihse Bursie wrote: Does this mean that updates to modules.xml between now and the integration-to-come of jigsaw/jake do not anymore need specific approval? I think we should keep the status quo and CC jigsaw-dev when there are changes to modules.xml. If nothing els

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

On 16/09/2015 13:28, Magnus Ihse Bursie wrote: On 2015-09-11 18:00, Attila Szegedi wrote: Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code” The revision incorporates the foll

Re: build concurrency

On 14/09/2015 17:05, Erik Joelsson wrote: Hello, When I implemented the heuristic to choose a suitable default concurrency, I only ever worried about the build. I think having tests use the same concurrency setting must be a new feature? In any case, it seems like there is a case for reduci

Re: RFR 8134260: jjs in jre directory fails with "Could not find or load main class jdk.nashorn.tools.jjs.Main"

On 25/08/2015 14:24, Sundararajan Athijegannathan wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8134260/ for https://bugs.openjdk.java.net/browse/JDK-8134260 jdk.nashorn.tools.jjs and jdk.internal.le should exist in jre's appmodules.jimage with this change and so jjs would work

Re: RFR 8043937: Drop support for the IIOP transport from the JMX RMIConnector

On 21/08/2015 12:49, Jaroslav Bachorik wrote: Updated webrev top-level: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.03 Updated webrev jdk: http://cr.openjdk.java.net/~jbachorik/8043937/webrev.03/jdk Contains changes to the top level repo as well as a correct version of jdk/make/rm

Re: "make clean" compiles files.

On 08/07/2015 14:19, Magnus Ihse Bursie wrote: This is a temporary solution which hopefully goes away when we get rid of modules.xml. and modules.xml will go away when we bring in the module system. -Alan

Re: Openjdk profiles

On 08/07/2015 12:45, GAUVIN Florian wrote: Hi, For a project I have to build OpenJDK with buildroot. The goal is to have an image as small as possible. So my question is, does there is a make option to build only one compact profile (compact1, compact2 or compact3) of Openjdk. Regards, Gauvin F

Re: JDK 9 RFR of JDK-8080722: Revisit how to check for doclint reference warning during the build

On 07/07/2015 22:09, joe darcy wrote: *ping* Patch below: --- a/make/Javadoc.gmkTue Jun 23 15:11:56 2015 +0200 +++ b/make/Javadoc.gmkMon Jun 29 12:11:03 2015 -0700 @@ -410,7 +410,8 @@ $(prep-target) @($(call COMMON_JAVADOCFLAGS) ; \ $(call COMMON_JAVADOCTAGS) ;

Re: [8u60] RFR: 8129926: Sub-packages in jdk.* are present in all Compact Profiles when they should not be

On 30/06/2015 03:03, David Holmes wrote: : http://cr.openjdk.java.net/~dholmes/8129926/webrev/ *** 205,214 --- 205,216 javax/sound \ javax/swing \ javax/xml/bind \ javax/xml/soap \ javax/xml/ws \ + jdk/internal/instrumentation \ + jdk/management

Re: [8u60] RFR: 8129850: java.util.Properties.loadFromXML fails on compact1 profile

On 26/06/2015 13:10, David Holmes wrote: : webrev: http://cr.openjdk.java.net/~dholmes/8129850/webrev/ This looks okay to me. -Alan

Re: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs

On 25/06/2015 17:25, Jan Lahoda wrote: Hello, Based on the feedback I've received so far, I've uploaded an updated version of the patch: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ Notable changes: -avoided the dependency on java.desktop and java.datatransfer -adjusted the n

Re: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version

On 17/06/2015 14:49, Roger Riggs wrote: Hi Alan, Would there be any concerns about backporting to JDK 8? I don't think so but it will require the jdk8u maintainers to approve. The new helper APIs only veri

Re: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version

On 15/06/2015 22:58, Roger Riggs wrote: Please review code for Windows 10 that sets the System properties for os.name and os.version from the version of kernel32.dll. The update uses the same technique used by Hotspot in src/os/windows/vm/os_windows.cpp. The Windows link of CoreLibraries.gmk

Re: RFR 7191662: JCE providers should be located via ServiceLoader

On 16/06/2015 00:58, Valerie Peng wrote: It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. Here is the latest webrev (Security source/test changes o

Re: sjavac always compiled?

On 10/06/2015 10:21, Andreas Lundblad wrote: On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote: What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? I have now pushed a patch that adds t

Re: sjavac always compiled?

On 10/06/2015 09:00, Erik Joelsson wrote: Hello, Sjavac has always been compiled in the interim langtools step, the configure flag only affects using it to compile the rest of the java classes. Has a bug been created for this? I haven't created a bug for this as I wasn't sure if this was

sjavac always compiled?

There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). I seem to be running into build issues on OS X since then (clean build, not a reconfigure). My boot JDK is 8u31. My configure command does not specify --enable-sjavac so I'm surprised this code is being compiled. Anyone el

Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

On 08/06/2015 13:37, Magnus Ihse Bursie wrote: : The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and

Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

On 05/06/2015 15:07, Magnus Ihse Bursie wrote: This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch

Re: RFR 7191662: JCE providers should be located via ServiceLoader

On 27/05/2015 23:42, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the M

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 25/05/2015 09:53, Chris Hegarty wrote: If it is agreed that these files are needed, then I can look at expanding the ImageBuilder to do concatenate them. I agree with Mandy's point that java.security should be change to list the provider name rather than the class name. If that happens then

Re: RFR 7191662: JCE providers should be located via ServiceLoader,

On 22/05/2015 13:55, Chris Hegarty wrote: : I think it could be done either way. Valerie - have you considered not pushing the services configuration files with this change? With the change then the java.security configuration is still class names, not provider names, so the fallback should

Re: RFR 9: 8074818: Resolve disabled warnings for libjava

On 22/05/2015 01:42, Roger Riggs wrote: Oops, got the wrong host: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-fix-all-warnings-8074818/ Issues: 8074818: Resolve disabled warnings for libjava 8080007: Stop ignoring warnings for libjava Thanks, Roger In JDK_GetVersionInfo0 then I

Re: Excessive rebuilds of modules

On 20/05/2015 21:12, Roger Riggs wrote: Ioi, You can rebuild just the contents of a single module: % make java.base java.base-libs java.base-launchers Yes, and this works great when you are using an exploded build. It's possible that Ioi is looking for an images build of course. In general

Re: RFR: 8076473 Remove the jhat code and update makefiles

On 23/04/2015 13:06, Staffan Larsen wrote: Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread). JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 bug: https://bugs.openjdk.java.net/browse/JDK-807

Re: RFR: JDK-8076583: move jdk.Exported from langtools to jdk

On 03/04/2015 00:52, Jonathan Gibbons wrote: Sorry for the relatively wide distribution. JDK-8076583 is a conceptually simple cleanup, to move the source file for the jdk.Exported class from the langtools repo (where it is a singleton outlier) to the jdk repo (alongside most of the rest of the

Re: RFR: JDK-8075495: Update jtreg bin location in configure

On 19/03/2015 14:04, Magnus Ihse Bursie wrote: The comment above is not needed anymore. How does this work with different versions of JTReg? Do we need to support older versions with the win32 directory still in place? Older versions of jtreg can't be used to run some of the tests today. We

Re: RFR: JDK-8075495: Update jtreg bin location in configure

On 19/03/2015 09:56, Erik Joelsson wrote: Jtreg removed the platform specific bin directories. Configure still picks up the jtreg launcher from win32/bin. This needs to be fixed. This patch is for jdk9. The same patch applies to jdk8u-dev and I would like to fix it there too. Bug: https://bug

Re: RFR: JDK-8075056 Remove Version.java.template from jconsole

On 12/03/2015 12:54, Staffan Larsen wrote: The build for jconsole currently takes a template file and inserts the version number of the build into the file. We can simplify this by removing the template file and reading the java.runtime.version system property at runtime. bug: https://bugs.ope

Re: RFR: JDK-8074690 Fix for JDK-8074429 was not complete

On 09/03/2015 11:46, Magnus Ihse Bursie wrote: The fix for JDK-8074429 moved the jar tool into a new jdk.jartool module. However, it did not remove all references from the old module. Gensrc-jdk.dev.gmk still references the old jar path, wh

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

On 05/03/2015 01:13, Mandy Chung wrote: : 2. jar, jarsigner to jdk.jartool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ It seems reasonable to have both jar and jarsigner in the same module so I think this is good. This will also work if Ma

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

On 05/03/2015 01:13, Mandy Chung wrote: 3. policytool to jdk.policytool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ This part looks good to me. -Alan

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

On 05/03/2015 01:13, Mandy Chung wrote: : Separate webrevs for each issue: 1. pack200, unpack200 to jdk.pack200 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ I think this looks okay. In the unshuffle_list (for back/forward porting patches) the

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

On 05/03/2015 02:55, Wang Weijun wrote: - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 04/03/2015 15:03, Magnus Ihse Bursie wrote: I believe all warnings are important to check! Unfortunately, this has not been done for a lot of warnings for a lot of time. :( Right, although in the past we had some areas close to be cleared of warnings, it's just that we didn't keep up the effo

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

On 04/03/2015 13:17, Magnus Ihse Bursie wrote: : I intend to file individual bugs to handle these remaining warnings, so the net result will be a completely warning free build. I also intend to file individual bugs on all the libraries that has had warnings disabled. I expect the outcome of

Re: RFR 8073596 : Add jdk.management.cmm in boot.modules that needs sun.management.spi be exported to it

On 27/02/2015 20:55, Brent Christian wrote: Hi, Please review a small update to the module config files for a new jdk.management.cmm module. Webrev: http://cr.openjdk.java.net/~bchristi/8073596/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8073596 I also found a needed hook missing f

Re: RFR: JDK-8073328: Incremental build of gensrc broken

On 17/02/2015 15:38, Erik Joelsson wrote: Right, thanks for catching that. The OS specific file is not there for every OS. This patch should fix it. I'm testing all platforms now. Webrev: http://cr.openjdk.java.net/~erikj/8073328/webrev.jdk.03/ /Erik Updated webrev looks good. -Alan

Re: RFR: JDK-8073328: Incremental build of gensrc broken

On 17/02/2015 14:56, Erik Joelsson wrote: Hello, Please review this fix for the incremental build behavior of the gensrc build step. After JDK-8073152 the charsets would unconditionally get regenerated each time make was invoked. The actual culprit was a stray backslash which prevented the 't

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

On 16/02/2015 18:46, Xueming Shen wrote: : 1. Is list_old needed, I can't tell if this is checked in for use by future archaeologists. No, it's not used by any code. I just added it the last minute to be a reference for the future, as I'm deleting the original list sbcs, dbcs and extsbcs.

Re: [9] Review Request: 8039269 images/cursors should not be in ${java.home}/lib

On 16/02/2015 11:57, Sergey Bylokhov wrote: Hello, Here is an updated version of the fix: http://cr.openjdk.java.net/~serb/8039269/webrev.01 The updated webrev looks good (indentation inconsistent in places but that isn't important here). -Alan.

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

On 14/02/2015 20:30, Xueming Shen wrote: Hi, Please help review the changes for JDK-8073152 Issue: https://bugs.openjdk.java.net/browse/JDK-8073152 Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/ This change is to re-organize how the "standard" and "extended" charsets repository

Re: RFR: JDK-8073166: Unable to successfully build the merge of jdk9/hs with jdk9/dev

On 16/02/2015 10:57, Erik Joelsson wrote: Hello, When merging jdk9/dev and jdk9/hs, the following message appears and the build fails: gmake[2]: *** No rule to make target 'jdk.runtime-java', needed by 'jdk.runtime-libs'. Stop. gmake[2]: *** Waiting for unfinished jobs : # Declare

Re: [9] Review Request: 8039269 images/cursors should not be in ${java.home}/lib

On 13/02/2015 18:01, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 9. As requested cursor related properties/images were moved from /lib to the java.desktop. - Image prefixes were removed because I moved them to the os specific location. - Windows version of cursors.properties

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

On 09/02/2015 10:32, Martijn Verburg wrote: Hi Erik, You're correct, the module-deps.gmk file does not have java.transaction in there. modules.xml does contain it as an export for java.corba (which depends on java.base), i.e. In that case, it looks like your top-level repo isn't up to dat

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

On 06/02/2015 15:42, Martijn Verburg wrote: Hi Alan, Thanks for the quick response! I've executed: rm -rf build bash configure make clean images == Unfortunately the same error comes up: Cleaned all build artifacts. Building OpenJDK for target 'clean images' in configuration '

<    1   2   3   4   5   6   7   8   >