On 4/22/2016 1:09 AM, Alan Bateman wrote:
On 22/04/2016 09:06, Amy Lu wrote:
Please review this tiny fix for typos in the the documentation of:
jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java
jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java
bug: https://b
Hi Roger,
Per other discussion in the thread, no new method will be introduced.
The area owners will need to cleanup this usage of this method since it
may involve restructuring of catch blocks, etc., since the recommended
approach has different exception behavior.
Thanks,
-Joe
On 4/22/201
Hi Harry,
Great to see a new contributor.
If you haven't read up on the OpenJDK processes, there are a few things
you can read
about how to contribute [1] and the developers guide [2]
Typically, changes are applied to the current developers release (JDK 9)
and then backported
as needed. Plea
Also a couple of minor suggestions:
- * Set native thread name as possible.
+ * Set native thread name if possible.
+ /*
- * We can clear pending exception because exception at this point
- * is not critical.
+ */
+ /*
+ * Clear non critical pending exception
Well done.
Roger
On 4/22/2016 11:38 AM, Chris Hegarty wrote:
Another remaining JEP 260 task that can now be resolved ( remove a
non-Critical API from sun.misc ).
With all the subtasks of 8147543 [1] complete, i.e. all the dependencies on
ManagedLocalsThread have been removed, it is time to r
Hi Joe,
Wouldn't it be less make work to introduce the new method, replace the
current one where appropriate
and then deprecate the existing method? As it is, you/someone is going
to make a second pass
over all the same files.
Roger
On 4/21/2016 12:25 PM, joe darcy wrote:
Hello,
After a
Another remaining JEP 260 task that can now be resolved ( remove a
non-Critical API from sun.misc ).
With all the subtasks of 8147543 [1] complete, i.e. all the dependencies on
ManagedLocalsThread have been removed, it is time to remove the type
itself ( its functionality has been superseded by th
2016/4/22 5:39:26 -0700, [email protected]:
> On 20 Apr 2016, at 02:11, [email protected] wrote:
>> 2016/4/19 12:37:41 -0700, Hervé BOUTEMY :
>>> Perhaps this requirement should be described in
>>> http://openjdk.java.net/jeps/238
>>
>> Yes -- that was certainly non-obvious!
>>
>> Ste
> On Apr 21, 2016, at 11:31 PM, Alan Bateman wrote:
>
> On 21/04/2016 23:03, Mandy Chung wrote:
>> Webrev:
>>http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8154837/webrev.00/
>>
>> The module location from an exploded image is file URL rather than file
>> path. This issue can be reproduc
Hi,
This is in the wrong place:
1715 if ((*env)->ExceptionOccurred(env)) {
1716 /*
1717* We can clear pending exception because exception at this point
1718* is not critical.
1719*/
1720 (*env)->ExceptionClear(env);
1721 }
This above needs to be after
Hi Michael,
thanks for simplifying and cleaning things up. With both patches applied
the code looks good to me.
/Claes
On 2016-04-22 14:41, Michael Haupt wrote:
Hi Claes,
thanks for this one as well; see
http://cr.openjdk.java.net/~mhaupt/8154754/webrev.01/ for an updated webrev.
This pat
Hi Claes,
thanks for this one as well; see
http://cr.openjdk.java.net/~mhaupt/8154754/webrev.01/ for an updated webrev.
This patch still depends on the one for 8154751.
Best,
Michael
> Am 22.04.2016 um 12:18 schrieb Claes Redestad :
>
> Hi,
>
> looks good to me. resultType == void.class ? z
Hi Claes,
thank you. I've applied the refactoring - see
http://cr.openjdk.java.net/~mhaupt/8154751/webrev.01/ for an update.
Best,
Michael
> Am 22.04.2016 um 12:09 schrieb Claes Redestad :
>
> Hi Michael,
>
> voidReturn ? zero(void.class) : identity(init.type().returnType()) is used
> twice
> On 20 Apr 2016, at 02:11, [email protected] wrote:
>
> 2016/4/19 12:37:41 -0700, Hervé BOUTEMY :
>> that's it: I added this Multi-Release: true attribute configuration in the
>> demo and now it works like a charm, thank you
>>
>> Perhaps this requirement should be described in
>> http:/
Hi David,
I don't think we need to report the exception, but can just ignore it. Either
way we have to clear the exception before continuing.
I've fixed it in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/
http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/
Hi Claes,
thank you - I've applied this simple change and pushed.
Best,
Michael
> Am 22.04.2016 um 12:13 schrieb Claes Redestad :
>
> Hi,
>
> change looks good.
>
> There's a small pre-existing inefficiency in that initit is created
> unconditionally but only used if iterator == null, thus
n 22 Apr 2016, at 10:07, Alan Bateman wrote:
> On 22/04/2016 09:47, Chris Hegarty wrote:
>> The jdk.unsupported module was added to the LimitModsTest.java test
>> temporally, until the problematic dependency from the java.logging
>> module on the jdk.unsupported module could be resolved. This is
Hi,
looks good to me. resultType == void.class ? zero(void.class) :
identity(resultType) appears twice and unconditionally used at least
once, thus could be profitably extracted to a variable for
readability/imaginary performance gain. Thanks! /Claes
On 2016-04-20 15:46, Michael Haupt wrote:
Hi,
change looks good.
There's a small pre-existing inefficiency in that initit is created
unconditionally but only used if iterator == null, thus could be
refactored into an if (iterator == null) ... else construct
Thanks!
/Claes
On 2016-04-20 11:25, Michael Haupt wrote:
Dear all,
pleas
Hi Michael,
voidReturn ? zero(void.class) : identity(init.type().returnType()) is
used twice, breaking it out to variable would improve readability,
possibly performance. Same goes for the subexpression
init.type().returnType() which is used three times currently.
Otherwise it looks fine to
On 21/04/2016 23:32, Stuart Marks wrote:
> Hi Mark,
>
> Is it possible to save the reference to the registry that was created by
> the call to LocateRegistry.createRegistry()? If so, then it's possible
> to shut down that registry by exporting it:
>
> UnicastRemoteObject.unexportObject(regist
On 22/04/2016 09:47, Chris Hegarty wrote:
The jdk.unsupported module was added to the LimitModsTest.java test
temporally, until the problematic dependency from the java.logging
module on the jdk.unsupported module could be resolved. This is
now resolved, see 8153158 [1].
It was an oversight of t
The jdk.unsupported module was added to the LimitModsTest.java test
temporally, until the problematic dependency from the java.logging
module on the jdk.unsupported module could be resolved. This is
now resolved, see 8153158 [1].
It was an oversight of the changes for 8153158 that this test was n
On 22/04/2016 09:06, Amy Lu wrote:
Please review this tiny fix for typos in the the documentation of:
jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java
jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java
bug: https://bugs.openjdk.java.net/browse/JDK-8154277
web
Please review this tiny fix for typos in the the documentation of:
jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java
jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java
bug: https://bugs.openjdk.java.net/browse/JDK-8154277
webrev: http://cr.openjdk.java.net/~amlu
25 matches
Mail list logo
