Kelly, Alan,
The com/sun/nio/sctp tests are run when running the jdk regression tests
with the makefile in the jdk/test directory. They are currently part of
the jdk_nio3 target.
SCTP is a niche area and there is no need to have these tests run with
the nio tests. Also most of them are on th
Is it possible that one of the system includes in using C99 features? It
may be that on older Solaris boxes have an older version of the include
file?
-Chris.
On 14/09/2011 11:49, Weijun Wang wrote:
I'm building jdk8 on a solaris-sparc and see this failure:
/java/devtools/sparc/SUNWspro/SS12
"a.c", line 1: invalid token in #define macro parameters: ...
cc: acomp failed for a.c
-Max
On 09/14/2011 06:56 PM, Chris Hegarty wrote:
Is it possible that one of the system includes in using C99 features? It
may be that on older Solaris boxes have an older version of the include
file?
-
All of the security native libraries have runtime dependencies on
libjava and libjvm, most of which are completely unnecessary. This CR
proposes to remove these dependencies and provide localized versions of
the trivial utility functions that are being used from libjava, i.e. the
JNU_ThrowXXX f
On 23/10/2011 23:43, David Holmes wrote:
Hi Chris,
On 22/10/2011 1:43 AM, Chris Hegarty wrote:
All of the security native libraries have runtime dependencies on
libjava and libjvm, most of which are completely unnecessary. This CR
proposes to remove these dependencies and provide localized
On 12/16/11 09:57 AM, Alan Bateman wrote:
On 16/12/2011 02:59, Stuart Marks wrote:
...
Stuart - the changes look okay to me but it would be good to get
confirmation that you've done both full and partial builds with these
changes. Also I think we need confirmation that incremental builds in
eac
I filed CR 7122235 for this issue.
Forcing a compile time error of a JDK class by inserting some bad code
is just ignored and the build continues, and appears to complete
successfully.
I believe the changes for CR 7116322 "enhance javac make rule with a
little bit of instrumentation", caused
asking me about this a while back
>>>
>>> That was Wednesday - not long ago. jigsaw build has a similar issue:
>>> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/diff/459b6cbb0de7/make/common/Rules.gmk
>>>
>>>
>>> that I have fixed. I didn't get
Looks fine to me.
Let's resync after this push and see if there is some low hanging fruit
we can pick, like the areas with 1 warning?
-Chris.
On 28/12/2011 01:57, Stuart Marks wrote:
Hi all, here's any updated webrev for this fix:
http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.1/
Looks much better, thanks Magnus.
-Chris.
On 25/04/2012 14:32, Magnus Ihse Bursie wrote:
On 2012-04-23 18:01, Dmitry Samersoff wrote:
Magnus,
I'm second to Kelly.
We shouldn't have executable scripts in repository.
Ok, so here comes a new, even simpler patch. :-)
http://cr.openjdk.java.net
[ cc'ing awt-dev & 2d-dev ]
The change looks fine Magnus, though it may be best to push through the
awt or 2d forest. Members of these groups, cc'ed, are in a better
position to comment on this.
Oh, just to clarify, I agree and approve this change (as much as my
approval counts ;-) ). Just n
On 27/04/2012 21:37, Jim Graham wrote:
Thanks, sorry, I missed the part where this was responding to a change
that is already under way in the new build system...
Right, but it would be nice to trivially cleanup (remove these files)
from FILES_export list in the old build system.
-Chris.
On 10/05/2012 08:36, Erik Joelsson wrote:
That will certainly be convenient. I've tried it and it works for me.
Code looks good.
+1, thanks Kelly.
Anything that aids the migration off the forest extension can only be a
good thing. The changes look fine to me.
-Chris.
/Erik
On 2012-05-09
On 18/06/2012 18:25, Andrew Haley wrote:
The README-builds.html instructions say...
Slow Builds:
...
Creating the javadocs can be very slow, if you are running
javadoc, consider skipping that step.
But there is no information I can find about how to skip that step: I
think it's
Martin,
Unless you have changes that span multiple repositories, then it can be
quite straight forward to run webrev ( without '-f ) on just the
individual repository that you are changing. It will run with simply 'hg
out'.
If you have changes in multiple repo's then you have other choices:
This change looks ok to me.
-Chris.
On 13/08/2012 17:09, Seán Coffey wrote:
Similar to 7163470, the JDK has historically allowed builds without the
javax.crypto package src.
In such cases a jce.jar bootstrap should be used where necessary. One
remaining use case is during javadoc building proc
+1
-Chris.
On 05/09/2012 20:40, Kelly O'Hair wrote:
Looks fine to me.
-kto
On Sep 5, 2012, at 12:08 PM, John Coomes wrote:
Please review this small change to keep the script in sync with the
forest structure.
webrev:
http://cr.openjdk.java.net/~jcoomes/7196361-hs-make-closed/
inline diff
On 05/09/2012 21:13, John Coomes wrote:
Chris Hegarty ([email protected]) wrote:
+1
Thanks Chris. Apologies for not including you in the cset comment; I
committed the cset and started the push before getting your message.
No problem. More eyes always help ;-)
-Chris.
-John
On
On 10/09/2012 12:26, Magnus Ihse Bursie wrote:
I'd like to start a discussion about the partial builds; what problem
they solve and the best way to solve these problems in the new
build-infra world.
I'm currently investigating on how to handle the equivalence to partial
builds in the new build s
On 11/09/12 14:37, Anthony Petrov wrote:
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
Looks fine Kumar.
-Chris
On 31 Oct 2012, at 17:43, Kumar Srinivasan
wrote:
> Hello,
>
> Please review changes to rev up the default -source and -target for jdk
> compilation,
> thus producing v52.0 class files.
>
> Bug is here:
> https://jbs.oracle.com/bugs/browse/JDK-8001191
>
> Webrev is
On 11/14/2012 04:07 PM, Pete Brunet wrote:
In the incoming changesets those are the only two with IDs above 80.
Is it possible that you have an old version of jcheck on your client?
-Chris.
Also I forgot to indicate that the repo is
hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk
Pete
On 11/1
Thanks Stuart, looks good.
-Chris.
On 11/29/2012 08:14 AM, Alan Bateman wrote:
On 29/11/2012 02:08, Stuart Marks wrote:
Hi all,
The JDI tests have proven to be fairly unstable and are causing a lot
of spurious failures in our JPRT and nightly jobs. Instead of moving
all the tests into the pro
Looks fine me.
-Chris.
On 05/12/2012 10:52, Alan Bateman wrote:
The new build is broken in jdk8/tl again, this time it's Linux only and
the culprit is this change:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44ae777564eb
Attached is the proposed change. I'd like to push it to jdk8/tl/jdk.
-A
2012 09:28 AM, Weijun Wang wrote:
On 12/12/2012 01:50 AM, Chris Hegarty wrote:
Max,
Mark is looking to recompile com/sun/security/ntlm/Client.java during an
incremental build. I cannot find explicit targets for the
com/sun/security/ntlm files, are these compiled implicitly by reference
from ot
Thanks Erik,
I haven't tried this yet, but this is exactly what I was looking for (
some way to be partial builds ).
-Chris.
On 12/21/2012 09:39 AM, Erik Joelsson wrote:
There have been some concerns raised about partial builds going away
when switching to the new build. Sjavac is supposed t
On 05/01/2013 17:24, Jonathan Gibbons wrote:
Congratulations!
+1 great work guys. Can't wait until this makes its way into TL.
-Chris.
-- Jon
On 01/04/2013 09:04 PM, [email protected] wrote:
Changeset: 5cf7750c8c43
Author: ohair
Date: 2013-01-04 21:04 -0800
URL: http://hg.openjdk.ja
On 01/29/2013 05:26 PM, Kelly O'Hair wrote:
On Jan 28, 2013, at 1:02 PM, Martin Buchholz wrote:
On Mon, Jan 28, 2013 at 11:58 AM, Kelly O'Hair wrote:
I would like configure to be executable too, but openjdk has a tradition of not
allowing executable files in the source repos.
To avoid
Anyone see this failure when trying to build on mac. I have the latest
jdk8/tl forest, as of 28th Jan.
## Starting jdk
Importing CORBA classes.jar
Importing CORBA src.zip
Importing CORBA bin.zip
Importing JAXP classes.jar
Importing JAXP src.zip
Importing JAXWS classes.jar
Importing JAXWS src.z
Chris.
/Erik
On 2013-01-30 13:22, Chris Hegarty wrote:
Anyone see this failure when trying to build on mac. I have the latest
jdk8/tl forest, as of 28th Jan.
## Starting jdk
Importing CORBA classes.jar
Importing CORBA src.zip
Importing CORBA bin.zip
Importing JAXP classes.jar
Importing JAXP sr
[ to build-dev and core-libs-dev, expect reviewer from either, but will
integrate through jdk8/tl ]
This issue is mainly of interest to Oracle engineers, but it effects the
public hgforest script.
When hgforest.sh is run with an addition argument to specify a closed
server, there is a proble
On 1 Feb 2013, at 22:37, David Holmes wrote:
> Hi Chris,
>
> On 2/02/2013 12:40 AM, Chris Hegarty wrote:
>> [ to build-dev and core-libs-dev, expect reviewer from either, but will
>> integrate through jdk8/tl ]
>>
>> This issue is mainly of interest to Ora
On 02/02/2013 12:37 AM, David Holmes wrote:
...
I can see that happening if the sleeps are too short. But what I noticed
from the logging was that the closed repos were being processed before
the open ones - which shouldn't happen.
I believe the output is misleading. I think the output from
There has been some discussion on this with David, but no other takers.
Fredrik, am I right that you added the support for parallel
clone/update? I believe the changes I have are correct, but maybe you
had other ideas about how to solve this issue?
-Chris.
On 01/02/2013 14:40, Chris Hegarty
On 04/02/2013 10:04, Fredrik Öhrström wrote:
2013-02-04 10:48, Chris Hegarty skrev:
There has been some discussion on this with David, but no other takers.
Fredrik, am I right that you added the support for parallel
clone/update? I believe the changes I have are correct, but maybe you
had
ing to wait for '$path' to be created";
> fi
> 180 done
> 181 fi
>
> - Ioi
>
> On 02/01/2013 02:37 PM, David Holmes wrote:
>> Hi Chris,
>>
>> On 2/02/2013 12:40 AM, Chris Hegarty wrote:
>>> [ to build-de
Added diagnostic error message to help identify potential future
problems if a nested repo is blocked for too long
-Chris.
David
On 2/02/2013 12:40 AM, Chris Hegarty wrote:
[ to build-dev and core-libs-dev, expect reviewer from either, but will
integrate through jdk8/tl ]
This issue is main
itories to the latest sources
sh ./common/bin/hgforest.sh pull -u
don't we want "|| exit 1" for the pull case as well?
Since the pull is the last command there is no need for "|| exit 1",
since its exit code will be returned.
-Chris.
Thanks,
David
On 6/02/2013 12:0
an
obscure bug.
Also, now returning an error code when something fails should help avoid
any future issues of missing or out of date repos.
-Chris.
David
-
On 6/02/2013 8:04 PM, Chris Hegarty wrote:
Thank for the review. comments inline...
On 06/02/2013 01:53, David Holmes wrote:
204 #
holding directory seems like a small price to pay for such an
obscure bug.
Also, now returning an error code when something fails should help avoid
any future issues of missing or out of date repos.
-Chris.
David
-
On 6/02/2013 8:04 PM, Chris Hegarty wrote:
Thank for the review. comment
On 6 Feb 2013, at 16:26, [email protected] wrote:
> On Feb 6, 10:04am, [email protected] (Chris Hegarty) wrote:
> -- Subject: Re: RFR: race with nested repos in hgforest.sh
>
> | Yes this is better, but the quotes are incorrect. It should simply be
> |for rc in ${tmp
Looks fine to me.
-Chris.
On 25/02/2013 14:54, Alan Bateman wrote:
Last week, David Holmes had to do a temporary addition to refs.allowed
(used by the dependency analyzer in the profiles build) in order to get
profiles over the line (a last minute glitch caused by closed code). The
temporary a
On 02/26/2013 01:48 PM, Alan Bateman wrote:
The build changes for Nashorn were pushed to jdk8/tl yesterday and one
of the casualties is the profiles build.
My reading of the make file changes is that ListPathsSafely_If (defined
in MakeBase.gmk) has changed the expansion so that secondary expan
On 02/26/2013 01:52 PM, Alan Bateman wrote:
While looking at the Nashorn build changes, I see that
/make/nashorn-rules.gmk is included by the top-level Makefile but
was missed in the change-set.
Wow, a whole missing rules file! I'm surprised this wasn't caught during
build and testing.
I c
If I understand fixpath correctly, only needs to be run/wrap commands
(to convert path arguments), rather then on actual paths, then this
looks fine to me.
Great to see tl being buildable again.
-Chris.
On 27/02/2013 13:11, Alan Bateman wrote:
This is another patch to get jdk8/tl building a
Since the new build does not enable -Werror when compiling any java
code, and disables quite a few lint options, new changes my
inadvertently introduce warnings without even realizing. This can cause
problems when building with the old build as many areas do compile with
-Werror set. Since the
On 08/03/2013 15:49, Mike Duigou wrote:
Looks fine to me.
Thanks Mike.
> Do we have an issue open for restoring warnings to the new build?
Not yet, that I am aware of. We really need the ability to set lint
options per package/subpackage.
-Chris.
Mike
On Mar 8 2013, at 05:24 , Ch
much time was spent, to allow it to regress to the state it was in a few
years ago.
-Chris.
(Ideally it would be nice to warn but not fail on just this one lint
option, but don't see how that's possible.)
Brad
-Chris.
Mike
On Mar 8 2013, at 05:24 , Chris Hegarty wrote:
On 9 Mar 2013, at 19:01, Jonathan Gibbons wrote:
> On 03/09/2013 12:11 AM, Chris Hegarty wrote:
>>
>> Everyone seems to agree, a solution needs to be found to allow us to keep
>> certain areas warning free. This issue is too important, and too much time
>> was sp
Thank you for trying this Erik.
I did think of this "workaround" myself, but felt if might not be
acceptable due to the performance penalty. But this information is great
to have.
I wonder if we should try to get all alternatives/proposals on the
table, then make a decision. I know of two ot
On 03/14/2013 08:58 AM, Alan Bateman wrote:
On 14/03/2013 01:26, David Holmes wrote:
:
3. -Werror is set for the SCTP native code causing the build to fail:
Lots of stuff like:
/home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24:
error:
, Brad Wetmore wrote:
Sorry for the delay in response, I've been pulled in yet another
direction, and this has come back up in priority.
On 3/9/2013 12:11 AM, Chris Hegarty wrote:
I agree about warning creeping problems. This is a temporary solution,
we should soon be fixing the underlying has
Looks fine to me too. I remember being confused by these targets before,
nice to see this clean up.
-Chris
On 04/02/2013 08:48 AM, Alan Bateman wrote:
On 01/04/2013 21:19, Mike Duigou wrote:
Hello all;
Another changeset for review in the series "JDK-8009683 Running
regression tests with make
FWIW, looks ok to me.
-Chris.
On 04/19/2013 07:11 PM, Lance Andersen - Oracle wrote:
still looking for a committer to bless this webrev so I can put it back
thank you in advance
best
Lance
On Apr 9, 2013, at 11:58 AM, Lance Andersen - Oracle wrote:
Thank you ulf, I made the change in my wo
Thanks for the explanation, it makes reviewing much easier.
I can see the additional types in the changeset for 8005523, so it looks
good to me.
If possible, it would be nice if that anyone touching source that
effects jsse.jar could also check the profiles target. That said, I
wasn't aware
Dmitry,
On 12/05/2013 23:42, Dmitry Samersoff wrote:
Mark,
I did some experiments on weekends and I'm against of using -u option
under any circumstances.
There are valid usecases for '-u'. For one, sync'ing from upstream
projects, Doug's CVS comes to mind.
-Chris.
People sponsoring chan
Please hold your fire! This is not a suggestion to about general
handling of warnings during the build, just a specific gripe I have when
trying to find genuine build failures among the noise.
Would there be any objection to adding '-overrides' to the jdk build?
This lint warning was added aft
future warning cleanup events.
-Chris.
Maurizio
On 13/05/13 14:53, Chris Hegarty wrote:
Please hold your fire! This is not a suggestion to about general
handling of warnings during the build, just a specific gripe I have
when trying to find genuine build failures among the noise.
Would th
the errors when they get lots in
the warnings. I just wonder whether we should just fix what seems like a
small number of warnings.
-Alan
On 13/05/2013 14:53, Chris Hegarty wrote:
Please hold your fire! This is not a suggestion to about general
handling of warnings during the build, just a s
an among equals
implementations.)
Regards,
-Joe
On 5/13/2013 8:36 AM, Chris Hegarty wrote:
I have no objection to someone fixing these warnings. They are across
a number of different areas, and could take an amount of time to resolve.
If we are to have a concerted effort, I'm not sure that I wo
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
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
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
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, 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 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 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 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, 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 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
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 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
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.
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
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
> 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.
> 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 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
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 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
> 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 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
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
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
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
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 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/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
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
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,
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
[ 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
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
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 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
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 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.
>
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 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 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
1 - 100 of 201 matches
Mail list logo
