RFR(s): 8035000: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead

[Stuart Marks]

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 that can be subsumed by other code 
in RMI's test library (JavaVM.waitFor).


I've listed this as a "small" changeset even though lots of files have changed. 
In all but three or so of the files, the only change is from calling 
"ActivationLibrary.rmidCleanup(rmid)" to calling "rmid.cleanup()" which is a 
refactoring enabled by the cleanup. The real action is in the files 
test/java/rmi/testlibrary/ActivationLibrary.java and RMID.java.


Webrev:

http://cr.openjdk.java.net/~smarks/reviews/8035000/webrev.0/

Bug:

https://bugs.openjdk.java.net/browse/JDK-8035000

Thanks,

s'marks

Re: RFR: 8065172: More core reflection final and volatile annotations

[Martin Buchholz]

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 of doing.

For the weird classes where we need to lazily switch the
implementation of bounds, I store in an Object[] and cas to update.

Now that we're using atomic updaters, it's hard to have any relaxed
operations unless we also introduce Unsafe.  My current thinking is
this code is not performance critical enough to do that sort of
brittle thing.  Volatile reads are either already very cheap or are
likely to get cheaper over time.  The code using updaters seems
robust, efficient, and deadlock free, unlike some other code in the
JDK.  Using updaters means there will never be an extremely rare bug
due to different objects being returned from a reflection method.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/

On Mon, Nov 24, 2014 at 12:25 PM, Joel Borggrén-Franck
 wrote:
>
>> 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 evaluated yet
>>> assert(upperBounds == null);
>>> return upperBoundASTs;
>>> }
>>>
>>> shouldn’t it happen once in a while:
>>>
>>> public Type[] getUpperBounds() {
>>> // lazily initialize bounds if necessary
>>> if (upperBounds == null) {
>>>
>>>  // thread gets preempted here, other thread completes init, 
>>> upperBounds are != null
>>>
>>> FieldTypeSignature[] fts = getUpperBoundASTs(); // get AST
>>>
>>>
>>> Is the current code only working because most run without esa?
>>
>> ...or because races that would trigger this are very rare, since two 
>> consecutive "loads" of upperBounds happen one after the other, so the 2nd 
>> load and check might even be optimized away.
>>
>
> I was thinking along the lines of warming up in the interpreter + large 
> search engine infrastructure scale.
>
> cheers
> /Joel

Re: RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[Martin Buchholz]

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:
> 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-intrinsics/
>
> I think "implies the effect of C++11" is too strong wording. "related"
> might be more appropriate.
>
> See also comments here for connection with "volatiles":
>  https://bugs.openjdk.java.net/browse/JDK-8038978
>
> Take note the Hans' correction that fences generally imply more than
> volatile load/store, but since you are listing the related things in the
> docs, I think the "native" Java example is good to have.
>
> -Aleksey.
>
>

Re: RFR 8060026: Update test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main

[Kumar Srinivasan]

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-8060026
webrev: http://cr.openjdk.java.net/~weijun/8060026/webrev.00/

Thanks,
Amy

Re: Initializing Secure Random (Reprise)

[Martin Buchholz]

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.

Re: Initializing Secure Random (Reprise)

[Bernd Eckenfels]

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 generate a random
process startup uuid would be so usefull, not only be the seeder for
the TLR. Maybe there should be some bootstrap code to do this once (and
without too much subsystem dependencies). This could even uses stuff
like libuuid on Linux or UuidCreate from rpcrt.dll on Windows.

Mixing this "JVM instance UUID" with PID and Timestamp -> good enough
TLR.

BTW: It was probably not a good idea to make SecureRandom.getSeed() so
easily accessible... if you think TLR needs a good random source, you
should at least allow the SecureRandom instance to use urandom and SHA1
mixing. Both is present with getInstance().getBytes() (but its probably
also not faster in the bug-specific test as the SecureRandom will be
seeded once at this point).

BTW2: I am not sure, it this seeded per thread? then using getSeed()
is probably even worse.

Re: Lower overhead String encoding/decoding

[Xueming Shen]

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() methods when malformed/unmappable
(3) for decoding (new String) from ByteBuffer, since it is guaranteed that all
 bytes in the input ByteBuffer will be decoded, it might be desirable to 
clearly
 specify that the position of the buffer will be "advanced to its limit" ?
(4) ln#1137 has an extra "*"
(5) StringCoding.decode(cs, bb), why do you want to allocate a direct buffer
 here for "untrusted"? Basically the output buffer "ca" will always be a 
wrapper
 of a char[], all our charset implementation will have better performance if
 both input and output are "array based" (decode on array directly, instead 
of
 the "slow" ByteBuffer)

Overall I think this is looking quite good and I think Sherman has captured the main 
issues. On #3 then wording such as ".. the position will be updated" isn't 
clear enough to allow the method be tested, it needs to make it clear that the position 
is advanced by the number of bytes that were decoded.

Sherman - are you going to sponsor this for Richard?



Yes, I will sponsor this RFE.

-Sherman

Re: RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[Aleksey Shipilev]

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-intrinsics/

I think "implies the effect of C++11" is too strong wording. "related"
might be more appropriate.

See also comments here for connection with "volatiles":
 https://bugs.openjdk.java.net/browse/JDK-8038978

Take note the Hans' correction that fences generally imply more than
volatile load/store, but since you are listing the related things in the
docs, I think the "native" Java example is good to have.

-Aleksey.

Re: Lower overhead String encoding/decoding

[Alan Bateman]

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 decoding (new String) from ByteBuffer, since it is guaranteed 
that all
 bytes in the input ByteBuffer will be decoded, it might be 
desirable to clearly
 specify that the position of the buffer will be "advanced to its 
limit" ?

(4) ln#1137 has an extra "*"
(5) StringCoding.decode(cs, bb), why do you want to allocate a direct 
buffer
 here for "untrusted"? Basically the output buffer "ca" will 
always be a wrapper
 of a char[], all our charset implementation will have better 
performance if
 both input and output are "array based" (decode on array 
directly, instead of

 the "slow" ByteBuffer)
Overall I think this is looking quite good and I think Sherman has 
captured the main issues. On #3 then wording such as ".. the position 
will be updated" isn't clear enough to allow the method be tested, it 
needs to make it clear that the position is advanced by the number of 
bytes that were decoded.


Sherman - are you going to sponsor this for Richard?

-Alan

RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[Martin Buchholz]

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/

Initializing Secure Random (Reprise)

[roger riggs]

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 some OS's and configurations lead
to increased startup times and issues with bootstrapping the Java runtime.

Martin has proposed[2] an alternative for Linux based on /dev/urandom
with a fallback to a simpler algorithm if /dev/urandom is not available.

Since /dev/urandom is not native to Windows, it seems prudent to identify
a corresponding source of entropy data.

What are the recommended ways on Windows to get seeds for random?
Please suggest one or more ways to initialize SecureRandom

Thanks, Roger

p.s. Sorry to be covering old ground but I don't have all the context.


[1] 8060435  SecureRandom initialization latency on Windows
 https://bugs.openjdk.java.net/browse/JDK-8060435

[2] 
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ThreadLocalRandom-system-entropy/

Re: RFR: 8065172: More core reflection final and volatile annotations

[Joel Borggrén-Franck]

> 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 evaluated yet
>> assert(upperBounds == null);
>> return upperBoundASTs;
>> }
>> 
>> shouldn’t it happen once in a while:
>> 
>> public Type[] getUpperBounds() {
>> // lazily initialize bounds if necessary
>> if (upperBounds == null) {
>> 
>>  // thread gets preempted here, other thread completes init, upperBounds 
>> are != null
>> 
>> FieldTypeSignature[] fts = getUpperBoundASTs(); // get AST
>> 
>> 
>> Is the current code only working because most run without esa?
> 
> ...or because races that would trigger this are very rare, since two 
> consecutive "loads" of upperBounds happen one after the other, so the 2nd 
> load and check might even be optimized away.
> 

I was thinking along the lines of warming up in the interpreter + large search 
engine infrastructure scale.

cheers
/Joel

Re: RFR: 8065748 - Add a test to verify that non ascii characters in Encodings.properties do not cause issues

[huizhe wang]

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 adding the test :-)).

Or am I mistaken on the meaning of @bug ?


These tags (bug, summary, author and etc.) are informational tags. For 
me, I use them to locate tests or corresponding bug reports. In this 
case, since there's a reference to 8065138, it's okay if you don't want 
to add it.


Best,
Joe



best regards,

-- daniel



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/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

Re: Lower overhead String encoding/decoding

[Xueming Shen]

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, since it is guaranteed that all
 bytes in the input ByteBuffer will be decoded, it might be desirable to 
clearly
 specify that the position of the buffer will be "advanced to its limit" ?
(4) ln#1137 has an extra "*"
(5) StringCoding.decode(cs, bb), why do you want to allocate a direct buffer
 here for "untrusted"? Basically the output buffer "ca" will always be a 
wrapper
 of a char[], all our charset implementation will have better performance if
 both input and output are "array based" (decode on array directly, instead 
of
 the "slow" ByteBuffer)

-Sherman

On 11/24/2014 08:45 AM, Richard Warburton wrote:

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-8/.

  I think this is looking good.

Thanks - I've pushed a new iteration to http://cr.openjdk.java.net/~
rwarburton/string-patch-webrev-9.

For the constructor then the words "decoding the specified byte buffer",

it might be a bit clearer as "decoding the remaining bytes in the ...".

For getBytes(ByteBuffer, Charset) then the position is advanced by the
bytes written, no need to mention the number of chars read here.

In the constructor then you make it clear that malformed/unmappable
sequences use the default replacement. This is important to state in the
getBytes methods too because the encoding can fail.



I've made all these changes.

Hi Richard, hi all,

Two comments,
You replace the nullcheck in getBytes() by a requireNonNull and at the
same time, you don"t use requireNonNull in String(ByteBuffer,Charset),
no very logical isn't it ?


Thanks for spotting this Remi - I've fixed this issue in my latest
iteration.

I think you need a supplementary constructor that takes a ByteBuffer and a

charset name as a String,
i may be wrong, but it seems that every constructor of String that takes
a Charset has a dual constructor that takes a Charset as a String.
As far as I remember, a constructor that takes a Charset as a String may
be faster because you can share the character decoder
instead of creating a new one.


A good observation. I've added variants which take a String for the
charset name as well the charset variants.

Having said that - wouldn't it also be a good idea to replicate the
caching on the charset versions as well as the charset name? I don't see
any obvious reason why this isn't possible but perhaps there's something
I'm missing here. Probably cleaner as a separate patch either way.


regards,

   Richard Warburton

   http://insightfullogic.com
   @RichardWarburto

Re: RFR: 8065748 - Add a test to verify that non ascii characters in Encodings.properties do not cause issues

[Daniel Fuchs]

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 the meaning of @bug ?

best regards,

-- daniel



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/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

Re: RFR: 8065748 - Add a test to verify that non ascii characters in Encodings.properties do not cause issues

[huizhe wang]

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/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

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Patrick Reinhart]

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 ByteStreams. 
>> 
>> Hmm, in the case of Reader/Writer ByteStreams seams to be a bit confusing 
>> for me, should then the reader copy stuff go to also a separate class like 
>> „CharStreams“. Locally I created an implementation named „IOUtils“ 
>> containing a copy method for InputStream to OutputStream.
>> 
> 
> Pick the one you prefer so we don't rat hole down the naming abyss :-)
> 
> Pavel, your point about the overload with j.u.stream.Stream is a reasonable 
> one (I am not too concerned by it myself). I hope one day in the future we 
> can have Stream :-)
> 
> Paul.

Patrick

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Paul Sandoz]

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 ByteStreams seams to be a bit confusing for 
> me, should then the reader copy stuff go to also a separate class like 
> „CharStreams“. Locally I created an implementation named „IOUtils“ containing 
> a copy method for InputStream to OutputStream.
> 

Pick the one you prefer so we don't rat hole down the naming abyss :-)

Pavel, your point about the overload with j.u.stream.Stream is a reasonable one 
(I am not too concerned by it myself). I hope one day in the future we can have 
Stream :-)

Paul.

Re: Lower overhead String encoding/decoding

[Richard Warburton]

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-8/ .

  I think this is looking good.
>>>
>>
> Thanks - I've pushed a new iteration to http://cr.openjdk.java.net/~
> rwarburton/string-patch-webrev-9.
>
> For the constructor then the words "decoding the specified byte buffer",
>>> it might be a bit clearer as "decoding the remaining bytes in the ...".
>>>
>>> For getBytes(ByteBuffer, Charset) then the position is advanced by the
>>> bytes written, no need to mention the number of chars read here.
>>>
>>> In the constructor then you make it clear that malformed/unmappable
>>> sequences use the default replacement. This is important to state in the
>>> getBytes methods too because the encoding can fail.
>>
>>
> I've made all these changes.
>
> Hi Richard, hi all,
>> Two comments,
>> You replace the nullcheck in getBytes() by a requireNonNull and at the
>> same time, you don"t use requireNonNull in String(ByteBuffer,Charset),
>> no very logical isn't it ?
>>
>
> Thanks for spotting this Remi - I've fixed this issue in my latest
> iteration.
>
> I think you need a supplementary constructor that takes a ByteBuffer and a
>> charset name as a String,
>> i may be wrong, but it seems that every constructor of String that takes
>> a Charset has a dual constructor that takes a Charset as a String.
>> As far as I remember, a constructor that takes a Charset as a String may
>> be faster because you can share the character decoder
>> instead of creating a new one.
>
>
> A good observation. I've added variants which take a String for the
> charset name as well the charset variants.
>
> Having said that - wouldn't it also be a good idea to replicate the
> caching on the charset versions as well as the charset name? I don't see
> any obvious reason why this isn't possible but perhaps there's something
> I'm missing here. Probably cleaner as a separate patch either way.
>

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto 

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Patrick Reinhart]

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 stuff go to also a separate class like 
„CharStreams“. Locally I created an implementation named „IOUtils“ containing a 
copy method for InputStream to OutputStream.

> 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 write some tests for that method [1]. Then 
> consider any nio related classes for an equivalent copy method. Some other 
> candidates to consider are on Guava's ByteStreams class:
> 
>  
> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/ByteStreams.html

I will also take a look at this

> It's very easy to get carried away and over-engineer such utility methods 
> thinking they need to be all things to all people so we need to consider them 
> carefully and i think the ones you included with size and reporting are not 
> required. Simply just one static method copying input to output will go a 
> long way (i have lost count of how many times i have reimplemented that!).

For now a single copy(from, to) for Input-/OutputStream and Readable/Appendable 
would be perfect for now.

> Hth,
> Paul.
> 
> [1] You can download jtreg from here:
> 
>  https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/jtreg/
> 
> for executing JDK tests. Depending on how you want to write your tests you 
> can also make ‚em run standalone too, but sometimes it is easier convenient 
> to use testng and execute via jtreg.

The environment I will update in the next.

Patrick

Re: [9] Review request : JDK-8059070: [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout

[Vladimir Ivanov]

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 Shefov wrote:

Kindly reminder.

On 10.11.2014 17:45, Konstantin Shefov wrote:

Vladimir, thanks for reviewing

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 10.11.2014 14:33, Vladimir Ivanov wrote:

Kontantin, sorry for the late response.

In general, the fix looks good.

I'd move timeout computation logic to Utils:
+private static final long TIMEOUT =
Utils.adjustTimeout(TimeUnit.SECONDS.toMillis(120));

Default value (120s) isn't specific to the tests, but an
implementation detail of jtreg.

Best regards,
Vladimir Ivanov

On 11/7/14, 2:22 PM, Konstantin Shefov wrote:

Gently reminder

29.10.2014 17:25, Konstantin Shefov пишет:

Please, review a test bug fix.
http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/

-Konstantin

On 27.10.2014 13:16, Konstantin Shefov wrote:

Kindly reminder

On 23.10.2014 19:04, Paul Sandoz wrote:

On Oct 23, 2014, at 1:25 PM, Konstantin Shefov
 wrote:

Gently reminder

On 17.10.2014 13:38, Konstantin Shefov wrote:

Hi,

I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/


+1

Sorry for the delay,
Paul.

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Pavel Rappo]

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 preferably ByteStreams.

Re: RFR: 8065172: More core reflection final and volatile annotations

[Peter Levart]

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.[upperBoundASTs, lowerBoundASTs] and 
TypeVariableImpl.boundASTs fields volatile in my version of patch (instead of 
final):

http://cr.openjdk.java.net/~plevart/jdk9-dev/GenericsReflectionRaces/webrev.01/

...so that after the structure they point to has been parsed into bound types, 
they can be thrown away. The comments indicate that possibility already, but 
the implementor was afraid to do it because of possible races. I think I got it 
right here.



As a cleanup and given the current state of testing here, I slightly favour 
Martin’s version because it should just make the current behaviour a bit safer.

Btw, has anyone seen the assert for upper/lower bounds == null fail in the wild?

private FieldTypeSignature[] getUpperBoundASTs() {
 // check that upper bounds were not evaluated yet
 assert(upperBounds == null);
 return upperBoundASTs;
}

shouldn’t it happen once in a while:

public Type[] getUpperBounds() {
 // lazily initialize bounds if necessary
 if (upperBounds == null) {

// thread gets preempted here, other thread completes init, upperBounds 
are != null

 FieldTypeSignature[] fts = getUpperBoundASTs(); // get AST


Is the current code only working because most run without esa?


...or because races that would trigger this are very rare, since two 
consecutive "loads" of upperBounds happen one after the other, so the 
2nd load and check might even be optimized away.


The private getter for a private field is meaningless in my opinion. 
That's why I removed it in my version of the patch.


Regards, Peter



cheers
/Joel

Re: RFR: 8065172: More core reflection final and volatile annotations

[Joel Borggrén-Franck]

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] and 
> TypeVariableImpl.boundASTs fields volatile in my version of patch (instead of 
> final):
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/GenericsReflectionRaces/webrev.01/
> 
> ...so that after the structure they point to has been parsed into bound 
> types, they can be thrown away. The comments indicate that possibility 
> already, but the implementor was afraid to do it because of possible races. I 
> think I got it right here.
> 


As a cleanup and given the current state of testing here, I slightly favour 
Martin’s version because it should just make the current behaviour a bit safer.

Btw, has anyone seen the assert for upper/lower bounds == null fail in the wild?

private FieldTypeSignature[] getUpperBoundASTs() {
// check that upper bounds were not evaluated yet
assert(upperBounds == null);
return upperBoundASTs;
}

shouldn’t it happen once in a while:

public Type[] getUpperBounds() {
// lazily initialize bounds if necessary
if (upperBounds == null) {

// thread gets preempted here, other thread completes init, upperBounds 
are != null

FieldTypeSignature[] fts = getUpperBoundASTs(); // get AST


Is the current code only working because most run without esa?

cheers
/Joel

Re: Library enhancement proposal for copying data from/to Reader/Writer InputStream/OutputStream

[Paul Sandoz]

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 write some tests for that method [1]. Then consider any nio 
related classes for an equivalent copy method. Some other candidates to 
consider are on Guava's ByteStreams class:

  
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/ByteStreams.html

It's very easy to get carried away and over-engineer such utility methods 
thinking they need to be all things to all people so we need to consider them 
carefully and i think the ones you included with size and reporting are not 
required. Simply just one static method copying input to output will go a long 
way (i have lost count of how many times i have reimplemented that!).

Hth,
Paul.

[1] You can download jtreg from here:

  https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/jtreg/

for executing JDK tests. Depending on how you want to write your tests you can 
also make 'em run standalone too, but sometimes it is easier convenient to use 
testng and execute via jtreg.


On Nov 21, 2014, at 3:12 PM, Patrick Reinhart  wrote:

> 
>> Am 21.11.2014 um 09:36 schrieb Alan Bateman :
>> 
>> On 21/11/2014 03:05, Stuart Marks wrote:
>>> 
>>> Thanks to Pavel for pointing out the existing copy operations in the nio 
>>> Files class. I think there's a case for the InputStream => OutputStream 
>>> copy method to be placed there too, although I admit it is somewhat unusual 
>>> in that it doesn't actually have anything to do with files.
>>> 
>>> At my first encounter with the nio.Files class some years ago I saw the 
>>> following copying methods:
>>> 
>>>   copy(istream, targetfile)
>>>   copy(sourcefile, ostream)
>>>   copy(sourcefile, targetfile)
>>> 
>>> and I immediately thought, "Where is copy(istream, ostream)?" So to me at 
>>> least, it makes more sense to be in the Files class than in some newly 
>>> created IOUtils class. (I'd like to hear further from Alan on this.)
>>> 
>>> As Pavel pointed out, the logic is also already there in the Files class. 
>>> Probably the way to proceed would be to rename the existing (private) 
>>> method to be something like copyInternal() and then create a new, public 
>>> copy(istream, ostream) method that does argument checking before calling 
>>> copyInternal().
>> 
>> The Files class works on files, it's not the right place for a general 
>> purpose copy(InputStream, OutputStream).
> 
> That was the reason in my proposal to not put those methods on the Files 
> class. I also would not try to find such methods there. Personally I tried to 
> look for such method on „Streams“ ;-)
> 
>> When we prototyped a copy(InputStream, OutputStream) and many other I/O 
>> methods a few years ago then the intention was to put it java.io. One option 
>> on the table was a Collections-like utility class with static methods. 
>> Another option was to add methods to InputStream, Reader, etc. A concern 
>> with the latter was whether the new methods would cause problems for 
>> existing InputStream/etc. implementations, similar to concerns about adding 
>> default methods to the collection types in 8. I think that discussion needs 
>> to happen again and having a few prototypes to get experience with the 
>> various approaches would be good too.
>> 
>> -Alan
> 
> It would be good to have such methods in the next release and I would love to 
> help here.
> 
> Patrick

Re: RFR 8060026: Update test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main

[Alan Bateman]

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://cr.openjdk.java.net/~weijun/8060026/webrev.00/


This looks okay to me, I'm sure Kumar will want to look at this too.

-Alan

RFR: 8065748 - Add a test to verify that non ascii characters in Encodings.properties do not cause issues

[Daniel Fuchs]

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

Re: RFR 8060026: Update test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main

[Paul Sandoz]

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-8060026
> webrev: http://cr.openjdk.java.net/~weijun/8060026/webrev.00/
> 

Looks ok to me,
Paul.

Re: [9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation

[Paul Sandoz]

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 Management) wrote:
>> On 18/11/2014 23:33, "Aleksey Shipilev" 
>> wrote:
>>> On 11/19/2014 12:01 AM, Vladimir Ivanov wrote:
 http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8059880
>>> 
>>> Yes, for the love of God, GO FOR IT.
>> 

Indeed!

Paul.

>> Seconded. Startup of our stuff seems fine now with a compile threshold of
>> zero, and it will make stacks so much easier to read in the debugger. :-)
>> 
>> ___
>> mlvm-dev mailing list
>> mlvm-...@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
> ___
> mlvm-dev mailing list
> mlvm-...@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

[Daniel Fuchs]

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 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 instead of just the sort at the end. It seems to require
using "export" to get picked up.


Hi Erik,

Looks good to me.

I have applied your patch (manually, because the copy/paste
seems to have eaten the tab characters away, which caused patch to
reject the diff) - and I confirm that the issue has disappeared.

Thanks for solving this!

Do you think it would be worth to commit this test modification
later on, in a followup Bug/RFE?

http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html


If so I will take care of it.

best regards,

-- daniel



Bug: https://bugs.openjdk.java.net/browse/JDK-8065138
Patch:
diff --git a/make/common/JavaCompilation.gmk
b/make/common/JavaCompilation.gmk
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -400,13 +400,15 @@
# Now we can setup the depency that will trigger the copying.
$$($1_BIN)$$($2_TARGET) : $2
  $(MKDIR) -p $$(@D)
-$(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e
's/\([^\\]\)=/\1\\=/g' \
+export LC_ALL=C ; $(CAT) $$< \
+| $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \
  -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \
  | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
  | $(SED) -e '/^#/d' -e '/^/d' \
  -e :a -e '/\\/N; s/\\\n//; ta' \
  -e 's/^[ ]*//;s/[ ]*//' \
--e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
+-e 's/\\=/=/' \
+| $(SORT) > $$@
  $(CHMOD) -f ug+w $$@

# And do not forget this target


I filed a separate issue [1] for investigating the use of pipefail.

/Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8065576

On 2014-11-20 10:34, Daniel Fuchs wrote:

On 11/20/14 10:26 AM, Erik Joelsson wrote:

Hello,

On 2014-11-20 02:20, Martin Buchholz wrote:

Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it,
but
the $(SED)s need it too!

Yes, I think that's the correct fix in this case.

On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz
 wrote:

[+ build-dev]

I think I see the problem.  By default, a Unix pipeline sadly fails
only when the last command fails.  In bash, you can change this to a
more sensible default via
set -o pipefail
but that's not portable enough for openjdk.

This is interesting and something I had missed. I will experiment
with enabling pipefail if configure finds support for it. This will
include setting the SHELL to bash. We really should fail instead of
silently generating broken builds.

Daniel, I can take over this bug if you want and work on a proper
build fix.


Thanks Erik! You are welcome!
So the whole issue seems to be that my default setting is
LC_ALL=en_US.UTF-8
whereas sed requires LC_ALL=C to work properly on these property
files...

When the test first failed I tried to rerun the test with LC_ALL=C -
with no success
of course. But I never thought of rebuilding with LC_ALL=C :-(

My apologies for the red herring :-(

best regards

-- daniel



/Erik

$(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e
's/\([^\\]\)=/\1\\=/g' \
-e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \
| $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
| $(SED) -e '/^#/d' -e '/^/d' \
-e :a -e '/\\/N; s/\\\n//; ta' \
-e 's/^[ ]*//;s/[ ]*//' \
-e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@

On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang
 wrote:

On 11/19/2014 4:09 PM, Mandy Chung wrote:


On 11/19/2014 3:49 PM, Mandy Chung wrote:


On 11/19/2014 12:50 PM, Daniel Fuchs wrote:

On 11/19/14 9:36 PM, Mandy Chung wrote:

resources.jar will be gone when we move to the modular runtime
image
(JEP 220 [1]).
JDK-8065138 and JDK-8065365 will become non-issue in JDK 9.

Do you mean that the property files will no longer be stripped
of their
comments?


(sorry for my delay in reply as I was trying to get the number
of the
resources in the modular image vs resources.jar but got
distracted.)

The current version copies all bytes when generating the modular
image.
This is a good question whether we should strip off the comments
when
writing to the modular runtime image.   I think we should look
at the
footprint and any performance saving and determine if we should
do the same
in JDK 9.


I looked at the exploded image under
BUILD_OUTPUTDIR/jdk/modules/java.xml
and found that the comments of Encodings.properties are stripped.
I was
confused with the mention of re

Re: RFR: 8065172: More core reflection final and volatile annotations

[Paul Sandoz]

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] and 
> TypeVariableImpl.boundASTs fields volatile in my version of patch (instead of 
> final):
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/GenericsReflectionRaces/webrev.01/
> 
> ...so that after the structure they point to has been parsed into bound 
> types, they can be thrown away. The comments indicate that possibility 
> already, but the implementor was afraid to do it because of possible races. I 
> think I got it right here.
> 

I think so too.

Paul.

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

[Erik Joelsson]

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 instead of just the sort at the end. It seems to require
using "export" to get picked up.


Hi Erik,

Looks good to me.

I have applied your patch (manually, because the copy/paste
seems to have eaten the tab characters away, which caused patch to
reject the diff) - and I confirm that the issue has disappeared.

Thanks for solving this!

Do you think it would be worth to commit this test modification
later on, in a followup Bug/RFE?

http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/jdk/test/javax/xml/jaxp/Encodings/CheckEncodingPropertiesFile.java.frames.html 



If so I will take care of it.

best regards,

-- daniel



Bug: https://bugs.openjdk.java.net/browse/JDK-8065138
Patch:
diff --git a/make/common/JavaCompilation.gmk
b/make/common/JavaCompilation.gmk
--- a/make/common/JavaCompilation.gmk
+++ b/make/common/JavaCompilation.gmk
@@ -400,13 +400,15 @@
# Now we can setup the depency that will trigger the copying.
$$($1_BIN)$$($2_TARGET) : $2
  $(MKDIR) -p $$(@D)
-$(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e
's/\([^\\]\)=/\1\\=/g' \
+export LC_ALL=C ; $(CAT) $$< \
+| $(SED) -e 's/\([^\\]\):/\1\\:/g' -e 's/\([^\\]\)=/\1\\=/g' \
  -e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \
  | $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
  | $(SED) -e '/^#/d' -e '/^/d' \
  -e :a -e '/\\/N; s/\\\n//; ta' \
  -e 's/^[ ]*//;s/[ ]*//' \
--e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@
+-e 's/\\=/=/' \
+| $(SORT) > $$@
  $(CHMOD) -f ug+w $$@

# And do not forget this target


I filed a separate issue [1] for investigating the use of pipefail.

/Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8065576

On 2014-11-20 10:34, Daniel Fuchs wrote:

On 11/20/14 10:26 AM, Erik Joelsson wrote:

Hello,

On 2014-11-20 02:20, Martin Buchholz wrote:
Amusingly, the $(SORT) has an LC_ALL=C carefully placed before it, 
but

the $(SED)s need it too!

Yes, I think that's the correct fix in this case.

On Wed, Nov 19, 2014 at 5:18 PM, Martin Buchholz
 wrote:

[+ build-dev]

I think I see the problem.  By default, a Unix pipeline sadly fails
only when the last command fails.  In bash, you can change this to a
more sensible default via
set -o pipefail
but that's not portable enough for openjdk.

This is interesting and something I had missed. I will experiment
with enabling pipefail if configure finds support for it. This will
include setting the SHELL to bash. We really should fail instead of
silently generating broken builds.

Daniel, I can take over this bug if you want and work on a proper
build fix.


Thanks Erik! You are welcome!
So the whole issue seems to be that my default setting is
LC_ALL=en_US.UTF-8
whereas sed requires LC_ALL=C to work properly on these property 
files...


When the test first failed I tried to rerun the test with LC_ALL=C -
with no success
of course. But I never thought of rebuilding with LC_ALL=C :-(

My apologies for the red herring :-(

best regards

-- daniel



/Erik

$(CAT) $$< | $(SED) -e 's/\([^\\]\):/\1\\:/g' -e
's/\([^\\]\)=/\1\\=/g' \
-e 's/\([^\\]\)!/\1\\!/g' -e 's/#.*/#/g' \
| $(SED) -f "$(SRC_ROOT)/make/common/support/unicode2x.sed" \
| $(SED) -e '/^#/d' -e '/^/d' \
-e :a -e '/\\/N; s/\\\n//; ta' \
-e 's/^[ ]*//;s/[ ]*//' \
-e 's/\\=/=/' | LC_ALL=C $(SORT) > $$@

On Wed, Nov 19, 2014 at 5:07 PM, huizhe wang
 wrote:

On 11/19/2014 4:09 PM, Mandy Chung wrote:


On 11/19/2014 3:49 PM, Mandy Chung wrote:


On 11/19/2014 12:50 PM, Daniel Fuchs wrote:

On 11/19/14 9:36 PM, Mandy Chung wrote:

resources.jar will be gone when we move to the modular runtime
image
(JEP 220 [1]).
JDK-8065138 and JDK-8065365 will become non-issue in JDK 9.

Do you mean that the property files will no longer be stripped
of their
comments?


(sorry for my delay in reply as I was trying to get the number
of the
resources in the modular image vs resources.jar but got
distracted.)

The current version copies all bytes when generating the modular
image.
This is a good question whether we should strip off the comments
when
writing to the modular runtime image.   I think we should look
at the
footprint and any performance saving and determine if we should
do the same
in JDK 9.


I looked at the exploded image under
BUILD_OUTPUTDIR/jdk/modules/java.xml
and found that the comments of Encodings.properties are stripped.
I was
confused with the mention of resources.jar that I assume it was a
step
stripping the comments before writing to resources.jar. This is
still
an issue in jigsaw m2 I believe.

Where does the build strip the comments?


A prev

RFR 8060026: Update test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main

[Amy Lu]

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/webrev.00/

Thanks,
Amy

Re: Reg: NoClassDefFoundError: sun/management/ExtendedPlatformComponent

[Janda Martin]

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/management/ExtendedPlatformComponent

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-8065397

best regards,

-- daniel

>
> Martin
>
> StackTrace:
>
> java.lang.NoClassDefFoundError: sun/management/ExtendedPlatformComponent
>   at 
> java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:494)
>   at 
> org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
>   at 
> org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown 
> Source)
>   at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown 
> Source)
>   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
> Source)
>   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
>   at 
> org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown 
> Source)
>   at org.apache.derby.impl.services.monitor.FileMonitor.(Unknown 
> Source)
>   at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown 
> Source)
>   at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
>   at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
>   at org.apache.derby.jdbc.EmbeddedDriver.(Unknown Source)
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:264)
>

Re: Reg: NoClassDefFoundError: sun/management/ExtendedPlatformComponent

[Daniel Fuchs]

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-8065397

best regards,

-- daniel



Martin

StackTrace:

java.lang.NoClassDefFoundError: sun/management/ExtendedPlatformComponent
at 
java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:494)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown 
Source)
at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at 
org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
at org.apache.derby.impl.services.monitor.FileMonitor.(Unknown 
Source)
at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown 
Source)
at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)

Re: Reg: NoClassDefFoundError: sun/management/ExtendedPlatformComponent

[Alan Bateman]

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 bug with Review ID: 9048260.

Martin

StackTrace:

java.lang.NoClassDefFoundError: sun/management/ExtendedPlatformComponent
at 
java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:494)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown 
Source)
at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at 
org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
at org.apache.derby.impl.services.monitor.FileMonitor.(Unknown 
Source)
at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown 
Source)
at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)

Reg: NoClassDefFoundError: sun/management/ExtendedPlatformComponent

[Janda Martin]

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.getPlatformMBeanServer(ManagementFactory.java:494)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at 
org.apache.derby.impl.services.jmx.JMXManagementService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown 
Source)
at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
Source)
at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
at 
org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown Source)
at 
org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
at org.apache.derby.impl.services.monitor.FileMonitor.(Unknown 
Source)
at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown 
Source)
at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
at org.apache.derby.jdbc.EmbeddedDriver.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)