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 meth
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`
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.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28
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
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:
>
> ./build/linux-x64/support/gensrc/java.base/java/nio/charset/IllegalCharsetNameException.java:47:
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 Record
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 att
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&q
ics.
>
> 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/reb
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 p
> 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 lin
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 th
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
> 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
> 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.
-Chris
> 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.
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,
>
> -- dan
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 openin
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.
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), these
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
> 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 does ), and pointed to when
> 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
>
>
> On 2017-02-01 13:0
jdk.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
>
>> -Original Message-
>> From: Chris He
: $(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
wrote:
Hello,
Build changes look good
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 wrote:
Hello,
Build changes look good except for one thing. In Javadoc.gmk, the dependency on
$(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on
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 ). If
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
warn
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], the javadoc for types in
&g
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 cleanu
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
+++ b
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 com.sun.tool
> 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 change and did
> not see an
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
@@ -4
On 30/09/16 10:47, Alan Bateman wrote:
On 30/09/2016 10:43, Chris Hegarty wrote:
...
Additionally, do you want to run with --add-modules java.se.ee to
include the 6 "EE" modules?
Not needed as the tool adds the class file attribute to every
module-info.class in jdk/modules/*.
Ah
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 build-
On 10 May 2016, at 12:42, Claes Redestad wrote:
> Hi,
>
> the tool makeClasslist.js lost it's purpose after JDK-8150044, so should be
> removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156561
>
> jdk repo$ hg rm make/non-build-utils/src/build/tools/makeclasslist
Looks good Claes.
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: http://cr.openjdk.java.net/~erikj/8156036/webrev.top.01
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: https://bugs.openjdk.java.net/brow
On 27 Apr 2016, at 20:13, Alan Bateman wrote:
> 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
On 27 Apr 2016, at 17:27, Mandy Chung wrote:
>
>> On Apr 27, 2016, at 2:04 AM, Chris Hegarty wrote:
>>
>> This works out quite nice. Webrev updated in-place:
>> http://cr.openjdk.java.net/~chegar/8044773/jdk/
>
> One comment on the qualified exports of sun.
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 methods and 2
> static methods
On 26 Apr 2016, at 10:57, Erik Joelsson wrote:
>
>
> On 2016-04-26 11:51, Chris Hegarty wrote:
>> On 26 Apr 2016, at 10:35, Erik Joelsson wrote:
>>
>>> Hello Chris,
>>>
>>> In general it looks good.
>> Thanks for the review Erik.
>
ntions.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 any non-SE API packages witho
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 must not
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/
https://bugs.openjdk.java.net/b
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 up
[ 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 compo
Forwarding, there are some small build changes.
Begin forwarded message:
> From: Chris Hegarty
> Date: 16 February 2016 at 19:19:35 GMT
> To: core-libs-dev
> Subject: RFR[9] 8068686: Remove meta-index support
>
> The Modular Run-Time image, integrated in b41, no longer ha
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 is,
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:
>
> I just updated my jdk 9 w
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 for
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 with
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, a
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 different
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 n
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.
/Er
On 5 Mar 2015, at 08:31, Alan Bateman 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 this loo
Looks good to me Stuart.
I tried the patch on Mac and Linux, both with the OpenJDK set of repos and with
Oracle’s additional ones, and all seems ok.
-Chris.
On 16 Dec 2014, at 17:38, Stuart Marks wrote:
> Hi all,
>
> Please review this change to hgforest.sh, to preserve argument quoting when
On 5 Dec 2014, at 18:14, Volker Simonis wrote:
> On Fri, Dec 5, 2014 at 7:09 PM, Chris Hegarty
> wrote:
>> Volker,
>>
>> Personally I would use the more verbose version,
>> Files.setPosixFilePermissions, so we can see any failures. But as Alan
>> pointed
x27;ve just checked 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
> wrote:
>> Thanks Volker,
>>
>> I agree with your change, or you ca
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 {
Set perms =
Files.getPosixFilePermissions(file);
perms.add(PosixFilePermission.OWNER_EXECUTE);
Staffan,
Having all the benchmarks located in a single place makes sense to me, but this
doesn’t necessarily mean that they need their own repository, in the forest.
If I can build, run, and test ( usual development cycle ) without any
dependency on these benchmarks, or their infrastructure,
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 wrote:
> This is a review request for the changes for JEP 220: Modular
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
Subject: RFR [JEP 220] Modular Run-Time
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 in the
[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
>>> Subject: RFR [JEP 220] Modular Run-Time Images
>>> Date: 20 November 2014 21:39:14 GMT
> From: Chris Hegarty
> Subject: RFR [JEP 220] Modular Run-Time Images
> Date: 20 November 2014 21:39:14 GMT
> To: jigsaw-dev , jdk9-dev
> , build-dev , Alan
> Bateman , Alex Buckley ,
> Chris Hegarty , Erik Joelsson
> , Jonathan Gibbons ,
> Karen Kinnear , "
), so I
> took the time to solve it in M2. What I mean by this is that M2 is prepared
> to handle it and the merge will not be that complicated anymore. I would
> rather have it done and dealt with early.
Ok. I’m happy to defer the decision on this to you.
-Chris.
> /Erik
>
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 n
On 14 Oct 2014, at 15:15, Daniel Fuchs wrote:
> On 14/10/14 16:09, Chris Hegarty wrote:
>> On 14 Oct 2014, at 15:03, Pavel Rappo 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 a
On 14 Oct 2014, at 15:03, Pavel Rappo 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 the crooks of the cha
On 12 Sep 2014, at 20:04, Mandy Chung 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. Rather than ke
On 28 Aug 2014, at 16:22, Volker Simonis 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 just close.c and move t
On 26 Aug 2014, at 08:26, Alan Bateman 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. This simplifies
tly because
the build 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 respon
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
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 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.
>
> Given that JDK 8 is
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 wrote:
>
> Hello all;
>
> This issue is a follow-on bug fix to JDK-8041151 (
This looks like a nice addition Mike.
-Chris.
On 5 May 2014, at 18:54, Mike Duigou 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
> http://cr.openjdk.j
:
> 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
> On 22 Apr 2014, at 09:10, Erik Joelsson 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 increase it
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: https://bug
posal ) ?
-Chris.
>
> Mike
>
> On Apr 11 2014, at 07:58 , 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 ( onl
ire 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,
for
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 usi
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 b/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 s
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 wrote:
>
>> Sometimes I get a little confused/nervous when trying to push/status/in
>> using
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 us
ensions=.bmp;
+
text/html: \
description=HTML Document;\
file_extensions=.htm,.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 ).
>>
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
To: OpenJDK Network Dev list
Following JDK-8004963: "URLConne
On 03/04/14 17:15, Mike Duigou wrote:
On Apr 3 2014, at 08:23 , Wang Weijun 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 slashes into one unless it
On 3 Apr 2014, at 11:16, Alan Bateman 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.
>>
>>
>
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 wrote:
> On 03/04/2014 09:53, Erik Joelsson wrote:
>> I don't see any reason not to make the switch. I filed this bug back in
>> Decem
While hunting around the build recently, when working on another SCTP bug, I
noticed a small issue where SCTP classes are being built on some platforms
unnecessarily.
Webrev:
http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/
Mac OS X and AIX contain only stubs for the SCTP channels
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 included
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
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 lin
e 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:al
1 - 100 of 201 matches
Mail list logo