Re: RFR 8157530/9, Remove intermittent key from javax/net/ssl/DTLS/WeakCipherSuite.java

[Xuelei Fan]

Looks fine to me.

Thanks,
Xuelei

On 6/20/2016 1:52 PM, Felix Yang wrote:
> javax/net/ssl/DTLS/WeakCipherSuite.java failed intermittently with
> (JDK-8129389 ). It had
> been resolved and no new failure was observed in pass round of same
> binaries runs.
> 
> It looks necessary to remove @key intermittent from the test.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8157530
> 
> Patch:
> 
> diff -r 7ff61c55b5c6 test/javax/net/ssl/DTLS/WeakCipherSuite.java
> --- a/test/javax/net/ssl/DTLS/WeakCipherSuite.java  Sat Jun 18
> 16:50:19 2016 -0700
> +++ b/test/javax/net/ssl/DTLS/WeakCipherSuite.java  Sun Jun 19
> 22:39:34 2016 -0700
> @@ -27,7 +27,6 @@
>  /*
>   * @test
>   * @bug 8043758
> - * @key intermittent
>   * @summary Datagram Transport Layer Security (DTLS)
>   * @modules java.base/sun.security.util
>   * @build DTLSOverDatagram
> 
> Thanks,
> 
> Felix
> 

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

[David Holmes]

On 17/06/2016 10:20 PM, Claes Redestad wrote:



On 2016-06-17 03:35, David Holmes wrote:

Hi Claes,

On 17/06/2016 8:20 AM, Claes Redestad wrote:

Isn't this variable unused now:

  63 boolean vmAllowSuspension;


Interestingly enough there are hooks in hotspot to compute offsets of
various fields in j.l.ThreadGroup, so even though the vmAllowSuspension
field is unused (on both sides), removing the field would require
changing code in hotspot.

Tumbled down that rabbit hole to see how deep it goes, and was
pleasantly surprised that it didn't go very far at all:

HS: http://cr.openjdk.java.net/~redestad/8159590/hotspot.02/
JDK: http://cr.openjdk.java.net/~redestad/8159590/jdk.02/

I think the cleanup on the vm side might be trivial enough to be wrapped
into this change. What do you think?


I'd need to look into the SA code as well and double-check some
things. But I'm off till next week :) If you want to move ahead
urgently then we can file a follow up cleanup bug for hotspot.


Not urgent enough to wait a few days to allow for this more thorough
cleanup. :-)


Everything seems okay.

Thanks,
David


/Claes

Re: RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

[Claes Redestad]

On 2016-06-20 14:42, David Holmes wrote:

On 17/06/2016 10:20 PM, Claes Redestad wrote:



On 2016-06-17 03:35, David Holmes wrote:



On 17/06/2016 8:20 AM, Claes Redestad wrote:

HS: http://cr.openjdk.java.net/~redestad/8159590/hotspot.02/
JDK: http://cr.openjdk.java.net/~redestad/8159590/jdk.02/



Everything seems okay.

Thanks,
David


Thanks!

/Claes

Re: [9] RFR: 8159548: Formatter returns unexpected strings if locale is null.

[Naoto Sato]

Kindly reminder...

Naoto

On 6/16/16 2:48 PM, Naoto Sato wrote:

Hi,

Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8159548/webrev.00/

The previous fix to 8146156 overly localized the formatted text for the
"null" locale. The offending localization code were reverted to the
original.

Naoto

RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

[Daniel Fuchs]

Hi,

Please find below a patch for:

8159245: Loggers created by system classes are not initialized
 correctly when configured programmatically from
 application code.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8150173

Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.00/index.html

When an application requests a logger by name, we do not know before
hand whether that corresponds to a system logger name or not.
So if no system logger by that name already exists, we simply return an
application logger.

The issue happens if a system class later requests a system logger
of the same name. The current implementation would simply copy over
the user logger handlers to the system logger, ignoring any other
data (level, filter, flags) that might have been set by the application
(with permission checks) prior to the creation of the system logger.

The proposed patch ensures instead that if a system class later
requests a system logger of the same name, then the application logger
and system logger configurations will be merged in a single instance of
a private static Logger$ConfigurationData value class that both loggers
will share.

A new test is added to verify that the configuration issue is fixed in
the various possible configuration cases:

  - parent of system logger created by the application before system
logger exists,
  - parent of system logger created by the application after system
logger exists,
  - logger created by the application before system logger of the
same name exists
  - logger created by the application after system logger of the
same name exists
  - all of the above with and without a security manager.

The new test will fail without the fix and pass with it.

best regards,

-- daniel

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

[Steve Drach]

Hi Remi,

> do you have checked that the your patch doesn't load a bunch of supplementary 
> classes at start-up ?
> because JarFile is used at start-up, it triggers the load of Runtime.Version 
> and Runtime.Version has a dependency on a dozen of classes in java.util.regex.

Is it still true, in JDK 9, that JarFile is loaded at start-up?  Using a simple 
Hello World program, I started it with the option -verbose:class and did not 
see either JarFile or Version loaded.  Just to verify, I added a print 
statement to a static initializer in both JarFile and Version, and again did 
not see either class loaded.  I also tried the tests with a jar file on the 
class path and did see both classes loaded.

> 
> cheers,
> Rémi
> 
> - Mail original -
>> De: "Steve Drach" 
>> À: "Joseph D. Darcy" 
>> Cc: "Core-Libs-Dev" 
>> Envoyé: Jeudi 16 Juin 2016 23:44:14
>> Objet: [SPAM-RENATER]Re: RFR: 8150680 JarFile.Release enum needs 
>> reconsideration withrespect to it's values
>> 
>> This webrev uses methods instead of fields to return the base and runtime
>> values used internally by JarFile.  I’ve also optimized it a bit.
>> 
>> http://cr.openjdk.java.net/~sdrach/8150680/webrev.02/
>> 
>> 
>>> On Jun 15, 2016, at 4:31 PM, Joseph D. Darcy  wrote:
>>> 
>>> Steve,
>>> 
>>> In JarFile, please use methods not fields to return the new information.
>>> The information in question is not constant across versions. Using methods
>>> instead of fields avoid over-committing on a particular implementation,
>>> etc.
>>> 
>>> Cheers,
>>> 
>>> -Joe
>>> 
>>> On 6/15/2016 3:49 PM, Steve Drach wrote:
 I’ve updated the webrev to address the issue of the constructor accepting
 values like Version.parse(“7.1”)
 
 http://cr.openjdk.java.net/~sdrach/8150680/webrev.01/
 
 
> On Jun 15, 2016, at 8:56 AM, Steve Drach  wrote:
> 
>>> Please review the following changeset:
>>> 
>>> webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8150680
>>> 
>>> 
>>> The issue calls for reconsidering the JarFile.Release enum.  A comment
>>> in the bug report suggests replacing JarFile.Release with
>>> Runtime.Version, and that’s what I did.  Specifically I removed the
>>> enum, changed the constructor to accept a Runtime.Version object
>>> instead of a JarFile.Release object, updated all places in the JDK
>>> that invoked the constructor and updated all tests.
>>> 
>> Moving to Runtime.Version seems right but doesn't the javadoc for the
>> constructor need to be updated to make it clear how it behavior when
>> invoking with something like Version.parse("7.1") ? If I read the code
>> correctly then this will be accepted and getVersion() will return 7.1.
> Yes, it needs to be updated and it needs to be fixed.  Thanks for finding
> that.
> 
>> Fields or methods is another discussion point for the base and runtime
>> versions.
> My thinking is, in this case fields and methods are equivalent, the
> method not giving any more flexibility than a field.  For example the
> method JarFile.baseVersion will just return the value contained in the
> private final static field BASE_VERSION.  Or the public final static
> field BASE_VERSION can be directly accessed.  I see no advantage of a
> method here.  But I’m willing to be enlightened.
> 
>> -Alan.
>>> 
>> 
>> 

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Brent Christian]

On 6/13/16 5:14 PM, Naoto Sato wrote:

On 13/06/2016 16:20, Brent Christian wrote:


Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country


So does this mean the new code will not honor the "Region" in the OSX's
system preference? For example, what happens if the user sets "UK" for
the "Region" in the preference, then the new code return "US" for the
country?


OS X's Region preference is reflected as the locale's "format", through
the "user.country.format" system property, and
Locale.getDefault(Locale.FORMAT).

The region is not reflected in the base "user.country" property or
Locale.getDefault().  As the existing source comment indicates, the
country is mapped to the default for the language, in this case, "US".

It seemed a bit strange to me, too, but my testing indicates this has
been the behavior since jdk 7u4.


I think that is a bug. It should adopt "UK" for the default/display
locale too. Probably this should be addressed in a separate bug.


After some more investigation, I don't believe there is a bug here.

The behavior I saw happened when using the basic 
"English"/"French"/"German" languages, and changing the country with Region.


OS X also provides regional options for the language itself (e.g. 
"British English", "Canadian French", "Swiss German", etc) in Preferred 
languages.  When using these languages, defaults are as expected (e.g. 
reflected in "user.country") without remapping with mapLookup().


Thanks,
-Brent

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Naoto Sato]

Good! Wasn't aware there is "British English" in the language selection. 
Looks like all is working as expected.


Naoto

On 6/20/16 2:34 PM, Brent Christian wrote:

On 6/13/16 5:14 PM, Naoto Sato wrote:

On 13/06/2016 16:20, Brent Christian wrote:


Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country


So does this mean the new code will not honor the "Region" in the OSX's
system preference? For example, what happens if the user sets "UK" for
the "Region" in the preference, then the new code return "US" for the
country?


OS X's Region preference is reflected as the locale's "format", through
the "user.country.format" system property, and
Locale.getDefault(Locale.FORMAT).

The region is not reflected in the base "user.country" property or
Locale.getDefault().  As the existing source comment indicates, the
country is mapped to the default for the language, in this case, "US".

It seemed a bit strange to me, too, but my testing indicates this has
been the behavior since jdk 7u4.


I think that is a bug. It should adopt "UK" for the default/display
locale too. Probably this should be addressed in a separate bug.


After some more investigation, I don't believe there is a bug here.

The behavior I saw happened when using the basic
"English"/"French"/"German" languages, and changing the country with
Region.

OS X also provides regional options for the language itself (e.g.
"British English", "Canadian French", "Swiss German", etc) in Preferred
languages.  When using these languages, defaults are as expected (e.g.
reflected in "user.country") without remapping with mapLookup().

Thanks,
-Brent

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Brent Christian]

Alex - thanks for your response.  More below...

On 6/13/16 4:51 PM, Alex Strange wrote:

2. In "setupMacOSXLocale" we simply drop the call to
"JRSSetDefaultLocalization" as it appears to be a NOP. According to
Apple, that API sets up native bundle locale, so that any access to
native Cocoa UI (like FileOpenChooser) uses localized strings.
Testing shows that this does not seem to work even in Apple's own
JDK (ie. JDK 6), so dropping the call to this SPI here does not
result in a regression.  An issue was filed to investigate further
(8024279, a dup of 8019464) which has since been closed as, "Not an
Issue".


This was added a very long time ago so that 'java -jar x.jar' would
show properly localized menus in the menubar, instead of English
menus, on a non-English system. It might no longer be a problem.


OK, thanks.

'java -jar x.jar' behavior is unchanged with this patch.  (From the bug 
report, it hasn't worked since JDK 7).



3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using
[NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was
already removed by 7178922).


You shouldn't need to use objc_msgSend_stret here. If you're not
getting a warning when you use @selector in the line above, you
should just be able to call -operationgSystemVersion directly inside
the if.

If you are getting a warning, it'd be best to declare the selector
yourself somewhere higher up:

typedef struct {
NSInteger majorVersion;
NSInteger minorVersion;
NSInteger patchVersion;
} OSVerStruct;

@interface NSProcessInfo ()
- (OSVerStruct)operatingSystemVersion;
@end


Thanks - this works for building w/ the 10.9 SDK (the officially 
supported Mac SDK for building JDK).


But I believe people also build w/ the 10.10 SDK (I've not tried it 
myself).  Won't this cause problems, since NSProcessInfo already has 
"operatingSystemVersion", and it returns an NSOperatingSystemVersion, 
not an OSVerStruct ?


I'd prefer something that can build on SDK 10.9 and 10.10, etc.  Once 
the official build moves to 10.10/later, objc_msgSend() can be removed 
and we can use [NSProcessInfo operatingSystemVersion] directly.


Thanks,
-Brent

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Brent Christian]

Hi,

I have an updated webrev at:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/

The comments have been updated as Gerard suggested.

The code to process the languageString now accounts for 3-character 
language codes, and 4-char script designations (line 86).


More extensive testing of languages with multiple scripts/regions
revealed that more changes were needed to maintain current behavior. 
Without knowing the internal workings of how
JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I 
believe the best options are to add a few more mappings as needed to 
locale_aliases (locale_str.h), and to add a special case for Portuguese 
(line 104).


OS X has 3 language options for Portuguese:
Portugues (Portugal)
Portugues (Brasil)
Portugues (Brasileiro)

CFLocaleCopyPreferredLanguages() gives the expected language code for
Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't 
include a region code (it's simply, "pt"), so gets mapped to the default 
country, Portugal.  To maintain current behavior, I added a special case 
to map "pt" to "pt_BR" when the Region system preference is set to Brazil.



This change introduces one notable behavior change, which I argue is 
actually a fix.  The bug report and test case do not list the "Spanish 
(Mexico)" language, but it is present on MaxOS 10.9 (presumably it was 
added to the OS since the original investigation).  The old code mapped 
this to "es_XL", XL being one of the "user-assigned" ISO 3166 country 
codes.  The new code maps to "es_MX", MX being the country code for Mexico.



I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried 
every language that includes multiple scripts/locales.  I also added a 
couple updated tests to the bug report.


General testing has looked good so far.

Thanks,
-Brent

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

[Hamlin Li]

Hi Daniel,

I just has one simple question.
In new version, in Logger::importConfig, userParentHandlers, filter, 
levelObject are copied from other(ConfigurationData) unconditionally, 
handlers in other are only *copied *when it's empty in system.
In previous version, handlers in other are *added *(which means merge 2 
set of handlers)**unconditionally.

is this different behavior expected?

Thank you
-Hamlin

On 2016/6/21 0:34, Daniel Fuchs wrote:

Hi,

Please find below a patch for:

8159245: Loggers created by system classes are not initialized
 correctly when configured programmatically from
 application code.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8150173

Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.00/index.html

When an application requests a logger by name, we do not know before
hand whether that corresponds to a system logger name or not.
So if no system logger by that name already exists, we simply return an
application logger.

The issue happens if a system class later requests a system logger
of the same name. The current implementation would simply copy over
the user logger handlers to the system logger, ignoring any other
data (level, filter, flags) that might have been set by the application
(with permission checks) prior to the creation of the system logger.

The proposed patch ensures instead that if a system class later
requests a system logger of the same name, then the application logger
and system logger configurations will be merged in a single instance of
a private static Logger$ConfigurationData value class that both loggers
will share.

A new test is added to verify that the configuration issue is fixed in
the various possible configuration cases:

  - parent of system logger created by the application before system
logger exists,
  - parent of system logger created by the application after system
logger exists,
  - logger created by the application before system logger of the
same name exists
  - logger created by the application after system logger of the
same name exists
  - all of the above with and without a security manager.

The new test will fail without the fix and pass with it.

best regards,

-- daniel

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

[Daniel Fuchs]

On 21/06/16 04:29, Hamlin Li wrote:

Hi Daniel,

I just has one simple question.
In new version, in Logger::importConfig, userParentHandlers, filter,
levelObject are copied from other(ConfigurationData) unconditionally,
handlers in other are only *copied *when it's empty in system.
In previous version, handlers in other are *added *(which means merge 2
set of handlers)**unconditionally.
is this different behavior expected?


Hi Hamlin,

There's no difference in behaviour - mergeConfigWithSystemPeer is called
unconditionally but the handlers from the application logger will be
copied in the system logger config only if the system's logger
list is empty - just like before.

This is something that will probably need to be revisited - maybe
the system handlers should be closed first and the application
handlers added unconditionally.
The issue here is that if the system logger had handlers
configured from the logging.properties file then the user handlers
are going to be garbage collected before being closed - which is
not ideal - even if it should rarely happen.

Let me think on it.

best regards,

-- daniel



Thank you
-Hamlin

On 2016/6/21 0:34, Daniel Fuchs wrote:

Hi,

Please find below a patch for:

8159245: Loggers created by system classes are not initialized
 correctly when configured programmatically from
 application code.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8150173

Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.00/index.html

When an application requests a logger by name, we do not know before
hand whether that corresponds to a system logger name or not.
So if no system logger by that name already exists, we simply return an
application logger.

The issue happens if a system class later requests a system logger
of the same name. The current implementation would simply copy over
the user logger handlers to the system logger, ignoring any other
data (level, filter, flags) that might have been set by the application
(with permission checks) prior to the creation of the system logger.

The proposed patch ensures instead that if a system class later
requests a system logger of the same name, then the application logger
and system logger configurations will be merged in a single instance of
a private static Logger$ConfigurationData value class that both loggers
will share.

A new test is added to verify that the configuration issue is fixed in
the various possible configuration cases:

  - parent of system logger created by the application before system
logger exists,
  - parent of system logger created by the application after system
logger exists,
  - logger created by the application before system logger of the
same name exists
  - logger created by the application after system logger of the
same name exists
  - all of the above with and without a security manager.

The new test will fail without the fix and pass with it.

best regards,

-- daniel