On 09/10/15 13:08, Peter Levart wrote:
Hi,
On 10/09/2015 04:39 AM, Paul Benedict wrote:
I don't think the statements "Creates an unmodifiable set containing X
elements" is always true. Since sets cannot have duplicates, it's
possible
passing in X elements gives you less than that based on equal
The functionality provided by these classes has long since been provided
by supported APIs in java.util.concurrent.locks. Nothing internal, or external
( to the best of my knowledge ), to the JDK is depending on these classes.
They should simply be removed.
$ hg rm src/java.base/share/classes/
On 9 Oct 2015, at 19:51, Stuart Marks wrote:
> On 10/9/15 10:23 AM, Chris Hegarty wrote:
>> The functionality provided by these classes has long since been provided
>> by supported APIs in java.util.concurrent.locks. Nothing internal, or
>> external
>> ( to the bes
This is a little temporary solution to get the jrt-fs up and running again
with JDK 8, until JDK-8137017 [1] can be resolved.
It is fair game for an unchecked Exception or Error thrown during
class initialization to result in a NCDFE. The code in BasicImageReader
should catch java.lang.LinkageErr
On 9 Oct 2015, at 20:26, Alan Bateman wrote:
> I looked more closely at this and I think it's best to handle NCDFE rather
> than the more general LinkageError.
Ok, I make the follow change before pushing:
diff --git
a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
b/s
Looks ok to me Amy.
-Chris.
On 12/10/15 09:27, Amy Lu wrote:
Test java/rmi/registry/readTest/readTest.sh is known to fail
intermittently, this patch is to mark the test accordingly with keyword
'intermittent'.
bug: https://bugs.openjdk.java.net/browse/JDK-8139407
webrev: http://cr.openjdk.java
On 12 Oct 2015, at 17:54, Mandy Chung wrote:
>
>> On Oct 12, 2015, at 8:09 AM, Vyom Tewari wrote:
>>
>> Hi All,
>>
>> Please review my changes for below bug.
>>
>> Bug:JDK-8068887 : java.lang.Throwable could use
>> Collections.emptyList for suppressedException
>> Webrev: http:/
On 1 Oct 2015, at 15:12, Roger Riggs wrote:
> ….
>
> Javadoc:
> http://cr.openjdk.java.net/~rriggs/cleaner-doc/
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
This is nice addition. Some comments / questions:
1) Should the behaviour, TCCL, permissions, etc, for
On 14 Oct 2015, at 15:15, Remi Forax wrote:
> - Mail original -
>> De: "Paul Sandoz"
>> Cc: "core-libs-dev"
>> Envoyé: Mercredi 14 Octobre 2015 13:46:38
>> Objet: Re: java.lang.reflect.Method.copyOf
>>
>>
>>> On 14 Oct 2015, at 12:38, Remi Forax wrote:
>>>
>>> Given that j.l.r.Metho
Roger,
On 14 Oct 2015, at 18:43, Roger Riggs wrote:
> Hi Alan, Mandy,
>
> I looked at a few of the many uses of finalize and the likely changes.
> The zip Inflater and Deflater are relatively simple cases.
> Some finalizers are not used and can be removed.
It is not immediately clear to me. Ar
Peter,
On 15 Oct 2015, at 09:12, Peter Levart wrote:
> On 10/14/2015 07:43 PM, Roger Riggs wrote:
>> Hi Alan, Mandy,
>>
>> I looked at a few of the many uses of finalize and the likely changes.
>> The zip Inflater and Deflater are relatively simple cases.
>> Some finalizers are not used and can
Looks good to me Sean. All other state seems to be accessed when holding zsRef.
-Chris.
On 15 Oct 2015, at 10:02, Seán Coffey wrote:
> bug report : https://bugs.openjdk.java.net/browse/JDK-8038502
>
> The len instance variable should be read/written while holding the zsRef lock.
>
> needsInpu
On 15 Oct 2015, at 14:21, Roger Riggs wrote:
> ...
>
> Also, I've seen a few calls to super.finalize() where there were no finalizers
> in any of the superclasses. It would be considered good design to always
> include it.
> I don't know if the optimization for empty finalize methods includes
> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote:
>
> Hello,
>
> This does change a bit the semantic of the length check. If the stream would
> return more bytes than the zipentry says the new version would ignore them,
> the old version was consuming then and then fail the check. How
> On 15 Oct 2015, at 11:08 p.m., Claes Redestad
> wrote:
>
>
> On 2015-10-15 23:21, Chris Hegarty wrote:
>>> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote:
>>>
>>> Hello,
>>>
>>> This does change a bit the semantic of
On 16/10/15 12:49, Claes Redestad wrote:
On 2015-10-16 04:09, Xueming Shen wrote:
On 10/15/15 3:08 PM, Claes Redestad wrote:
On 2015-10-15 23:21, Chris Hegarty wrote:
On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote:
Hello,
This does change a bit the semantic of the length check. If
Looks fine Joe.
-Chris.
> On 19 Oct 2015, at 8:43 p.m., joe darcy wrote:
>
> Hello,
>
> Please review the fix below to address
>
>JDK-8139925: Problem list LFMultiThreadCachingTest.java on windows
>
> The test in question,
>
>test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.
As part of the preparation for JEP 260 [1], Unsafe needs to be separable
from the base module [2], so it can be exported by a new, yet to be
defined, jdk.unsupported module, and have a separate evolution policy
that is not exposed. That is, the JDK needs an internal Unsafe that can
be evolved and a
On 23/10/15 10:14, Andrew Haley wrote:
On 22/10/15 15:48, Christoph Engelbert wrote:
I don’t like to say it but it sounds very wrong to have another
Unsafe like thinggy in the future instead of providing public
alternatives right from the start. I agree it might be a faster to
just write adapte
Thanks for looking at this John. Comments inline…
On 23 Oct 2015, at 02:06, John Rose wrote:
> On Oct 22, 2015, at 7:28 AM, Chris Hegarty wrote:
>>
>> To this end I've put together a webrev containing the changes required
>> for step 1. It contains
>> - th
up.
Possibly. CheckIntrinsics, in a fast debug build, will catch if there
is a mismatch. I hope to also add some new tests to the hotspot
forest to make sure Unsafe continues to work as expected.
-Chris.
>> Paul.
>>
>>> On 22 Oct 2015, at 07:28, Chris Hegarty wrote:
>
Hi David, Alan,
> On 26 Oct 2015, at 01:49, Alan Bateman wrote:
>
> On 26/10/2015 01:41, David Holmes wrote:
>
>>> If you are in agreement, is it best to move this first step on and
>>> push it into hs-rt. I can then follow up with the additional steps:
>>> hotspot test updates in hs-rt, and th
On 27 Oct 2015, at 13:56, Aleksey Shipilev wrote:
> On 10/27/2015 04:51 PM, Claes Redestad wrote:
>>
>>
>> On 2015-10-27 14:21, Aleksey Shipilev wrote:
>>> On 10/25/2015 04:27 AM, Claes Redestad wrote:
when deserializing objects with references to themselves,
ObjectInputStream pointle
Following on from 8139891 "Prepare Unsafe for true encapsulation” [1],
the JDK library code should use the internal Unsafe class, and not
sun.misc.Unsafe.
http://cr.openjdk.java.net/~chegar/8140606/00/
This will be pushed to jdk9/dev once 8139891 makes its way from
hs-rt.
-Chris.
[1] https://bu
On 28 Oct 2015, at 22:14, Alan Bateman wrote:
> On 28/10/2015 19:55, Chris Hegarty wrote:
>> Following on from 8139891 "Prepare Unsafe for true encapsulation” [1],
>> the JDK library code should use the internal Unsafe class, and not
>> sun.misc.Unsafe.
>>
>&
rive. Since the major 166 sync is done, the
amount of change in this area should be small. I can help out
with incoming changes also, until you fork.
-Chris.
> On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty
> wrote:
> Following on from 8139891 "Prepare Unsafe for true encapsulation” [
In line with the intended location for other VM annotations,
see 8138732 [1], @sun.misc.Contended should be moved
to the jdk.internal.vm.annotation package.
http://cr.openjdk.java.net/~chegar/8140687/00/
-Chris.
[1] https://bugs.openjdk.java.net/browse/JDK-8138732
> On 2 Nov 2015, at 12:54 a.m., David Holmes wrote:
>
> Hi Chris,
>
> hotspot and jdk changes look fine to me.
Thanks for looking at this David.
-Chris.
> Thanks,
> David
>
>> On 2/11/2015 9:56 AM, Chris Hegarty wrote:
>> In line with the intended locat
On 02/11/15 10:45, Aleksey Shipilev wrote:
On 11/02/2015 02:56 AM, Chris Hegarty wrote:
In line with the intended location for other VM annotations,
see 8138732 [1], @sun.misc.Contended should be moved
to the jdk.internal.vm.annotation package.
http://cr.openjdk.java.net/~chegar/8140687/00
On 09/11/15 12:34, Peter Levart wrote:
On 11/09/2015 01:32 PM, Peter Levart wrote:
On 11/09/2015 11:43 AM, Chris Hegarty wrote:
On 02/11/15 10:45, Aleksey Shipilev wrote:
On 11/02/2015 02:56 AM, Chris Hegarty wrote:
In line with the intended location for other VM annotations,
see 8138732
On 10 Nov 2015, at 18:55, Roger Riggs wrote:
> A few of the proposed replacements of ?: with requireNonNullElse were
> unsuitable
> because in the particular context, null is an allowed replacement value.
>
> The webrev has been updated to revert changes:
> - two uses in
> jdk/src/java.base/sh
On 9 Nov 2015, at 12:49, Doug Lea wrote:
> On 11/09/2015 05:43 AM, Chris Hegarty wrote:
>> On 02/11/15 10:45, Aleksey Shipilev wrote:
>>> On 11/02/2015 02:56 AM, Chris Hegarty wrote:
>>>> In line with the intended location for other VM annotations,
>>>
On 11 Nov 2015, at 13:11, Doug Lea wrote:
> On 11/11/2015 07:06 AM, Chris Hegarty wrote:
>
>>>>>> http://cr.openjdk.java.net/~chegar/8140687/00/
>>>>>
>>>
>>> While this is up for review, could someone please explain
>>> ag
To me, it sounds like @Contended, in its current form, is not quite ready
for prime-time ( inclusion in Java SE 9 ). There is some concern about its
implementation, and I’m not sure how the loader restriction, and the control
through a -XX flag, would translate into SE spec. There is certainly some
Given John's comments, and the limitation of -XX:-RestrictContended,
adding an additional command line flag, -XaddExports, in 9 to access
@CS seems reasonable. I will proceed with this change as is.
http://cr.openjdk.java.net/~chegar/8140687/00/
-Chris.
On 13/11/15 00:08, John Rose wrote:
O
Stuart,
This is looking very good, and simple. Nice.
Sorry if this has come up already, but is the "@return the newly
created xxx” too restrictive? Will it require the implementation to
return a NEW instance of xxx for each invocation, even of() ?
-Chris.
On 24 Nov 2015, at 06:26, Stuart Marks
On 24 Nov 2015, at 23:27, Stuart Marks wrote:
> ….
>
> But in the hypothetical value-typed future, we might want to return value
> types from at least some of the factory methods. Value types have no notion
> of identity, so we don't want to make any statements that lead to thinking
> about th
On 29/11/15 16:42, Claes Redestad wrote:
On 2015-11-29 17:18, Alan Bateman wrote:
On 29/11/2015 14:30, Claes Redestad wrote:
On 2015-11-25 16:23, Aleksey Shipilev wrote:
On 11/25/2015 06:14 PM, Claes Redestad wrote:
Inlining the isPrimitive check should be enough to avoid extra
comparisons:
I looked at the jdk webrev, looks fine.
Out of curiosity, what is the point of running the test with
-Xint? Does it verify anything useful?
-Chris.
On 26/11/15 16:22, Paul Sandoz wrote:
Hi,
I have updated the patches:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fenc
On 30/11/15 11:31, Claes Redestad wrote:
On 2015-11-30 11:38, Chris Hegarty wrote:
I'm OK with moving these utility methods to a more neutral place, but
since the BytecodeDescriptor utilities are public for now, maybe this
should be a follow-up once/if
these classes become pro
On 30/11/15 11:35, Peter Levart wrote:
...
Wouldn't it be nice to offer this often needed functionality as a public
API? It would fit naturally on the java.lang.Class as an instance method.
I don't have a strong opinion either way on this. I'm
ok with Claes proceeding with this bug as is. Any
On 30/11/15 12:41, Paul Sandoz wrote:
On 30 Nov 2015, at 12:48, Chris Hegarty wrote:
I looked at the jdk webrev, looks fine.
Out of curiosity, what is the point of running the test with
-Xint? Does it verify anything useful?
It tests our assumptions are correct about the interpreter
On 26 Nov 2015, at 12:00, Aleksey Shipilev wrote:
> On 11/26/2015 12:55 PM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/
>
> Both JDK and Hotspot changes look good to
The regression tests in the jdk should be updated, where possible, to
use java.util.Base64.
http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
-Chris.
On 02/12/15 14:03, Alan Bateman wrote:
On 02/12/2015 12:08, Chris Hegarty wrote:
The regression tests in the jdk should be updated, where possible, to
use java.util.Base64.
http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
Should S11N be updated to serialize with JDK 8 so that
Updated to remove all use of reflection. If someone really
wants to run S11N on an older JDK, then it is a simple
edit to uncomment/comment 3 lines.
http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/
-Chris.
On 02/12/15 14:15, Chris Hegarty wrote:
On 02/12/15 14:03, Alan
Thanks Max,
I'm ok with this version, if you are. I'll include it in the final push.
-Chris.
On 02/12/15 15:13, Wang Weijun wrote:
On Dec 2, 2015, at 10:52 PM, Wang Weijun wrote:
My fault to use an internal class. I should have simply used the hex encoding.
Please wait a while and I'll se
in this fix.
> Missed? or justbecause this test will be totally removed soon in a separate
> bugid?
Since this test is specifically designed to test the coder
functionality, then it will be proposed to be removed when the coders are.
Thanks,
-Chris.
> Thanks,
> Amy
>
&g
On 2 Dec 2015, at 20:23, Roger Riggs wrote:
> Please review the java.lang.ref.Cleaner and tests following the
> recommendation to simplify the public
> interface to support only phantom cleanup.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-cleaner-8138696/
>
> Javadoc:
> http://
On 3 Dec 2015, at 15:58, Roger Riggs wrote:
> Hi Chris,
>
> Thanks for the review and comments:
>
> The webrev and javadoc have been updated.
>
> On 12/03/2015 08:55 AM, Chris Hegarty wrote:
>> On 2 Dec 2015, at 20:23, Roger Riggs wrote:
>>
>>> P
Tagir,
It would seem most useful to update the implementation to
match the current spec. To that end, your first patch looks
like the most appropriate change, pattern-patch.txt.
-Chris.
On 06/12/15 12:21, Tagir F. Valeev wrote:
Hello!
Currently Pattern.splitAsStream JavaDoc says [1]:
* If
102 * They are serializable if all elements are serializable.
To avoid any ambiguity or "leaking", would it make sense to
have the serial form of these types be defined, in a similar
manner to what was done for Serializable types in the
java.time package [1].
This can be done as a follow up,
On 07/12/15 13:55, Paul Sandoz wrote:
On 7 Dec 2015, at 11:18, Chris Hegarty wrote:
Tagir,
It would seem most useful to update the implementation to
match the current spec.
Yes, it’s an oversight and lacked a test for such case.
Tagir, thanks for finding this. Would it be possible for
Many threads created by the platform are short lived and perform some
simple async operation on behalf of the platform. These threads typically
use/extend sun.misc.ManagedLocalsThread. This is a convenient internal
API that can be used to create threads that do not wish to inherit initial
values fr
Thread is also very common.
-Chris.
> Roger
>
>
> On 12/08/2015 09:15 AM, Chris Hegarty wrote:
>> Many threads created by the platform are short lived and perform some
>> simple async operation on behalf of the platform. These threads typically
>> use/extend su
> On 8 Dec 2015, at 8:19 p.m., Mandy Chung wrote:
>
>
>> On Dec 8, 2015, at 6:50 AM, Chris Hegarty wrote:
>>
>>
>>> On 8 Dec 2015, at 14:33, Roger Riggs wrote:
>>> Adding an argument to the most flexible constructor of Thread bulks up
>>
Looks like the Compact Strings work inadvertently introduced a
dependency on sun.misc.Unsafe. ( just temporary confusion with
having two Unsafes until the jdk.unsupported module is defined )
diff --git a/src/java.base/share/classes/sun/nio/cs/StringUTF16.java
b/src/java.base/share/classes/sun/ni
Peter,
On 09/12/15 07:05, Peter Levart wrote:
Hi,
I think the only way to try to prevent such things is with a good
example in javadoc that "screams" of possible miss-usages.
public static class CleanerExample implements AutoCloseable {
private static final Cleaner cleaner = ...; //
thread-local values, then they can. As was said,
this will not be that commonly used.
I’ll finalise this as is, unless there are any objections.
-Chris.
On 9 Dec 2015, at 16:58, mark.reinh...@oracle.com wrote:
> 2015/12/8 5:36 -0800, david.hol...@oracle.com:
>> On 9/12/2015 12:15 AM, Chri
= null;
/* Speed the release of some of these resources */
threadLocals = null;
inheritableThreadLocals = null;
inheritedAccessControlContext = null;
blocker = null;
uncaughtExceptionHandler = null;
}
}
-Chris.
> On 12/08/2015 08:15 AM, Chris Hegarty wrote:
>&g
This looks good Stuart.
-Chris.
On 10 Dec 2015, at 00:22, Stuart Marks wrote:
> Hi all,
>
>
> Joe Darcy pointed out that API changes I pushed into jdk9-dev yesterday are
> missing wildcards from the Map.ofEntries() method. Please see this bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8
I received some comments from Paul offline about the test.
Updated webrev:
http://cr.openjdk.java.net/~chegar/8056152/01/webrev/
-Chris.
On 8 Dec 2015, at 14:15, Chris Hegarty wrote:
> Many threads created by the platform are short lived and perform some
> simple async operation on
sun.misc.HexDumpEncoder is an internal private API that is used almost
exclusively by the security library code. It should be moved out of sun.misc
and into a package more appropriate to its use, sun.security.util.
HexDumpEncoder extends CharacterEncoder, which is slated for later
removal, so the
On 10 Dec 2015, at 19:59, Mandy Chung wrote:
> On 12/10/2015 03:48 AM, Chris Hegarty wrote:
>> Updated webrev:
>> http://cr.openjdk.java.net/~chegar/8056152/01/webrev/
>
> Looks good.
Thanks Mandy.
> Nit:
> 687 * the specified stack size, and inherits initial valu
On 11 Dec 2015, at 11:17, Alan Bateman wrote:
> On 11/12/2015 09:24, Chris Hegarty wrote:
>> :
>>> Nit:
>>> 687 * the specified stack size, and inherits initial values for
>>> Not sure if italic font of stack size is intentional since this constructor
>
sun.misc.Request and RequestProcessor are not used by the JDK, and I can
find no usage outside the JDK either. I would like to propose their removal.
$ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java
$ hg rm src/java.base/share/classes/sun/misc/Request.java
-Chris.
ups later.
-Chris.
> Roger
>
>
> On 12/11/2015 11:30 AM, Chris Hegarty wrote:
>> sun.misc.Request and RequestProcessor are not used by the JDK, and I can
>> find no usage outside the JDK either. I would like to propose their removal.
>>
>>
More technical debt in sun.misc…
Java SE has had support for Queues in Collections for many major releases,
sun.misc.Queue seems to predate that. I cannot find any usages outside of the
JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to
provide the necessary minimum function
> On 12 Dec 2015, at 11:27 a.m., Peter Levart wrote:
>
> Hi Paul,
>
> Your latest code does not build with jdk9/dev as it uses
> @jdk.internal.vm.annotation.DontInline, but in jdk9/dev the @DontInline is
> still in java.lang.invoke.
>
> Is there a plan to push the move of DontInline annotat
ill never be reached, but
I accept your comment. Maybe add(E) is more appropriate? add()
either succeeds, or fails with IllegalStateException.
> then probably OOM(or something like that) will be better?
I don’t think OOM is quite right. Maybe ISE, as above is better?
-Chris.
> On 11/12/15 20
No new code here, just giving sun.misc.ProxyGenerator a more appropriate
location, in jdk.internal.reflect ( since it contains the code to generate a
dynamic
proxy class for the java.lang.reflect.Proxy ).
http://cr.openjdk.java.net/~chegar/proxyGeneratorWebrev/webrev/
Note: ProxyGenerator could
Chris.
> Roger
>
>
> On 12/15/2015 7:00 AM, Chris Hegarty wrote:
>> No new code here, just giving sun.misc.ProxyGenerator a more appropriate
>> location, in jdk.internal.reflect ( since it contains the code to generate a
>> dynamic
>> proxy c
Paul,
I cannot address your general question, but I guess it might be motivated
by some of my recent preparatory work for JEP 260 [1]. This JEP proposes
to expose a small number of critical API’s that are in the sun.misc and
sun.reflect namespace. Anything not deemed critical should be removed
fro
On 15 Dec 2015, at 17:15, Mandy Chung wrote:
>
>> On Dec 15, 2015, at 4:00 AM, Chris Hegarty wrote:
>>
>> No new code here, just giving sun.misc.ProxyGenerator a more appropriate
>> location, in jdk.internal.reflect ( since it contains the code to generate a
&g
On 15 Dec 2015, at 19:26, Mandy Chung wrote:
>> On Dec 15, 2015, at 10:41 AM, Chris Hegarty wrote:
>>
>>
>> Webrev updated in-place.
>
> Thank you for moving it to java.lang.reflect.
>
> Formatting nit: since you make generateProxyClass method package-pri
xying, libraries to
construct objects in a non-standard way.
-Chris.
cheers
/Joel
On Tue, 15 Dec 2015 at 16:15 Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:
Paul,
I cannot address your general question, but I guess it might be
motivated
by some of my recent prepa
The removal of BASE64Encoder, and a related types, in 8144479 [1]
has triggered the failure of java/beans/Introspector/Test6277246.java.
Another internal type should be used instead of sun.misc.BASE64Encoder.
The sun.security.x509 package seems stable, and is being used in other
areas, like langtoo
;
throw new Error((object != null) ? "test failure" : "test error”);
-Chris.
> Roger
>
>
> On 12/17/2015 9:46 AM, Chris Hegarty wrote:
>> The removal of BASE64Encoder, and a related types, in 8144479 [1]
>> has triggered the failur
For ease of review, I moved the complete changes into a webrev.
http://cr.openjdk.java.net/~chegar/8145589/webrev/
-Chris.
On 17 Dec 2015, at 15:08, Chris Hegarty wrote:
> On 17 Dec 2015, at 14:54, Roger Riggs wrote:
>
>> Hi Chris,
>>
>> Looks fine.
>
&g
Chris.
> On Wed, Dec 16, 2015 at 1:22 PM, Chris Hegarty
> wrote:
>> On 15/12/15 18:56, Joel Borggrén-Franck wrote:
>>>
>>> Hi Chris,
>>>
>>> I'm somewhat surprised to see ReflectionFactory on that list. Can you
>>> share more details a
Thanks for doing this Claes. The changes look good to me.
-Chris.
On 20/12/15 23:06, Claes Redestad wrote:
Hi all,
On 2015-12-20 20:43, Ulf wrote:
Hi Claes,
I had a very short look and found in j.l.Thread:
211 * Java thread status for tools, 0 indicate thread 'not yet
started'
I guess
There are 5 "math" related classes in the sun.misc package,
DoubleConsts, FDBigInteger, FloatConsts, FloatingDecimal, and
FormattedFloatingDecimal. They provide support for various standard
constants, and conversation/formatting utilities, etc. They are used
by the JDK in a few public packages, ja
Thanks for doing this Claes. The changes look good to me.
-Chris.
On 22 Dec 2015, at 13:40, Claes Redestad wrote:
> Hi,
>
> there are a number of cases where we check that the authority, query and
> fragment components of a URI is null. This simple patch changes some cases
> where we it's po
sun.misc.CompoundEnumeration is a utility class that supports enumerating
over an array of enumerations. It is used in just a single place in the JDK, in
ClassLoader.getResources(String) to support enumerating over the parent’s
resources as well as the current loaders resources. I can find no usage
On 22 Dec 2015, at 14:53, Aleksey Shipilev wrote:
> On 12/22/2015 05:41 PM, Chris Hegarty wrote:
>> sun.misc.CompoundEnumeration is a utility class that supports enumerating
>> over an array of enumerations. It is used in just a single place in the JDK,
>> in
>> Clas
On 22 Dec 2015, at 14:58, Aleksey Shipilev wrote:
> On 12/22/2015 05:57 PM, Chris Hegarty wrote:
>> http://cr.openjdk.java.net/~chegar/8146000/
>
> Looks good.
Thanks.
> Thanks,
> -Aleksey
>
> P.S. Nice bug ID, pity to waste it on a trivial thing :D
Right. I’m
Hi Roger,
On 22 Dec 2015, at 16:35, Roger Riggs wrote:
> Please review improvements to the CleanerTest to improve the reliability of
> the test.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-cleanertest-8146012/
The use of WhiteBox should make the test more reliable ( rather than
On 22 Dec 2015, at 16:13, Claes Redestad wrote:
> Hi,
>
> please review this patch to clean up and remove volatile from a number of
> lazily initialized fields in java.net.URI.
So ‘string’ is the only remaining volatile field. Is there any specific reason
for this?
> This is safe as long as
On 22 Dec 2015, at 17:14, Chris Hegarty wrote:
> On 22 Dec 2015, at 16:13, Claes Redestad wrote:
>
>> Hi,
>>
>> please review this patch to clean up and remove volatile from a number of
>> lazily initialized fields in java.net.URI.
>
> So ‘string’ is t
On 22 Dec 2015, at 17:40, Claes Redestad wrote:
> Hi!
>
> On 2015-12-22 18:16, Chris Hegarty wrote:
>> On 22 Dec 2015, at 17:14, Chris Hegarty wrote:
>>
>>> On 22 Dec 2015, at 16:13, Claes Redestad wrote:
>>>
>>>> Hi,
>>>>
>
Thanks for your reply Roger. I’m fine with the changes are they are.
-Chris.
On 22 Dec 2015, at 18:10, Roger Riggs wrote:
> Hi Chris,
>
> Thanks for the review
>
> On 12/22/2015 12:01 PM, Chris Hegarty wrote:
>> Hi Roger,
>>
>> On 22 Dec 2015, at
With the addition of a Thread constructor that can suppress the inheriting
of inheritable thread-local variable initial values from the constructing
thread [1], the usages of ManagedLocalsThread were removed from
the base module. ManagedLocalsThread was also removed from the
hierarchy of Innocuou
sun.misc.VM provides a low-level interface for a small number
of specific operations with the VM. In preparation for JEP 260,
this class should be moved out of sun.misc and located in a
non-exported package [.
http://cr.openjdk.java.net/~chegar/8145544/00/
Note: as in other areas some tests that
On 04/01/16 14:12, Sean Mullan wrote:
On 01/04/2016 09:02 AM, Chris Hegarty wrote:
sun.misc.VM provides a low-level interface for a small number
of specific operations with the VM. In preparation for JEP 260,
this class should be moved out of sun.misc and located in a
non-exported package
On 04/01/16 14:16, Alan Bateman wrote:
On 04/01/2016 14:02, Chris Hegarty wrote:
sun.misc.VM provides a low-level interface for a small number
of specific operations with the VM. In preparation for JEP 260,
this class should be moved out of sun.misc and located in a
non-exported package
On 5 Jan 2016, at 18:24, Roger Riggs wrote:
> The follow on work to adding the Cleaner is to replace uses of finalization
> with uses of the Cleaner.
> For the 'easy' cases in the java.base module, it is useful to introduce a
> private Cleaner for the
> java.base module. It is proposed to be
sun.misc.MessageUtils provides low-level access for writing “error” messages
to stdout and stderr. It is, effectively, used in just one place in the JDK,
String
coding, when the specific encoding is not available. Since this is the only
usage,
the minimal functionality required by String coding c
hanks,
> David
>
> On 5/01/2016 12:02 AM, Chris Hegarty wrote:
>> sun.misc.VM provides a low-level interface for a small number
>> of specific operations with the VM. In preparation for JEP 260,
>> this class should be moved out of sun.misc and located in a
>> no
On 06/01/16 10:12, Alan Bateman wrote:
On 06/01/2016 05:28, Chris Hegarty wrote:
sun.misc.MessageUtils provides low-level access for writing “error”
messages
to stdout and stderr. It is, effectively, used in just one place in
the JDK, String
coding, when the specific encoding is not available
Roger,
On 05/01/16 21:24, Roger Riggs wrote:
Hi Chris,
On 1/5/2016 2:33 PM, Chris Hegarty wrote:
On 5 Jan 2016, at 18:24, Roger Riggs wrote:
The follow on work to adding the Cleaner is to replace uses of finalization
with uses of the Cleaner.
For the 'easy' cases in the java.b
701 - 800 of 2214 matches
Mail list logo
