Hi,
I found regression in latest Java 8u40 b15 linux x64. There is missing
internal class in JDK. Submitted as bug with Review ID: 9048260.
Martin
StackTrace:
java.lang.NoClassDefFoundError: sun/management/ExtendedPlatformComponent
at
java.lang.management.ManagementFactory.getPlatfo
Thanks. From what I can tell, this one was specific to Oracle JDK builds
and has already been fixed for an upcoming 8u40 build.
-Alan
On 24/11/2014 09:19, Janda Martin wrote:
Hi,
I found regression in latest Java 8u40 b15 linux x64. There is missing
internal class in JDK. Submitted as
On 24/11/14 10:19, Janda Martin wrote:
Hi,
I found regression in latest Java 8u40 b15 linux x64. There is missing
internal class in JDK. Submitted as bug with Review ID: 9048260.
Hi Martin,
This should now have been fixed in the jdk8u-dev forest by
https://bugs.openjdk.java.net/browse/JDK
Thank you all for fast reply,
I didn't check properly bug tracking system for reported/fixed issues.
I'm sorry.
Martin
- Original Message -
From: "Daniel Fuchs"
To: "core-libs-dev"
Sent: Monday, November 24, 2014 10:32:48 AM
Subject: Re: Reg: NoClassDefFoundError: sun/managemen
Some test/tools/launcher tests have dependency on sun.tools.jar.Main
The dependency actually comes from TestHelper.java
This fix is to remove above internal JDK API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8060026
webrev: http://cr.openjdk.java.net/~weijun/8060026/
Hello Daniel,
Test seems like a great idea. Thanks!
/Erik
On 2014-11-20 18:25, Daniel Fuchs wrote:
On 20/11/14 14:36, Erik Joelsson wrote:
Here is my proposal for fixing the particular issue of generating the
correct properties files. I'm simply adding LC_ALL=C to the whole
command line inste
On Nov 20, 2014, at 4:33 PM, Peter Levart wrote:
> Hi Martin,
>
> On 11/19/2014 01:42 AM, Martin Buchholz wrote:
>> Hi Joe, Peter, Paul
>>
>> This is the followup on thread safety I promised Peter.
>
> Looks good.
>
Same here.
> I made the WildcardTypeImpl.[upperBoundASTs, lowerBoundASTs]
On 24/11/14 11:44, Erik Joelsson wrote:
Hello Daniel,
Test seems like a great idea. Thanks!
OK - I have logged JDK-8065748
https://bugs.openjdk.java.net/browse/JDK-8065748
I'll send a patch for review when your fix is in :-)
Thanks!
-- daniel
/Erik
On 2014-11-20 18:25, Daniel Fuchs wrote
On Nov 19, 2014, at 11:24 AM, Vladimir Ivanov
wrote:
> Aleksey, Duncan, thanks for the review and the confirmation that it doesn't
> break stuff for you.
>
> Any Reviews, please? :-)
>
Looks good.
> Best regards,
> Vladimir Ivanov
>
> On 11/19/14, 2:23 PM, MacGregor, Duncan (GE Energy Man
On Nov 24, 2014, at 10:47 AM, Amy Lu wrote:
> Some test/tools/launcher tests have dependency on sun.tools.jar.Main
> The dependency actually comes from TestHelper.java
> This fix is to remove above internal JDK API dependency from the tests.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-806
Hi,
Please find below a small webrev that adds a trivial sanity
test to CheckEncodingPropertiesFile.java
http://cr.openjdk.java.net/~dfuchs/webrev_8065748/webrev.00
This is as a followup of Joel's fix for
https://bugs.openjdk.java.net/browse/JDK-8065138
best regards,
-- daniel
On 24/11/2014 09:47, Amy Lu wrote:
Some test/tools/launcher tests have dependency on sun.tools.jar.Main
The dependency actually comes from TestHelper.java
This fix is to remove above internal JDK API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8060026
webrev: http://
Hi Patrick,
To speed things along for now i recommend creating a new class say IOUtils or
preferably ByteStreams.
You should keep things simple for an initial iteration and just add one static
method :-) which is essentially a refined copy of the private method that Pavel
pointed out. Then wr
Hi,
> On 20 Nov 2014, at 16:33, Peter Levart wrote:
>
> Hi Martin,
>
> On 11/19/2014 01:42 AM, Martin Buchholz wrote:
>> Hi Joe, Peter, Paul
>>
>> This is the followup on thread safety I promised Peter.
>
> Looks good.
+1
>
> I made the WildcardTypeImpl.[upperBoundASTs, lowerBoundASTs] an
On 11/24/2014 04:04 PM, Joel Borggrén-Franck wrote:
Hi,
On 20 Nov 2014, at 16:33, Peter Levart wrote:
Hi Martin,
On 11/19/2014 01:42 AM, Martin Buchholz wrote:
Hi Joe, Peter, Paul
This is the followup on thread safety I promised Peter.
Looks good.
+1
I made the WildcardTypeImpl.[upper
Paul, I wouldn't name it 'ByteStreams' because of the possible subjective
associations (and confusion) with java.util.stream.IntStream,
java.util.stream.LongStream, etc.
IOStreams?
-Pavel
> On 24 Nov 2014, at 14:32, Paul Sandoz wrote:
>
> i recommend creating a new class say IOUtils or prefer
Looks good.
Best regards,
Vladimir Ivanov
On 11/19/14, 3:12 PM, Konstantin Shefov wrote:
Hello, Vladimir
I have updated the Webrev
http://cr.openjdk.java.net/~kshefov/8059070/webrev.02
I have added DEFAULT_TEST_TIMEOUT constant to Utils class.
-Konstantin
On 13.11.2014 15:48, Konstantin Shef
Hi Paul,
> Am 24.11.2014 um 15:32 schrieb Paul Sandoz :
>
> Hi Patrick,
>
> To speed things along for now i recommend creating a new class say IOUtils or
> preferably ByteStreams.
Hmm, in the case of Reader/Writer ByteStreams seams to be a bit confusing for
me, should then the reader copy st
Hi all,
I'm sure everyone is very busy, but is there any chance that someone take a
look at the latest iteration of this patch?
Thanks for taking the time to look at this - most appreciated. I've pushed
the latest iteration to http://cr.openjdk.java.net/~
rwarburton/string-patch-webrev-
On Nov 24, 2014, at 5:34 PM, Patrick Reinhart wrote:
> Hi Paul,
>
>> Am 24.11.2014 um 15:32 schrieb Paul Sandoz :
>>
>> Hi Patrick,
>>
>> To speed things along for now i recommend creating a new class say IOUtils
>> or preferably ByteStreams.
>
> Hmm, in the case of Reader/Writer ByteStrea
Well I will then suggest using IOUtils with two simple methods:
public static long copy(InputStream source, OutputStream target)
public static long copy(Readable source, Appendable target)
>>>
>>> To speed things along for now i recommend creating a new class say IOUtils
>>> or preferably Byt
Hi Daniel,
Would you want to add 8065748 to the @bug tag? Otherwise, the test
looks good to me.
Best,
Joe
On 11/24/2014 3:30 AM, Daniel Fuchs wrote:
Hi,
Please find below a small webrev that adds a trivial sanity
test to CheckEncodingPropertiesFile.java
http://cr.openjdk.java.net/~dfuchs/
On 24/11/14 18:04, huizhe wang wrote:
Hi Daniel,
Would you want to add 8065748 to the @bug tag? Otherwise, the test
looks good to me.
Hi Joe,
I don't think adding 8065748 would be a good idea - since the test
doesn't test 8065748 (8065748 is about adding the test :-)).
Or am I mistaken on t
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs "@throw UEE".
(2) It should be "default replacement byte array" not "replace string" for all
getBytes() methods when malformed/unmappable
(3) for decoding (new String) from ByteBuffer, sinc
On 11/24/2014 9:12 AM, Daniel Fuchs wrote:
On 24/11/14 18:04, huizhe wang wrote:
Hi Daniel,
Would you want to add 8065748 to the @bug tag? Otherwise, the test
looks good to me.
Hi Joe,
I don't think adding 8065748 would be a good idea - since the test
doesn't test 8065748 (8065748 is about
> On 24 Nov 2014, at 16:36, Peter Levart wrote:
>
> On 11/24/2014 04:04 PM, Joel Borggrén-Franck wrote:
>>
>> Btw, has anyone seen the assert for upper/lower bounds == null fail in the
>> wild?
>>
>> private FieldTypeSignature[] getUpperBoundASTs() {
>> // check that upper bounds were not
Hi,
This topic has languished for a bit and could use a bit of expertise from
Windows developers.
The improvements in entropy for initializing Secure Random in JDK 8 have
some negative attributes that affect maintainability, robustness and
performance[1].
The dependency on networking, can in s
Hi folks,
Review carefully - I am trying to learn about fences by explaining them!
I have borrowed some wording from my reviewers!
https://bugs.openjdk.java.net/browse/JDK-8065804
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/
On 24/11/2014 18:41, Xueming Shen wrote:
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs "@throw UEE".
(2) It should be "default replacement byte array" not "replace string"
for all
getBytes() methods when malformed/unmappable
(3) for
Hi Martin,
On 11/24/2014 11:56 PM, Martin Buchholz wrote:
> Review carefully - I am trying to learn about fences by explaining them!
> I have borrowed some wording from my reviewers!
>
> https://bugs.openjdk.java.net/browse/JDK-8065804
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-i
On 11/24/2014 01:21 PM, Alan Bateman wrote:
On 24/11/2014 18:41, Xueming Shen wrote:
Hi Richard,
Here are some comments regarding the updated webrev.
(1) String(ByteBuffer, String) needs "@throw UEE".
(2) It should be "default replacement byte array" not "replace string" for all
getBytes(
Hello,
Crypto API (as used by NativeRandom on windows with SubMSCAPI) would be
the right thing to use for a secure high entropy source (and this is
actually what is used if you ask SecureRandom for seed bytes). But I
guess this is not at all expected/needed for TLR.
Having all platform launchers
On Mon, Nov 24, 2014 at 2:36 PM, Bernd Eckenfels wrote:
> Hello,
> BTW2: I am not sure, it this seeded per thread? then using getSeed()
> is probably even worse.
No. ThreadLocalRandom and SplittableRandom each need 8 seed bytes per
JVM startup.
Looks good.
Kumar
On 11/24/2014 1:47 AM, Amy Lu wrote:
Some test/tools/launcher tests have dependency on sun.tools.jar.Main
The dependency actually comes from TestHelper.java
This fix is to remove above internal JDK API dependency from the tests.
bug: https://bugs.openjdk.java.net/browse/JDK-8
OK, I worked in some wording for comparison with volatiles.
I believe you when you say that the semantics of the corresponding C++
fences are slightly different, but it's rather subtle - can we say
anything more than "closely related to"?
On Mon, Nov 24, 2014 at 1:29 PM, Aleksey Shipilev
wrote:
>
I tried to address all the known problems in sun/reflect (except for
the performance ones), including the ones in Peter's webrev (although
it now looks quite different).
I broke down and switched to using AtomicReferenceFieldUpdaters for
all lazily initialized operations,
like I had been thinking
Hi all,
Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
policy for rmid processes that are started by RMI's test library in support of a
few dozen of the RMI activation tests. The previous implementation was, well,
confused, and it had a redundant timing loop th
37 matches
Mail list logo
