On 14/06/2017 22:44, Peter Levart wrote:
:
In j.l.Module:
There are two places in the same method that contain exactly the same
fragment of code:
566 if (targets.contains(EVERYONE_MODULE) ||
targets.contains(other))
567 return true;
568
On 15/06/2017 15:28, Mandy Chung wrote:
On Jun 15, 2017, at 12:34 AM, Alan Bateman wrote:
java/lang/Module.java
901 void implAddOpensToAllUnnamed(Iterator iterator) {
902 if (jdk.internal.misc.VM.isModuleSystemInited()) {
903 iterator.forEachRemaining(pn ->
90
> On Jun 15, 2017, at 12:34 AM, Alan Bateman wrote:
>
>>
>> java/lang/Module.java
>> 901 void implAddOpensToAllUnnamed(Iterator iterator) {
>> 902 if (jdk.internal.misc.VM.isModuleSystemInited()) {
>> 903 iterator.forEachRemaining(pn ->
>> 904 implAdd
Hi Alan,
On 06/15/2017 09:34 AM, Alan Bateman wrote:
2453 reflectionFactory.getExecutableSharedParameterTypes(method),
reflectionFactory should be accessed via getReflectionFactory(). I
see Peter
already comments on this.
Thanks, it should be getReflectionFactory().
...and I would also in
On 15/06/2017 06:37, Mandy Chung wrote:
:
java/lang/Class.java
2453
reflectionFactory.getExecutableSharedParameterTypes(method),
reflectionFactory should be accessed via getReflectionFactory(). I see Peter
already comments on this.
Thanks, it should be getReflectionFacto
Re-reading my post in the morning...
On 06/14/2017 11:44 PM, Peter Levart wrote:
In j.l.Module:
There are two places in the same method that contain exactly the same
fragment of code:
566 if (targets.contains(EVERYONE_MODULE) ||
targets.contains(other))
567
Thanks for looking through this.
On 14/06/2017 22:44, Peter Levart wrote:
:
...where you use the 'reflectionFactory' field one time and
'getReflectionFactory()' method another time. The field might not
already be initialized...
Well spotted, it should be using getReflectionFactory(), not
ref
> On Jun 14, 2017, at 9:52 AM, Alan Bateman wrote:
>
> It's time to bring the changes accumulated in the jake forest into jdk9/dev.
> I'm hoping we are near the end of these updates and that we can close the
> jake forest soon.
>
> A summary of the changes that have accumulated for this updat
Hi Alan,
I looked at the hotspot and top changes.
They look good.
Thanks,
Serguei
On 6/14/17 09:52, Alan Bateman wrote:
It's time to bring the changes accumulated in the jake forest into
jdk9/dev. I'm hoping we are near the end of these updates and that we
can close the jake forest soon.
A
Hi Alan,
Looking just at changes in jdk part...
On 06/14/2017 06:52 PM, Alan Bateman wrote:
It's time to bring the changes accumulated in the jake forest into
jdk9/dev. I'm hoping we are near the end of these updates and that we
can close the jake forest soon.
A summary of the changes that h
It's time to bring the changes accumulated in the jake forest into
jdk9/dev. I'm hoping we are near the end of these updates and that we
can close the jake forest soon.
A summary of the changes that have accumulated for this update are
listed in this issue:
https://bugs.openjdk.java.net/b
11 matches
Mail list logo