Re: Setting BOOT_RTJAR: rt.jar vs. 'sun.boot.class.path'

Hello Volker, I like this solution, even if it could be viewed as a bit of overkill. /Erik On 2013-11-14 17:35, Volker Simonis wrote: Hi, I wanted to solve 8026964: Building with an IBM J9 boot jdk requires special settings for BOOT_RTJAR (https://bugs.openjdk.java.net/browse/JDK-8026964)

hg: jdk8/tl: 8027963: Create unlimited policy jars.

Changeset: c009462c1e92 Author:erikj Date: 2013-12-04 12:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c009462c1e92 8027963: Create unlimited policy jars. Reviewed-by: wetmore, ihse ! common/autoconf/spec.gmk.in

hg: jdk8/tl/jdk: 8027963: Create unlimited policy jars.

Changeset: 427c78c88229 Author:erikj Date: 2013-12-05 09:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/427c78c88229 8027963: Create unlimited policy jars. Reviewed-by: wetmore, ihse ! make/CreateSecurityJars.gmk ! make/SignJars.gmk -

hg: jdk8/tl: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 53d74b77ee53 Author:erikj Date: 2014-01-08 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/53d74b77ee53 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb, ihse, tbell ! common/autoconf/generated-configure.sh !

hg: jdk8/tl/jdk: 8030781: System.setProperties(null) drops all system properties (RELEASE not set)

Changeset: 2437ccbf3504 Author:erikj Date: 2014-01-08 14:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2437ccbf3504 8030781: System.setProperties(null) drops all system properties (RELEASE not set) Reviewed-by: alanb + test/java/lang/System/SetPropertiesNull.java

hg: jdk8/tl/jdk: 8032217: failure in man page processing

Changeset: ff56039c4870 Author:erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk

Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

On 2014-01-23 09:32, Sergey Bylokhov wrote: On 23.01.2014 3:53, Vladimir Kozlov wrote: I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 Looks like the problem is that 8032348 is not pushed to the master workspace

Re: RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Hello Sherman, The build changes look good to me. /Erik On 2014-04-14 19:52, Xueming Shen wrote: Thanks Mandy and Alan for the review. webrev has been updated accordingly to (1) Removed the basic.sh. The tests are now using test.jdk to access the zipfs.jar directly (2) Updated most of the

Re: Review request: 8040059 Change default policy for extensions to no permission

Hello Mandy, The logic looks fine. Just some style issues. I would like indentation for the conditionals to be 2 spaces as is currently the standard in the makefiles. I would also like to have POLICY_SRC_LIST to be declared empty with := instead of just =. We only use = assignment when

Re: RFR: 8043666: Remove unused files from jaxp repository

Looks good to me, Joe. /Erik On 2014-05-23 17:23, huizhe wang wrote: Removing unused files in jaxp repository. Most of them are META-INF/services files used by Apache build process. The COPYING files at the bottom came with SAX, but they are included in the THIRD_PARTY_README file already.

Re: Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds

Hello Mandy, Looking at this, I just realized that $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/jdeps-modules.xml is a generated resource for a module and that you correctly added it to the gendata target. Then to make it fit with the new makefile model, the running of

Re: Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds

On 2014-08-27 16:39, Mandy Chung wrote: On 8/27/2014 3:19 AM, Magnus Ihse Bursie wrote: On 2014-08-27 10:26, Erik Joelsson wrote: Hello Mandy, Looking at this, I just realized that $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/jdeps-modules.xml is a generated resource

Re: Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds

Hello Mandy, That certainly looks better. A couple of more thoughts, and sorry for not pointing this out earlier, but the new structure is still new to me too. * The rmic targets also generate classes, so for modules.xml to be correct, I suspect you need to depend on that too. Simply add

Re: Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds

push. /Erik On 2014-08-28 19:21, Mandy Chung wrote: On 8/27/14 11:38 PM, Erik Joelsson wrote: Hello Mandy, That certainly looks better. A couple of more thoughts, and sorry for not pointing this out earlier, but the new structure is still new to me too. * The rmic targets also generate

Re: i18n dev [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

/ This includes: - a couple of fixes to the CLDR Converter - Added fallback for any bad SPI implementations which return null for requested instances. Still asking for review comments. Naoto On 8/8/12 2:13 PM, Naoto Sato wrote: On 8/7/12 2:57 AM, Erik Joelsson wrote: See inline On 2012-07-13 22:20

Re: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

See inline On 2012-07-13 22:20, Kelly O'Hair wrote: Something seems strange here: http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html It's like someone was avoiding overall quotes, but using them to add spaces somehow... I sure would like to get rid

Re: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK

Looks good to me now. /Erik On 2012-11-02 22:00, Kumar Srinivasan wrote: Hi David, Kelly, Erik, as Kelly stated the jdk only build, uses the compiler from the import JDK, this works with -source 8 -target, which was prepped by Joe earlier. I also checked with a jdk only jprt build

Re: Review request: 8003562: Provide a command-line tool to find static dependencies

Looks good. /Erik On 2012-12-07 22:55, Mandy Chung wrote: This is the updated webrev. It includes Erik's makefile changes and small change - be consistent with javap, jdeps can take classnames as the input argument or wildcard * to analyze all class files that replaces the -all option.

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Hello, Nice to see a good attempt at getting the new build in order. While this looks like it works, I have a few comments: In makefiles/CompileLaunchers.gmk * OPENJDK_TARGET_CPU_LIBDIR is empty on macosx, so you can safely use the same definition of BUILD_JSPAWNHELPER_DST_DIR for all

Review Request: 8005856: build-infra: Remove special handling of base module classes header generation

Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation

Re: Codereview request for 8003680: JSR 310: Date/Time API

On 2013-01-23 01:14, David Holmes wrote: On 23/01/2013 9:08 AM, Xueming Shen wrote: On 01/22/2013 02:58 PM, Alan Bateman wrote: On 22/01/2013 22:19, David Holmes wrote: All of the jar building was modified so that jars go into images/lib not jdk/lib. So it should not be necessary (or

Re: OPENJDK env var not playing well with new build

On 2013-01-23 11:30, Weijun Wang wrote: I thought building an OpenJDK or Oracle JDK can be fully controlled by using the --enable-openjdk-only configure option, but it seems the OPENJDK env variable still plays a part. If the variable is set to true and --enable-openjdk-only is not provided,

Re: OPENJDK env var not playing well with new build

On 2013-01-23 12:54, David Holmes wrote: On 23/01/2013 8:58 PM, Erik Joelsson wrote: On 2013-01-23 11:30, Weijun Wang wrote: I thought building an OpenJDK or Oracle JDK can be fully controlled by using the --enable-openjdk-only configure option, but it seems the OPENJDK env variable still

Re: OPENJDK env var not playing well with new build

On 2013-01-23 13:23, Weijun Wang wrote: On 01/23/2013 07:54 PM, David Holmes wrote: On 23/01/2013 8:58 PM, Erik Joelsson wrote: On 2013-01-23 11:30, Weijun Wang wrote: I thought building an OpenJDK or Oracle JDK can be fully controlled by using the --enable-openjdk-only configure option

Re: CFR - updated 8001667: Comparator combinators and extension methods

The build change looks fine. The new build will not need any changes. /Erik On 2013-02-06 04:51, Henry Jen wrote: Hi, This is an update on previous reviewed version, there are two new method introduced for Comparators to convert a Comparator into a BinaryOperator and corresponding test cases.

Re: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at java.home/lib/zi with JSR310's tzdb.

The build part of this review looks good to me. /Erik On 2013-02-07 19:31, Xueming Shen wrote: Hi, 8007572: Replace existing jdk timezone data at java.home/lib/zi with JSR310's tzdb. Webrev: http://cr.openjdk.java.net/~sherman/8007572/ Note: JDK/JRE has been using the time zone data at

Re: Review 8007703: Remove com.sun.servicetag API

Looks good to me. /Erik On 2013-02-15 00:31, Mandy Chung wrote: Remove com.sun.servicetag that we no longer support. This includes updates the makefiles and so include build-infra to review this change. It's solely JDK implementation-specific that was added to support JDK product

Re: RFR: 8009428 and 8009429 - Profile related fixes and clean ups

On 2013-03-08 10:19, Alan Bateman wrote: On 08/03/2013 01:48, David Holmes wrote: Not sure which is best list for this given Alan will likely be the only reviewer anyway :) Webrevs under: http://cr.openjdk.java.net/~dholmes/8009428_8009429/ As further background to others, the reverting of

Re: RFR 8009517: Disable fatal compiler warning in the old build

I have a suggestion for how to at least partly enable -Werror in the new build. The penalty is slightly longer compile time, but the difference should be negligible. We split the big java compilation in jdk in two. The first pass with -Werror and all warnings turned on, the second without. We

Re: RFR 8009517: Disable fatal compiler warning in the old build

:30, Erik Joelsson wrote: I have a suggestion for how to at least partly enable -Werror in the new build. The penalty is slightly longer compile time, but the difference should be negligible. We split the big java compilation in jdk in two. The first pass with -Werror and all warnings turned

Re: RFR JDK-8010267 JDK-8010268 : Makefile maintenance for test targets

Both of these look good to me, but you still need a jdk8 reviewer. /Erik On 2013-03-27 17:27, Mike Duigou wrote: I still need a review for both of these changes. Mike On Mar 18 2013, at 22:48 , Mike Duigou wrote: A two small changes to review: If approved I will commit to TL (or someone

Re: RFR 8010280: jvm.cfg needs updating for non-server builds

Hello, It looks to me like you are covering the case of both server and client being true twice. How could line 319 ever evaluate to true? Otherwise it looks ok. /Erik On 2013-04-15 02:18, David Holmes wrote: Some background. The jvm.cfg file, for which there is a per-architecture

Re: RFR 8010280: jvm.cfg needs updating for non-server builds

This looks good to me. /Erik On 2013-04-16 00:42, David Holmes wrote: FYI updated webrev at same location, removing the dead code Erik spotted. http://cr.openjdk.java.net/~dholmes/8010280/webrev/ On 16/04/2013 2:25 AM, Mike Duigou wrote: Hi David; I remember reviewing the jvm.cfg config

Re: What is the Build Process for Codes inside jdk/src/macosx/native/jobjc

Hello Dan, These sources are indeed treated separately. I don't actually know why, but they were in the old build. (There the native was compiled as an XCode project and the java code with Ant). When converting to the new build, we strived to keep differences in build output to a minimum.

Re: 8014500: bootcycle-images fails after upgrade to JAXP 1.5

Looks good from the build side. /Erik On 2013-05-14 14:16, Alan Bateman wrote: The bootcycle-images target is currently broken in jdk8/tl. Jon has taken 8014461 to fix genstubs but once you get past that then the CLDRConverter fails parsing LDML due to DTD references that aren't allowed by

hg: jdk8/tl/langtools: 8014513: Sjavac doesn't detect 32-bit jvm properly

Changeset: dcc6a52bf363 Author:erikj Date: 2013-06-27 10:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dcc6a52bf363 8014513: Sjavac doesn't detect 32-bit jvm properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

Build changes are looking pretty good. Just one thing that I would like to add. Since the executable jspawnhelper is linking in an object file from libjava, it would be good to declare that dependency. See unpack200 for a similar situation. $(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)

Re: Build error with GCC4.8 on Fedora19

I would like to see a comment explaining why the option was needed. Is this a bug in gcc or has the checking just become better? /Erik On 2013-07-09 07:46, Dan Xu wrote: Adding build-dev mailing list. On 07/08/2013 09:54 PM, Yasu wrote: Sorry, I forgot to attach a patch: -- diff -r

hg: jdk8/tl/langtools: 8015145: Smartjavac needs more flexibility with linking to sources

Changeset: 71b0089b146f Author:erikj Date: 2013-08-15 17:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71b0089b146f 8015145: Smartjavac needs more flexibility with linking to sources Reviewed-by: jjg, ohrstrom !

hg: jdk8/tl/langtools: 8023146: Sjavac test failes in langtools nightly

Changeset: 4300c2f5fb1b Author:erikj Date: 2013-08-16 16:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4300c2f5fb1b 8023146: Sjavac test failes in langtools nightly Reviewed-by: mcimadamore, jfranck ! test/tools/sjavac/SJavac.java

Re: RFR(M): 8024265: Enable new build on AIX (jdk part)

Hello Volker, This looks good to me. I think the mapfile situation could be solved better, but your solution is probably the simplest, at least if you anticipate using them in the future. /Erik On 2013-09-16 17:20, Volker Simonis wrote: Hi, could you please review the following webrev

Re: RFR: 8009719: core reflection should get type annotation data from the VM lazily

Or wait, you added a c-file to libjava and want the old build to keep working, then you need to add that file to jdk/make/java/java/FILES_c.gmk. /Erik On 2013-09-23 09:59, Erik Joelsson wrote: Build part of the changes are fine. /Erik On 2013-09-21 16:26, Joel Borggren-Franck wrote: Hi

Re: RFR: 8009719: core reflection should get type annotation data from the VM lazily

I'm happy with the build part now. /Erik On 2013-09-23 16:00, Joel Borggren-Franck wrote: Hi all, Updated webrev: http://cr.openjdk.java.net/~jfranck/8009719/webrev.02/ Adds Field.c to make/java/java/FILES_c.gmk (old build) Renames parameter in Field.c from method to field Thanks for the

RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

Currently the RMI stubs in the jdk are built with the newly built rmic binary at the end of the build. This patch changes that and instead builds a bootstrap version of the rmic classes, much like bootstrap javac in langtools, which runs on the bootjdk, but generates classes for the new jdk.

Re: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

On 2013-10-15 16:40, Alan Bateman wrote: On 15/10/2013 15:30, Erik Joelsson wrote: Currently the RMI stubs in the jdk are built with the newly built rmic binary at the end of the build. This patch changes that and instead builds a bootstrap version of the rmic classes, much like bootstrap

Re: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

AM, David Holmes wrote: Hi Erik, Many thanks for jumping on this! On 16/10/2013 12:30 AM, Erik Joelsson wrote: Currently the RMI stubs in the jdk are built with the newly built rmic binary at the end of the build. This patch changes that and instead builds a bootstrap version of the rmic classes

Re: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

as we aren't running the rmic or idlj in the bootjdk at all now. /Erik Thank you and best regards, Volker On Tue, Oct 15, 2013 at 4:40 PM, Alan Bateman alan.bate...@oracle.com wrote: On 15/10/2013 15:30, Erik Joelsson wrote: Currently the RMI stubs in the jdk are built with the newly built rmic

hg: jdk8/tl: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

Changeset: af81988013b5 Author:erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk !

hg: jdk8/tl/corba: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

Changeset: 438c54c148a6 Author:erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/438c54c148a6 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/BuildCorba.gmk

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 76a7c0bc74fd Author:erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk !

Re: RFR(XS): 8026874 : During JAXWS build the newly built JAXP classes should be in the bootclasspath (not only in the classpath)

Hello Volker, Looks good to me. I can sponsor the change. /Erik On 2013-10-18 16:41, Volker Simonis wrote: Hi, could somebody please review and sponsor (i.e. push) the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/8026874/ https://bugs.openjdk.java.net/browse/JDK-8026874

Re: RFR: JDK-6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar

On Wed, Oct 16, 2013 at 2:51 PM, Volker Simonis volker.simo...@gmail.com wrote: On Wed, Oct 16, 2013 at 12:22 PM, Erik Joelsson erik.joels...@oracle.com wrote: On 2013-10-15 17:29, Volker Simonis wrote: Hi Erik, Alan, first of all I think this is a good change because it helps porters to build

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin/grep doesn't handle '\(3\.8[12]\)\|\(4\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

; then AC_MSG_NOTICE([Found GNU make at $MAKE_CANDIDATE, however this is not version 3.81 or later. (it is: $MAKE_VERSION_STRING). Ignoring.]) else /Erik On 2013-10-30 16:51, Erik Joelsson wrote: It seems the problem is with the grep tool used to parse the version string. /usr/xpg4/bin

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00, Erik Joelsson erik.joels...@oracle.com wrote: I found a solution that's also more readable. Posting inline since it's so small a change: diff -r

Re: RFR: ccache 3.1.9 not being recognized on Solaris

While the change is correct, ccache usage on Solaris is pointless in my experience. Are you actually seeing performance gains by using it? I investigated this quite thoroghly a while back and concluded that ccache and sun studio just didn't go together. I think I could make ccache work with

Re: [8u60] RFR: 8038189: Add cross-platform compact profiles support

Hello David, Most of it looks good, but profile-includes.txt could certainly benefit from some reduction in duplication. (Aside from the extension of the file itself, which I find a bit weird, but it's already there.) The two common structures that I can see are: 1. Expanding debuginfo files

Re: [8u60] RFR: 8038189: Add cross-platform compact profiles support

! I will incorporate, test and return with an updated webreb. David On 1/12/2014 7:19 PM, Erik Joelsson wrote: Hello David, Most of it looks good, but profile-includes.txt could certainly benefit from some reduction in duplication. (Aside from the extension of the file itself, which I find a bit

Re: Review request: JDK-8067360: verify-modules target was dropped in jdk9 b41

Looks good to me. I don't mind if you fix javadoc in the same change. It's such a small issue I rather not go through the hassle of creating a bug and a new review. Thanks! /Erik On 2014-12-12 19:25, Mandy Chung wrote: Webrev:

Re: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows

. In this change, I'm removing this special treatment of unpack200.exe so that it is linked just like all other executables. /Erik On 2015-01-22 15:40, Erik Joelsson wrote: Hello, Please review this patch, which makes it possible to take a compile command line from the make debug log on Windows, and rerun

Re: RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual Studio 2013 (VS2013)

Hello, New webrev for root repo: http://cr.openjdk.java.net/~erikj/8042707/webrev.root.02/ On 2015-01-09 15:45, Magnus Ihse Bursie wrote: It looks basically good to me. Some remarks on toolchain_windows.m4, though. In TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT: # TODO: improve detection

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

(adding build-dev) Hello Sherman, In Gensrc-jdk.charsets.gmk: * The variable CHARSET_EXTENDED is defined but never used. The value is used in several places however. I think you should either use the variable or not define it at all. * $(CHARSET_EXTENDED_DATA) is put on a prerequisite line,

RFR: JDK-8042707: Source changes needed to build JDK 9 with Visual Studio 2013 (VS2013)

Hello, Please review this patch, which adds support for building with different versions of Visual Studio and in particular adds support for VS2013. In order to control which version to use, I've introduced a new configure parameter --with-toolchain-version. On windows, this parameter will

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

Thanks, looks good! /Erik On 2015-03-06 17:14, Magnus Ihse Bursie wrote: On 2015-03-04 14:31, Erik Joelsson wrote: Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line

Re: RFR 9: 8076184 Cleanup compile/link warnings on Solaris

Looks good to me. /Erik On 2015-03-27 18:27, Roger Riggs wrote: Please review minor cleanups to compile and builds on Solaris. Some entry points had been renamed but not updated in the make/mapfiles/reorder-xxx files and a compilation warning remedied by putting declarations at the top of

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

Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for debugging in the future? Also, how hard

Re: RFR: JDK-8072842 Add support for building native JTReg tests

Hello Magnus, Overall looks good. I would prefer if some of the longer lines in Main.gmk were split as it's a file I often need to read. In MakeBase, the definition of dups, I thought we (informally) agreed to start such macro definitions with a newline to make them stand out more from normal

RFR: JDK-8055190: Cleanup include and exclude of core-libs native libraries after source code restructure

Hello, Please review this build patch, cleaning up some in the native compilation of some core libraries. After the source code restructure into modules, the need for explicit exclude and include of source files was reduced. This patch moves some OS specific files to OS specific source dirs

Re: RFR: JDK-8055190: Cleanup include and exclude of core-libs native libraries after source code restructure

On 2015-01-23 15:41, Alan Bateman wrote: On 23/01/2015 14:35, Erik Joelsson wrote: Hello, Please review this build patch, cleaning up some in the native compilation of some core libraries. After the source code restructure into modules, the need for explicit exclude and include of source

Re: RFR: JDK-8074859 Turn on warnings as error

Looks good to me. /Erik On 2015-04-17 14:52, Magnus Ihse Bursie wrote: With JDK-8074096, the number of warnings in the product was reduced to a minimum. This enables the next step, which is turning on the respective compiler flags that turns warnings into errors. In the long run, this is the

Re: Review Request for 8074431: Remove native2ascii tool

Looks good to me. /Erik On 2015-05-19 00:45, Mandy Chung wrote: This patch removes native2ascii command-line tool from JDK 9 as proposed in March [1]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074431/webrev.00/ Jon - A langtools test is updated to use a new

Re: native2ascii be removed from JDK?

Note that the JDK build itself uses native2ascii for the man pages. I have no idea why or if this is actually necessary. Here is the code: define install-ja-manpage $(MKDIR) -p $(@D) $(CAT) $ \ | $(NATIVE2ASCII) -encoding eucJP \ | $(SED)

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

Hello, Looks pretty good. Found some typos: jdk_util.c: 99: specia_update_version jdk-version.m4: 31: assing 124, 132: --with--version-pre-base has a dash too many? I see this pattern consistently used though, am I missing something? /Erik On 2015-06-05 16:07, Magnus Ihse Bursie wrote:

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

Looks good. /Erik On 2015-06-09 15:52, Magnus Ihse Bursie wrote: Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ And here's a (much simpler) delta webrev which shows just these

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

Hello Jan, Build changes look mostly ok. Some notes: * $(CFLAGS_WARNINGS_ARE_ERRORS), which should not be used anymore. Warnings are already treated as errors globally. * There should not be a need to add -I$(INCLUDEDIR) -I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS) to cflags. INCLUDEDIR

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

Hello Jan, Build changes look good. /Erik On 2015-06-25 18: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

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

Hello Roger, Build change looks fine to me. /Erik On 2015-06-15 23: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

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

Looks good. /Erik On 2015-06-10 15:44, Magnus Ihse Bursie wrote: On 2015-06-09 01:31, Daniel D. Daugherty wrote: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. I realize I missed that part of the

Re: Review Request 8074432: Move jdeps to jdk.compiler module

, \ +-DEXPAND_CLASSPATH_WILDCARDS \ +-DNEVER_ACT_AS_SERVER_CLASS_MACHINE \ +-DJAVA_ARGS='{ -J-ms8m$(COMMA) com.sun.tools.jdeps.Main$(COMMA) }')) On May 27, 2015, at 12:48 AM, Erik Joelsson erik.joels...@oracle.com wrote: Hello Mandy, I don't see a Launcher-jdk.jdeps.gmk. Should there be one? /Erik On 2015-05-27 08:00

Re: Review Request 8074432: Move jdeps to jdk.compiler module

Hello Mandy, I don't see a Launcher-jdk.jdeps.gmk. Should there be one? /Erik On 2015-05-27 08:00, Mandy Chung wrote: We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The

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

The build change looks fine, thanks for fixing this! /Erik On 2015-05-22 02: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

Re: RFR - 8027634: Support @argfiles for java command-line tool

Hello Henry, Build changes look good to me. /Erik On 2015-07-10 05:48, Henry Jen wrote: Hi, Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in

Re: RFR v4 - 8027634: Support @argfiles for java command-line tool

New build changes look fine to me. /Erik On 2015-08-08 09:03, Henry Jen wrote: Hi, Another update for argument file support, this version we added a couple measures to ensure compatibility, 1) Compile time directive ENABLE_ARG_FILES is needed to enable the feature, only java is enabled

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

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 support for the IIOP transport (JDK-8043937).

Re: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

On 2015-12-04 22:00, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ Tested with JPRT with: • "-testset hotspot" • "-testset svc" • "-testset chris" from the

Re: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

On 2015-12-07 12:18, David Holmes wrote: On 7/12/2015 6:33 PM, Erik Joelsson wrote: On 2015-12-04 22:00, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ Tested

Re: RFR: JDK-8145596 Enable debug symbols for all libraries

Looks good to me. Note that this patch will conflict with the quick fix I did in jdk9/hs, so you will need to either wait for my patch, push in a forest that has my patch, or make sure the integrator can handle it correctly. /Erik On 2015-12-17 14:43, Magnus Ihse Bursie wrote: For

Re: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition

The configure change looks good. Can't comment on the code changes. /Erik On 2015-12-16 14:50, Magnus Ihse Bursie wrote: There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I

Re: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile JRE

Looks good to me. /Erik On 2015-12-21 21:18, Bob Vandette wrote: http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ Please review the following fixes that were required to complete the initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest. 1. Change the

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

On 2016-01-27 14:55, Aleksey Shipilev wrote: c) (XS) Build changes that force emitting the "legacy" inline StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is expected): http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ In what context do we need pre-JDK 9

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

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. This makes the build process very noisy in

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

On 2016-03-24 12:15, Alan Bateman wrote: 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

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

New webrev with shorter lines in SocketOptionRegistry.java.template. http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ /Erik On 2016-03-24 12:57, Erik Joelsson wrote: On 2016-03-24 12:15, Alan Bateman wrote: On 23/03/2016 16:14, Erik Joelsson wrote: : On 2016-03-23 12:13, Erik

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

ups"), - configure_args: common.configure_args, +configure_args: concat(common.configure_args, "--with-zlib=system"), make_args: common.make_args }, On 2016-03-24 09:05, Erik Joelsson wrote: Hello, As I wrote in the bug, jdk9/dev cu

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

(adding core-libs) On 2016-03-23 12:13, Erik Joelsson wrote: In the gensrc step for java.base, we generate a couple of java classes with the purpose of extracting native constants from the system. We currently do this by compiling a C program that when run, generates the java source file

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

zlib for a while. Thanks, Sherman On 03/24/2016 06:22 AM, Erik Joelsson wrote: Hello again. Here is my suggested patch for the jib-profiles.js file. This will enforce system zlib for Oracle builds on Linux, Solaris and Macosx. /Erik diff -r 6da9e0c79eac common/conf/jib-profiles.js

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

Hello, As I wrote in the bug, jdk9/dev currently fails when using --with-zlib=system with the new devkit on Linux. That will need to be fixed first. If the intention of this change is to enforce --with-zlib=system on OracleJDK builds, we should also update the Jib profile definitions for

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

Looks good to me. /Erik On 2016-03-24 23:31, Xueming Shen wrote: Thanks Erik! Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8031767/webrev/ -Sherman On 03/24/2016 01:57 PM, Erik Joelsson wrote: Hello, Yes, I believe we still need to, the reason being

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

Hello Brent, The build changes look pretty good. Just one nit, in the new LibosxLibraries.gmk, please remove the "include LibCommon.gmk" as that is now handled by Lib-java.desktop.gmk. /Erik On 2016-03-01 22:16, Brent Christian wrote: Hi, A number of internal APIs were carried over into

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

  1   2   3   4   >