Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main

Re: RFR: JDK-8266254: Update to use jtreg 6

On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the > version of jtreg to use, for those systems that rely on this file. In > addition, the `requiredVersion`

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Re: RFR: 8267043: IntelliJ project doesn't handle generated sources correctly [v2]

On Wed, 12 May 2021 17:51:11 GMT, Maurizio Cimadamore wrote: >> Since generated sources are placed in the build folder, and since the build >> folder is indicated by the IntelliJ project settings as "project output", >> IntelliJ indexing blissfully ignores all the classes which are generated

Re: RFR: 8264779: Fix doclint warnings in java/nio

On Wed, 7 Apr 2021 13:22:44 GMT, Conor Cleary wrote: > This fix addresses the following warnings which were generated by building > JDK API documentation with the `-Xdoclint:all` option enabled: > >

Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols [v4]

On Tue, 1 Dec 2020 11:18:11 GMT, Jan Lahoda wrote: >> Adding support for record classes in the historical data for ct.sym. This >> includes a few changes not strictly needed for the change: >> -updating and moving tests into test/langtools, so that it is easier to run >> them. >> -fixing

Re: RFR: JDK-8256950: Add record attribute support to symbol generator CreateSymbols

On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda wrote: > Adding support for record classes in the historical data for ct.sym. This > includes a few changes not strictly needed for the change: > -updating and moving tests into test/langtools, so that it is easier to run > them. > -fixing Record

Integrated: 8256755: Update build.tools.depend.Depend to handle record components in API signatures

On Tue, 24 Nov 2020 09:59:44 GMT, Chris Hegarty wrote: > The `Depend` build tool creates a hash of a module's API elements, so that it > can determine if downstream modules require recompilation. The build tool > fails (throws an exception) when it encounters an "unknown"

Re: RFR: 8256755: Update build.tools.depend.Depend to handle record components in API signatures [v2]

> This issue is a blocker to adding any public record types to the JDK - since > the build will fail. Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The p

RFR: 8256755: Update build.tools.depend.Depend to handle record components in API signatures

The `Depend` build tool creates a hash of a module's API elements, so that it can determine if downstream modules require recompilation. The build tool fails (throws an exception) when it encounters an "unknown" record attribute/component - the build tool predates records. The components of a

Re: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v6]

> On 5 Nov 2020, at 18:11, Alex Buckley wrote: > > On 11/5/2020 4:45 AM, Jan Lahoda wrote: >> FWIW, a javadoc generated with the current version of the patch: >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html > > Allow me to draw people's attention to the PREVIEW

Re: RFR: 8223347: Integration of Vector API (Incubator)

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote: > This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in

Re: Change for 8248135: Build microbenchmarks with --enable-preview makes other non-preview JMH benchmarks to fail

Peter, 8248429 [1] tracks this issue, right? There was a recent thread on build-dev relating to this, in the form of an RFR from Jorn : https://mail.openjdk.java.net/pipermail/build-dev/2020-June/thread.html#27804 Some great discussion was had, but I’m not sure that a conclusion was reached

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 23 Jun 2020, at 10:46, Chris Hegarty wrote: > > > >> On 23 Jun 2020, at 10:17, Peter Levart wrote: >> >> ... >> http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ > > Good stuff. Reviewed. > > I am going t

Re: RFR: 8247532, 8248135: Records deserialization is slow + Build microbenchmarks with --enable-preview

> On 23 Jun 2020, at 10:17, Peter Levart wrote: > > ... > http://cr.openjdk.java.net/~plevart/jdk-dev/RecordsDeserialization/webrev.08/ Good stuff. Reviewed. I am going to take this latest change and run it through our internal build and test system. Will post the results here soon.

Re: RFR: JDK-8244093 Move all IDE support into coherent structure in make directory

> On 29 Apr 2020, at 11:36, Magnus Ihse Bursie > wrote: > > ... > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244093 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8244093-move-ide-support/webrev.01 The make/idea changes look ok to me. -Chris.

Re: RFR [14] 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries

Adding build-dev; minor change to remove a linker dependency. -Chris. > On 16 Aug 2019, at 18:22, Daniel Fuchs wrote: > > Hi chris, > > That looks good to me - although don't count me as reviewer > for the makefile changes. > > best regards, > > -- daniel &

Re: bin/idea.sh and Cygwin

Matthias, On 08/11/18 11:45, Baesken, Matthias wrote: Hello, I tried to use bin/idea.sh with Cygwin to generate project files for IDEA IntelliJ Community . The project file generation seems to work and outputs the .idea - folder with lots of xml files in it . However , when

Re: RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef

On 26/09/18 10:24, Baesken, Matthias wrote: ...wse/JDK-8211146 http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ Looks good Matthias. -Chris.

Re: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass

On 14/03/18 13:08, Alan Bateman wrote: On 14/03/2018 12:56, Chris Hegarty wrote: This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int

RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass

This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these references are to the no-args getCallerClass that was removed a long time ago. These

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

> On 15 Jun 2017, at 14:29, Claes Redestad wrote: > ... > http://cr.openjdk.java.net/~redestad/8181147/jdk.06/ 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

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

should pick the first found > source file of the same name (or rather, that would end up as the same > object) and the macro FindSrcDirsForLib should guarantee that the most > specific file is found first. I can confirm that this works fine. Thanks Erik. -Chis. > /Erik > >

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

her > webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ > > I have seen the multiple DIRECTs myself during testing and I think filtering > on the java side is a very elegant solution. > Thanks for this! > > Best regards, > Arno > >> -Origin

Re: RFR [9] Warning notice for types in Incubator Modules

: $(COPY_TARGETS) -Chris. On 30/01/17 11:29, Erik Joelsson wrote: Hello, On 2017-01-30 11:58, Chris Hegarty wrote: Magnus, On 26/01/17 11:45, Magnus Ihse Bursie wrote: On 2017-01-25 13:51, Chris Hegarty wrote: On 24 Jan 2017, at 16:44, Erik Joelsson <erik.joels...@oracle.com> wrote:

Re: RFR [9] Warning notice for types in Incubator Modules

Magnus, On 26/01/17 11:45, Magnus Ihse Bursie wrote: On 2017-01-25 13:51, Chris Hegarty wrote: On 24 Jan 2017, at 16:44, Erik Joelsson <erik.joels...@oracle.com> wrote: Hello, Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to

Re: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp

On 30/01/17 08:08, Magnus Ihse Bursie wrote: On 2017-01-26 15:28, Chris Hegarty wrote: I’m not sure of the latest status of warnings in the build, but just to say, libstcp was always built with 0 warnings being emitted ( the JNI code has unused this/class parameters that cannot be removed

Re: RFR: JDK-8081694 Remove DISABLED_WARNINGS_gcc for libsctp

I’m not sure of the latest status of warnings in the build, but just to say, libstcp was always built with 0 warnings being emitted ( the JNI code has unused this/class parameters that cannot be removed ). If you remove this suppression won’t the compilation of code from libsctp now produce a

Re: RFR [9] Warning notice for types in Incubator Modules

ecipes are created. Setting it on the phony docs-javadoc > target will not help incremental builds. Updated in place http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. > /Erik > > > On 2017-01-24 15:08, Chris Hegarty wrote: >> As per the guidance in JEP 11 [1

RFR [9] Warning notice for types in Incubator Modules

As per the guidance in JEP 11 [1], the javadoc for types in incubator modules should have a clear and explicit warning notice. To that end, I’ve added a simple inline taglet that can be used to effectively inject a standard notice, and applied it to all public types in the HTTP module ( I’ll

Re: Review request: JDK-8173085 Warning module name in --add-exports not found: jdk.jdeps when compiling for BUILD_JIGSAW_TOOLS

On 19/01/17 23:37, Mandy Chung wrote: JDK-8172973 removes the warning emitted at run-time but --add-exports specified at compile-time is not removed. Hence a javac warning is emitted. diff --git a/make/CompileModuleTools.gmk b/make/CompileModuleTools.gmk --- a/make/CompileModuleTools.gmk +++

RFR [9] Remove add exports from ModuleSummary build

After a recent change [1], I noticed a warning during compilation of the ModuleSummary build tool: warning: [options] module name in --add-exports option not found: jdk.jdeps It can be seen from the history of ModuleSummary.java in jake that at one point this class used types from

Re: RFR: 8172709 Upgrade to jtreg 4.2 b05

> On 12 Jan 2017, at 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

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

Looks good to me Erik. -Chris. On 30/11/16 14:18, Erik Joelsson wrote: This patch adds the jdk.unsupported module to the compact profile images. Bug: https://bugs.openjdk.java.net/browse/JDK-8168924 Patch: diff -r 2ba99326da3d make/Images.gmk --- a/make/Images.gmk +++ b/make/Images.gmk @@

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

On 30/09/16 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-8156036: Enable building of arm targets in default JPRT testset

On 4 May 2016, at 16:47, Erik Joelsson wrote: > This is the open part of an Oracle internal change to JPRT. It requires > adding of a hook in the open configuration file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156036 > Webrev:

Re: RFR: JDK-8155641: Correct merge typo in compare script

On 28 Apr 2016, at 15:00, Erik Joelsson wrote: > An apparent typo has appeared in common/autoconf/compare.sh.in which I think > originates from a merge changeset. It prevents clean comparisons from being > done so I would like to have it fixed asap. > > Bug:

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

On 27 Apr 2016, at 17:27, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> On Apr 27, 2016, at 2:04 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> This works out quite nice. Webrev updated in-place: >> http://cr.openjdk.java.ne

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

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) with 3 instance

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

On 26 Apr 2016, at 10:57, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > On 2016-04-26 11:51, Chris Hegarty wrote: >> On 26 Apr 2016, at 10:35, Erik Joelsson <erik.joels...@oracle.com> wrote: >> >>> Hello Chris, >>> >>

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

enjdk.java.net/groups/build/doc/code-conventions.html > > On 2016-04-25 23: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 a

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

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 Principle 4 of JEP 200: >

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

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/~chegar/8044773/

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

On 04/04/16 12:34, Alan Bateman wrote: > On 04/04/2016 12:04, Erik Joelsson wrote: >> Makefile looks good. >> >> If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of >> libjava, should you also remove it from the mapfile for libjava? >> > Yes, libjava/mapfile-vers will need to be

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

[ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native

Fwd: RFR[9] 8068686: Remove meta-index support

Forwarding, there are some small build changes. Begin forwarded message: > From: Chris Hegarty <chris.hega...@oracle.com> > Date: 16 February 2016 at 19:19:35 GMT > To: core-libs-dev <core-libs-...@openjdk.java.net> > Subject: RFR[9] 8068686: Remove meta-index support &

Re: question on jigsaw build

Magnus, Thank you for your reply. On 09/02/16 09:57, Magnus Ihse Bursie wrote: On 2016-01-25 13:43, Maurizio Cimadamore wrote: Hi, the current build system in JDK 9 has a way to recover all the source dirs for a given module, by doing something like this: $(call ALL_SRC_DIRS,$(mod)) That

Re: jdk 9 build broken?

Hi Lance, I pushed a change a few days ago that updated libraries to use the internal Unsafe class. The jdk9/dev forest builds fine for me on all platforms, and in several internal automated build systems. -Chris > On 14 Nov 2015, at 18:17, Lance Andersen wrote: >

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

On 25/09/15 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 support

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

On 25/05/15 09:42, Erik Joelsson wrote: On 2015-05-22 18:53, Mandy Chung wrote: On 05/22/2015 08:09 AM, Alan Bateman wrote: 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

Re: Status of ccache

On 25/05/15 09:38, Erik Joelsson wrote: On 2015-05-22 17:47, Dan Smith wrote: JDK-8027584 disabled ccache by default, I gather because it doesn't work in Cygwin, and secondarily because of vague general problems with it. The documentation (README-builds.html) still unambiguously endorses it,

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

On 22/05/15 07:58, Erik Joelsson wrote: On 2015-05-22 02:46, Mandy Chung wrote: I’m including build-dev and we need to ask for Erik and Magnus advice what’s the best way to work around this. Erik, Magnus, Security providers now become service providers. They are provided from 11

Re: clang 6.1 inteference

Is this another sighting of https://bugs.openjdk.java.net/browse/JDK-8077364 ? -Chris. On 13/04/15 15:22, Jim Laskey (Oracle) wrote: Run into an issue after upgrade to clang 6.1 /Volumes/Elephant/Projects/sandbox/hotspot/src/share/vm/opto/chaitin.cpp:2098:8: error: 'this' pointer cannot be

Re: RFR: 8074910 hgforest.sh needs an option to bring over a smaller set of extra repos

Thank you Phil, doing something along the lines of this has been on my list for a while now. On 11/03/15 08:55, Erik Joelsson wrote: Hello, Line 187 looks like debug output left about. Perhaps also 219 but I think that echo makes sense to keep. Otherwise looks good to me. +1. -Chris.

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

On 5 Mar 2015, at 08:31, Alan Bateman alan.bate...@oracle.com wrote: 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

Re: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only

Thanks Volker, I agree with your change, or you can take the code from ImageBuilder. Either is fine with me. private void setExecutable(Path file) { try { SetPosixFilePermission perms = Files.getPosixFilePermissions(file);

Re: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only

that on Solaris 'jspawnhelper' still has the right execution bits set after the change. Regards, Volker On Fri, Dec 5, 2014 at 3:18 PM, Chris Hegarty chris.hega...@oracle.com wrote: Thanks Volker, I agree with your change, or you can take the code from ImageBuilder. Either is fine with me

Re: RFR(XXS): 8066766: The commands in the modular images are executable by the owner only

On 5 Dec 2014, at 18:14, Volker Simonis volker.simo...@gmail.com wrote: On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty chris.hega...@oracle.com wrote: Volker, Personally I would use the more verbose version, Files.setPosixFilePermissions, so we can see any failures. But as Alan pointed

Re: RFR [JEP 220] Modular Run-Time Images

I’ve taken a pass over the non-build changes and don’t see anything of concern. I put them though our internal build and test system, and the results look positive. -Chris. On 20 Nov 2014, at 21:39, Chris Hegarty chris.hega...@oracle.com wrote: This is a review request for the changes

Re: RFR [JEP 220] Modular Run-Time Images

On 23/11/14 23:15, Magnus Ihse Bursie wrote: On 2014-11-20 22:39, Chris Hegarty wrote: This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed

Re: RFR [JEP 220] Modular Run-Time Images

it in other FactoryFinders. found in $java.home/jaxp.properties, found in $java.home/conf/jaxp.properties, This has been fixed in jigsaw/m2. -Chris Thanks, Joe On 11/20/2014 1:41 PM, Chris Hegarty wrote: From: Chris Hegarty chris.hega...@oracle.com Subject: RFR [JEP 220] Modular Run

Re: RFR [JEP 220] Modular Run-Time Images

, -Chris. [1] http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/3032b0232660 --Sean On 11/20/2014 04:41 PM, Chris Hegarty wrote: From: Chris Hegarty chris.hega...@oracle.com Subject: RFR [JEP 220] Modular Run-Time Images Date: 20 November 2014 21:39:14 GMT To: jigsaw-dev jigsaw

RFR [JEP 220] Modular Run-Time Images

From: Chris Hegarty chris.hega...@oracle.com Subject: RFR [JEP 220] Modular Run-Time Images Date: 20 November 2014 21:39:14 GMT To: jigsaw-dev jigsaw-...@openjdk.java.net, jdk9-dev jdk9-...@openjdk.java.net, build-dev build-dev@openjdk.java.net, Alan Bateman alan.bate...@oracle.com, Alex

Re: Build support for JDK-8044627

Erik, Pavel has already pushed the JNDI changes, and will follow up with the service configuration files later, so this issue is less pressing. If you like lets defer addressing the general problem of concatenating service configuration files until jigsaw/m2 is in the JDK 9 mainline. There is

Re: Build support for JDK-8044627

:49, Chris Hegarty wrote: Erik, Pavel has already pushed the JNDI changes, and will follow up with the service configuration files later, so this issue is less pressing. If you like lets defer addressing the general problem of concatenating service configuration files until jigsaw/m2

Re: RFR JDK-8044627: Update JNDI to work with modules

On 14 Oct 2014, at 15:03, Pavel Rappo pavel.ra...@oracle.com wrote: OK, so what I will do for now is I exclude these 4 files and push without them. I'll create a new issue to add them later. That sounds like a fine plan. This issue has already gone on for long enough, and I don’t think that

Re: RFR JDK-8044627: Update JNDI to work with modules

On 14 Oct 2014, at 15:15, Daniel Fuchs daniel.fu...@oracle.com wrote: On 14/10/14 16:09, Chris Hegarty wrote: On 14 Oct 2014, at 15:03, Pavel Rappo pavel.ra...@oracle.com wrote: OK, so what I will do for now is I exclude these 4 files and push without them. I'll create a new issue to add

Re: RFR: JDK-8058118: Generate modules.list during the build

On 12 Sep 2014, at 20:04, Mandy Chung mandy.ch...@oracle.com wrote: On 9/12/14 7:03 AM, Erik Joelsson wrote: Hello, The checked in modules.list file defines the dependencies between modules for the build. The dependency information in this file is already captured in the modules.xml.

Re: RFR(S): 8056246 : Fix AIX build after the Modular Source Code change 8054834

On 28 Aug 2014, at 16:22, Volker Simonis volker.simo...@gmail.com wrote: PS: I would also like to do some further cleanup in NetworkingLibraries.gmk in a follow-up change. I think now that we have all the corresponding directories in place we could rename {solaris,linux,bsd}_close.c to

Re: Review request: 8055230: Rename attach provider implementation class

On 26 Aug 2014, at 08:26, Alan Bateman alan.bate...@oracle.com wrote: On 26/08/2014 05:29, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/ This patch renames the class name of attach provider implementation class to be the same for all platforms.

Re: RFR [9] Modular Source Code

output is still in large parts repository oriented. This is something we hope to improve later. /Erik On 2014-08-12 16:10, Chris Hegarty wrote: This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. There are a number of individuals responsible for these changes

RFR [9] Modular Source Code

This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review

Re: RFR : 8042932: Bump up the -source version for JDK 9 builds

Looks good to me Sean. -Chris. P.S. don’t forget to push the closed version of gen-conf too. On 12 May 2014, at 23:22, Seán Coffey sean.cof...@oracle.com wrote: While adding some lambda code to a CORBA class, I got a build time error indicating that the build was running with -source 7.

Re: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo

Looks fine to me Mike. Trivially while you are there (not related to your changes), or i can do it separately, --sequentially now runs with up to two parallel commands. -Chris On 9 May 2014, at 03:19, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This issue is a follow-on bug

Re: RFR: JDK-8042417 : (s) hgforest: allow local clone of extra repos

This looks like a nice addition Mike. -Chris. On 5 May 2014, at 18:54, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a small enhancement to hgforest.sh cloning which will include cloning the extra repos if they exist. https://bugs.openjdk.java.net/browse/JDK-8042417

Re: RFR [9] : get_source.sh should be more friendly to MQ

...@oracle.com wrote: Chris Hegarty (chris.hega...@oracle.com) wrote: On 11/04/14 15:59, Jonathan Gibbons wrote: Popping all patches beforehand is reasonable, but afterwards, it would be better to reset to the patches that were previously applied than to try and push all of them. Michael

Re: RFR: 8041151: More concurrent hgforest.

On 22 Apr 2014, at 09:10, Erik Joelsson erik.joels...@oracle.com wrote: Seems to work for me too. Nice speedup! Looks good to me. +1. Thanks for doing these improvements Mike. -Chris. /Erik On 2014-04-19 01:21, Mike Duigou wrote: Hello all; This is an improvement to hgforest to

Re: RFR: JDK-8030794: Update configure to require jdk8 as boot

Looks good to me. -Chris. On 16/04/14 11:01, Erik Joelsson wrote: There are now changes in jdk9 which prohibit the use of jdk7 as boot jdk (unless the update version is high enough). It's time we formally change the requirement from jdk7 to jdk8 by making configure require it. Bug:

Re: Java compilation and -g

On 11/04/14 15:40, Erik Joelsson wrote: Hello, While converting the build to the new build-infra makefiles, one thing that annoyed me was the fact that we aren't consistently compiling with or without -g for java code. In the new makefiles we just emulate the same behavior, but I would like to

RFR [9] : get_source.sh should be more friendly to MQ

Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically. If you do not have patch repos, then there is no change. diff --git a/get_source.sh

Re: RFR [9] : get_source.sh should be more friendly to MQ

code and you can take action. -Chris. -- Jon On 04/11/2014 07:58 AM, Chris Hegarty wrote: Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ

Re: RFR [9] : get_source.sh should be more friendly to MQ

a much more involved set of changes in hgforest, but could be doable. All you need to know is queue tip, 'hg qtop', of each repo, qpush back to it. -Chris. Michael On 11/04/14 15:58, Chris Hegarty wrote: Anyone using MQ for their daily development will know about this, forgetting to qpop

Re: RFR [9] : get_source.sh should be more friendly to MQ

. Mike On Apr 11 2014, at 07:58 , Chris Hegarty chris.hega...@oracle.com wrote: Anyone using MQ for their daily development will know about this, forgetting to qpop before sync'ing up. It would be nice it get_source would pop and push patches ( only if you are using MQ ) automatically

RFR [9] sequential operation option for hgforest

Sometimes I get a little confused/nervous when trying to push/status/in using the hgforest.sh script. The output can be a little confusing as it runs several jobs in parallel. I would like to add an option to support sequential operation of commands. It is off by default. The more nervous of

Re: RFR [9] sequential operation option for hgforest

with something else, “—np|—non-parallel” ?? Or anything, I’m happy once I can operate in non parallel mode. -Chris. Mike On Apr 10 2014, at 08:54 , Chris Hegarty chris.hega...@oracle.com wrote: Sometimes I get a little confused/nervous when trying to push/status/in using the hgforest.sh script

Fwd: RFR [9] 8039362: Read content-types.properties as a resource

Adding build-dev ( for the makefile changes ). -Chris. Original Message Subject: RFR [9] 8039362: Read content-types.properties as a resource Date: Mon, 07 Apr 2014 15:27:43 +0100 From: Chris Hegarty chris.hega...@oracle.com To: OpenJDK Network Dev list net

Re: RFR [9] 8039362: Read content-types.properties as a resource

,.html;\ [3] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a /Erik On 2014-04-07 16:33, Chris Hegarty wrote: Adding build-dev ( for the makefile changes ). -Chris. Original Message Subject: RFR [9] 8039362: Read content-types.properties as a resource Date

Re: get_source.sh from ssh://host//path

On 03/04/14 17:15, Mike Duigou wrote: On Apr 3 2014, at 08:23 , Wang Weijun weijun.w...@oracle.com wrote: It looks like the problem is at common/bin/hgforest.sh: 222pull_newrepo=`echo ${pull_base}/${i} | sed -e 's@\([^:]/\)//*@\1@g'` It tries to substitute all repeated

Re: When will JDK 9 builds move to requiring the boot JDK be JDK 8?

FYI. This is already reviewed ;-) http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html -Chris. On 3 Apr 2014, at 11:04, Alan Bateman alan.bate...@oracle.com wrote: On 03/04/2014 09:53, Erik Joelsson wrote: I don't see any reason not to make the switch. I filed this

Re: When will JDK 9 builds move to requiring the boot JDK be JDK 8?

On 3 Apr 2014, at 11:16, Alan Bateman alan.bate...@oracle.com wrote: On 03/04/2014 11:12, Chris Hegarty wrote: FYI. This is already reviewed ;-) http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011406.html -Chris. I know but I also replied suggesting that he hold off

Re: build warnings

On 08/02/14 00:41, Mike Duigou wrote: Part of the issue seems to be that the meaning of -Wno-unused seems to have changed and/or become ineffective. It's reported that it previously hid all unused parameter warnings though it doesn't seem to on any compiler I'm currently using. I've

Re: build warnings

On 07/02/14 10:43, Michael McMahon wrote: It seems, the warning is emitted by the combination of: -W -Wall and could be disabled by adding -Wno-unused-parameter Given the definition of JNI method signatures, then I agree with this. It would be really helpful to be able to see real warnings.

Re: JDK 9 RFR of JDK-8031747: Add overloads lint warning to build of jdk repository

The changes look good to me Joe. This is forward progress. -Chris. On 15/01/14 02:07, Joe Darcy wrote: Hello, With the lint warnings cleanup continuing, we are close to ridding the jdk repository of the overloads warning; remaining work there is out for review (JDK-8031550: Fix overloads lint

Re: JDK 9 RFR of JDK-8031081 Use separate doclint flags for different doc bundles

if it is possible with the javadoc tool, is how to make the warnings fatal. -Chris. -- Jon On 01/06/2014 12:55 PM, Chris Hegarty wrote: Sounds good to me ( I must remember to do doc builds before pushing;-) ). In which case I’d like to go ahead and enable -Xdoclint:all/protected” for the SCTP API

Re: JDK 9 RFR of JDK-8031081 Use separate doclint flags for different doc bundles

On 5 Jan 2014, at 23:30, Joe Darcy joe.da...@oracle.com wrote: On 01/05/2014 02:36 AM, Alan Bateman wrote: On 31/12/2013 02:07, Joe Darcy wrote: : To be clear, the goal would be for -Xdoclint:all/protected to be used on all bundles. Is the goal also for these warnings to be fatal? If so

Re: JDK 9 RFR of JDK-8031081 Use separate doclint flags for different doc bundles

Makes sense to me. The changes look fine. -Chris On 31 Dec 2013, at 02:07, Joe Darcy joe.da...@oracle.com wrote: Hello, Starting in JDK 8, there have been efforts to clean up the doclint warnings and errors, especially for types going into the coredocs bundle. The core libraries are

Re: RFR: JDK-8030793: Update jprt.properties to release jdk9

Looks good to me. Thanks Eric. -Chris. On 19 Dec 2013, at 12:30, Erik Joelsson erik.joels...@oracle.com wrote: Please review these changes to make/jprt.poperties and hotspot/make/jprt.properties. I've just added a jdk9 configuration to JPRT and this change is needed for JDK 9 to start

Re: RFR: JDK-8030793: Update jprt.properties to release jdk9

s/Eric/Erik -Chris. On 19 Dec 2013, at 12:51, Chris Hegarty chris.hega...@oracle.com wrote: Looks good to me. Thanks Eric. -Chris. On 19 Dec 2013, at 12:30, Erik Joelsson erik.joels...@oracle.com wrote: Please review these changes to make/jprt.poperties and hotspot/make

Re: RFR: JDK-8030794: Update configure to require jdk8 as boot

Thanks Erik, looks good to me. -Chris. On 19 Dec 2013, at 13:32, Erik Joelsson erik.joels...@oracle.com wrote: Since we now have dependencies in the langtools source on jdk8 features, we can no longer build jdk9 with jdk7 as boot. This change updates configure to allow jdk8 and jdk9 as

RFR: ccache 3.1.9 not being recognized on Solaris

Erik, I have a build of ccache 3.1.9 on my Solaris box, but it is not being used by the build as it thinks it is not greater than 3.1.4. The suggested changes (below) are in line with the grep/regular expression used in the GNU make version check you and Vinnie were discussing yesterday.

  1   2   >