On 02/10/2017 02:49 PM, Alan Bateman wrote:
Here's what you could do:
http://cr.openjdk.java.net/~plevart/jdk9-jake/AccessibleObject.canAccess_caching/webrev.01/
Good idea. Do you want to create an issue for this and follow-up on
core-libs-dev? The changes are in jdk9/dev now so it can foll
On 10/02/2017 10:00, Peter Levart wrote:
First, just a nit...
java.lang.module.Resolver:
320 private void addFoundModule(ModuleReference mref) {
321 ModuleDescriptor descriptor = mref.descriptor();
322 nameToReference.put(descriptor.name(), mref);
323
324 if (
Hi Alan,
On 02/09/2017 10:28 PM, Alan Bateman wrote:
On 07/02/2017 13:23, Alan Bateman wrote:
I will re-generate the webrevs later in the week once jdk-9+156 is
promoted before eventually merging with jdk9/dev in advance of the
eventual push.
I've sync'ed up jake to jdk-9+156 and re-generate
On 07/02/2017 13:23, Alan Bateman wrote:
I will re-generate the webrevs later in the week once jdk-9+156 is
promoted before eventually merging with jdk9/dev in advance of the
eventual push.
I've sync'ed up jake to jdk-9+156 and re-generated the webrevs:
http://cr.openjdk.java.net/~alanb/817
Hotspot changes look good.
thanks,
Karen
> On Feb 7, 2017, at 8:23 AM, Alan Bateman wrote:
>
> We've been accumulating changes in the jake forest for the last few weeks and
> it's time to bring the changes to jdk9/dev, to make jdk-9+157 if possible.
> JDK 9 is the first phase of rampdown and
I reviewed your updated webrev:
http://cr.openjdk.java.net/~alanb/8173393/2
src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java
285 m.descriptor.packages().forEach(builder::opens);
This is not needed. I took it out.
We probably will do another pass on the APIs to tag with
> On 8 Feb 2017, at 03:37, Alan Bateman wrote:
>
> On 08/02/2017 03:10, Paul Sandoz wrote:
>
>> Hi,
>>
>> Just minor stuff in the JDK area (i browsed quickly through the tests).
> Thanks, a few comments below.
>
>>
>> Paul.
>>
>>
>> java.lang.module.Configuration
>> —
>>
>> 321 * @i
On 08/02/2017 14:49, Claes Redestad wrote:
From a startup perspective all alternatives are more or less equal
here, and generally speaking a lambda and a method reference are equal
as long as they're both non-capturing.
A detail I had missed here, though, is that the createModuleReader
meth
Hi,
On 2017-02-08 12:37, Alan Bateman wrote:
BuiltinClassLoader
—
925 private ModuleReader moduleReaderFor(ModuleReference mref) {
926 return moduleToReader.computeIfAbsent(mref, m ->
createModuleReader(m));
927 }
Use this:: createModuleReader
I'll defer to Claes on th
On 08/02/2017 03:10, Paul Sandoz wrote:
Hi,
Just minor stuff in the JDK area (i browsed quickly through the tests).
Thanks, a few comments below.
Paul.
java.lang.module.Configuration
—
321 * @implNote In the implementation then observability of modules may
depend
s/then/the
"the
Hi,
Just minor stuff in the JDK area (i browsed quickly through the tests).
Paul.
java.lang.module.Configuration
—
321 * @implNote In the implementation then observability of modules may
depend
s/then/the
ModuleDescriptor
—
2662 private static >
2663 int compare(Set s1, Set
Hotspot changes look good to me.
Lois
On 2/7/2017 8:23 AM, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make
jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so
this update will n
Hi Alan,
jaxp and stack walking class (and test) changes look OK to me.
best regards,
-- daniel
On 07/02/17 13:23, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make jdk-9+157
if possible. JDK
Langtools changes look good to me.
Maurizio
On 07/02/17 13:23, Alan Bateman wrote:
We've been accumulating changes in the jake forest for the last few
weeks and it's time to bring the changes to jdk9/dev, to make
jdk-9+157 if possible. JDK 9 is the first phase of rampdown and so
this update
14 matches
Mail list logo
