On 29/05/2015 07:58, Xueming Shen wrote:
Please help review change to move the AbstractCharsetProvider from
java.base/sun.nio.cs to
jdk.charsets/sun.nio.cs.ext. This is needed for the modules.
issue: https://bugs.openjdk.java.net/browse/JDK-8081452
webrev: http://cr.openjdk.java.net/~sherman/
It was originally written to be the base class for both std and ext
charsets providers... maybe it should
just be merged into the ExtendedCharsets class later separately.
-sherman
On 5/29/2015 12:04 AM, Alan Bateman wrote:
On 29/05/2015 07:58, Xueming Shen wrote:
Please help review change to
Vladimir,
What do you mean by ignore code cache overflow? Do you mean I should fix
the test to ignore these errors or should I leave this test unfixed
because it is a product related issue?
-Konstantin
On 28.05.2015 21:22, Vladimir Ivanov wrote:
Got it, thanks.
Can we ignore errors caused
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8081479
Webrev is http://cr.openjdk.java.net/~kshefov/8081479/webrev.00/
It's a backport of JDK9 JDBC tests to JDK8u.
Thanks
Maxim
What do you mean by ignore code cache overflow? Do you mean I should fix
the test to ignore these errors or should I leave this test unfixed
because it is a product related issue?
The former. How reliable the test is if it ignores NoSuchMethodException
& VirtualMachineError? Are there other manif
On 26/05/2015 13:24, Miroslav Kos wrote:
Thanks, you are correct. Changed to try-catch with resources, the some
code moved to SchemaCache. Refernced resources found by
com.sun.tools.internal.xjc.SchemaCache.ResourceResolver added to
collection and closed after parsing.
updated webrev: http:
Hi Maxim,
this looks fine
Best
Lance
On May 29, 2015, at 7:34 AM, Maxim Soloviev wrote:
> Hello,
>
> Please review the test bug fix
> https://bugs.openjdk.java.net/browse/JDK-8081479
> Webrev is http://cr.openjdk.java.net/~kshefov/8081479/webrev.00/
> It's a backport of JDK9 JDBC tests to JDK8
Hi Peter,
It is a very interesting proposal but to further David’s comments, the
life-cycle costs of reference objects is horrendous of which the actual process
of finalizing an object is only a fraction of that total cost. Unfortunately
your micro-benchmark only focuses on one aspect of that c
On 05/29/2015 12:20 AM, Xueming Shen wrote:
It was originally written to be the base class for both std and ext
charsets providers... maybe it should
just be merged into the ExtendedCharsets class later separately.
Perhaps better to merge it now rather than separately?
Mandy
-sherman
On 5
Thank you Martin for review!
On 29.05.2015 3:03, Martin Buchholz wrote:
Approved.
On Thu, May 28, 2015 at 3:43 PM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
Good naming is one of the most difficult part of coding IMO.
The chosen names were meant to be read literally: "
Thanks for your hint David. That's the only reason I could imagine too.
Can somebody tell something about the cost for recursive lock acquisition in comparison to the whole
call, couldn't it be eliminated by Hotspot?
As I recently fell into the trap of forgetting the synchronized block around a
For what it's worth, I fully agree with David and Kirk around finalization not
necessarily needing this treatment.
However, I was hoping this would have the effect of improving (non-finalizable)
reference handling. We've seen serious issues in WeakReference handling and
have had to write some t
On 05/29/2015 09:28 AM, Mandy Chung wrote:
On 05/29/2015 12:20 AM, Xueming Shen wrote:
It was originally written to be the base class for both std and ext charsets
providers... maybe it should
just be merged into the ExtendedCharsets class later separately.
Perhaps better to merge it now rat
Please review the removal of the java/lang/ProcessHandle/ScaleTest for
ProcessHandles.
It is not appropriate for regression testing and does not run reliably.
It was inadvertently included in the commit.
Webrev:
http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-scaletest-remove-8081536/
Iss
Approved; cheers,
-Joe
On 5/29/2015 12:13 PM, Roger Riggs wrote:
Please review the removal of the java/lang/ProcessHandle/ScaleTest for
ProcessHandles.
It is not appropriate for regression testing and does not run reliably.
It was inadvertently included in the commit.
Webrev:
http://bussund04
Am 29.05.2015 um 19:42 schrieb Xueming Shen:
But if it is decided later that we may want to have a separate ext charsets provider2, for example
to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base
class ...
Hm, is it mandatory, that each charset pr
On 5/29/15 4:02 PM, Ulf Zibis wrote:
Am 29.05.2015 um 19:42 schrieb Xueming Shen:
But if it is decided later that we may want to have a separate ext
charsets provider2, for example to split most of the ibm charsets to
a separate provider, it might be desired to keep it as a base class ...
Hm,
17 matches
Mail list logo
