Re: RFR 8139507: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs

[Jan Lahoda]

Hi Alan,

On 12.6.2016 20:51, Alan Bateman wrote:



On 10/06/2016 17:05, Jan Lahoda wrote:


The other Preferences implementations used this pattern, so I used it
as well. I don't have a problem with using double-checked locking.
Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8139507/webrev.01

(updates all the Preferences implementations, to remain consistent.)

This looks good. One small suggestion is to drop the initialization of
the volatiles to null, this shouldn't be needed.


Thanks. I removed the null initializations, and pushed.

Jan



-Alan

Fwd: RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError:

[shilpi.rast...@oracle.com]

Gentle reminder!


 Forwarded Message 
Subject: 	RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - 
java.lang.AssertionError:

Date:   Tue, 7 Jun 2016 14:58:47 +0530
From:   shilpi.rast...@oracle.com 
To: core-libs-dev 



Hi All,

Please review fix for
https://bugs.openjdk.java.net/browse/JDK-8039955
http://cr.openjdk.java.net/~srastogi/8039955/webrev.00/

Thanks,
Shilpi

Re: JDK 9 RFR of JDK-8159330: Improve deprecation text for Class.newInstance

[Roger Riggs]

Hi,

That example kind of glosses over the need to handle 3 new exceptions.
That's been my annoyance with this change.

throws InstantiationException, IllegalAccessException, 
InvocationTargetException


Roger



On 6/12/2016 11:43 PM, joe darcy wrote:


On 6/12/2016 7:21 PM, Wang Weijun wrote:

Why not just clazz.getConstructor().newInstance()?


That seems to work to and is much shorter; thanks :-)

-Joe




+ * can be replaced by
+ *
+ * {@code
+ * clazz.getConstructor(new 
Class[0]).newInstance((Object[])null);

+ * }

RFR 9: 8155808: Process.getInputStream().skip() method is faulty

[Roger Riggs]

A latent issue with Process InputStreams support for the skip method was 
reported[1].


Though the InputStream returned is a BufferedInputStream, in some cases,
the skip method calls FileInputStream.seek on the pipe containing output
from the process but the pipes do not support seek.  The proposed fix is 
to override
the skip method to implement skip as reading the bytes instead of 
invoking seek.


Please review and comment:

Webrev:

http://cr.openjdk.java.net/~rriggs/webrev-skip-8155808/index.html

Issue:

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

Thanks, Roger

JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Jan Lahoda]

Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when 
exported API refers to types not exported/accessible to the API clients.


I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

There are some warnings produced for existing code in the hotspot and 
jdk repositories (see the end for the warnings), I was using these 
patches to keep JDK buildable:

hotspot repository:
http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/

Any help with those (esp. those in the hotspot repository) would be 
wholeheartedly welcome.


Any feedback on this is welcome!

Thanks,
   Jan

The warnings:
-hotspot repository:
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
 ^
error: warnings found and -Werror specified
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
warning: unexported type referenced in exported API

public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
 ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
warning: unexported type referenced in exported API
public int adjustCompilationLevel(HotSpotVMConfig config, Class 
declaringClass, String name, String signature, boolean isOsr, int level) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


   ^
1 error
7 warnings

-jdk/java.desktop:
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: 
warning: inaccessible type referenced in exported API

protected DefaultAction defaultPressAction;
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: 
warning: inaccessible type referenced in exported API

protected DefaultAction defaultReleaseAction;
  ^
error: warnings found and -Werror specified
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
warning: inaccessible type referenced in exported API

protected MetalBumps bumps = new MetalBumps( 10, 10,
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
warning: inaccessible type referenced in exported API
protected DirectoryComboBoxRenderer 
createDirectoryComboBoxRenderer(JFileChooser fc) {

  ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65: 
warning: inaccessible type referenced in exported API

protected MetalBumps bumps;
  ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
5 warnings


-jdk/java.naming:
.../jdk/src/java.naming/share/classes/javax/naming/CompoundName.java:156: warning: 
inaccessible type referenced in exported API

protected transient NameImpl impl;
^
error: warnings found and -Werror specified
1 error
1 warning


-jdk/jdk.accessibility:
.../jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java:219: 
warning: inaccessible type referenced in exported API
static protected AWTEventsListener awtListener = new 
AWTEventsListener();

 ^
error: warnings found and -Werror specified
.../jdk/src/jdk.a

Re: JDK 9 RFR of JDK-8159330: Improve deprecation text for Class.newInstance

[joe darcy]

Hi Roger,

On 6/13/2016 6:59 AM, Roger Riggs wrote:

Hi,

That example kind of glosses over the need to handle 3 new exceptions.
That's been my annoyance with this change.

throws InstantiationException, IllegalAccessException, 
InvocationTargetException


The patch sent to the list 
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041754.html), 
did note addition exception types are thrown by the replacement code. 
The proposed text with Max's improvement is


+ * The call
+ *
+ * {@code
+ * clazz.newInstance()
+ * }
+ *
+ * can be replaced by
+ *
+ * {@code
+ * clazz.getConstructor().newInstance()
+ * }
+ *
+ * The latter sequence of calls is inferred to be able to throw
+ * the additional exception types {@link
+ * InvocationTargetException} and {@link
+ * NoSuchMethodException}. Both of these exception types are
+ * subclasses of {@link ReflectiveOperationException}.
+ *

Class.newInstance is declared to throw InstantiationException and 
IllegalAccessException. Its implementation internally catches 
NoSuchMethodException and rethrows it as something else.


I considered adding more text to guide developers more explicitly to 
either use multi-catch


catch(InstantiationException  | IllegalAccessException e) =>
catch(InstantiationException  | IllegalAccessException | 
InvocationTargetException | NoSuchMethodException e)


or catching ReflectiveOperationException

catch(InstantiationException  | IllegalAccessException e) =>
catch(ReflectiveOperationException e) =>

With the more precise rethrow feature added in 7, catching 
ReflectiveOperationException and then rethrowing it doesn't lose any 
type information.


I was hesitant to add such text as to not overwhelm further the 
non-deprecated text of the method. However, if people think such 
guidance is warranted, I'll craft something.


Thanks,

-Joe




Roger



On 6/12/2016 11:43 PM, joe darcy wrote:


On 6/12/2016 7:21 PM, Wang Weijun wrote:

Why not just clazz.getConstructor().newInstance()?


That seems to work to and is much shorter; thanks :-)

-Joe




+ * can be replaced by
+ *
+ * {@code
+ * clazz.getConstructor(new 
Class[0]).newInstance((Object[])null);

+ * }

Re: RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

[Peter Levart]

Hi,

I explored various strategies to minimize worst-case lookup performance 
for MethodType keys in LinearProbeHashtable. One idea is from the 
"Hopscotch hashing" algorithm [1] which tries to optimize placement of 
keys by moving them around at each insertion or deletion. While a 
concurrent Hopscotch hashtable is possible, it requires additional 
"metadata" about buckets which complicates it and does not make it 
practical for implementing in Java until Java gets value types and 
arrays of them. The simplest idea until then is to optimize placement of 
keys when the table is rehashed. Normally when table is rehashed the old 
table is scanned and entries from it inserted into new table. To achieve 
similar effect to "Hopscotch hashing", the order in which keys are taken 
from the old table and inserted into new table is changed. Keys are 
ordered by increasing bucket index as it would be computed for the key 
in the new table. Inserting in this order minimizes the worst-case 
lookup performance. Doing this when rehashing and not at every insertion 
or deletion guarantees that at least half of keys are optimally placed.


Another strategy to minimize worst-case lookup performance is to use 
quadratic probe sequence instead of linear probe sequence. Normally, 
when looking up a key, slots in the table are probed in the following 
sequence (seq = 0, 1, 2 ...):


index(seq) = (hashCode + seq) % tableLength

Quadratic probing uses the following probe sequence:

index(seq) = (hashCode + seq * (seq + 1) / 2) % tableLength

Those two strategies can be combined. Here's a simulation of using those 
two strategies in an open-addressing hashtable:


http://cr.openjdk.java.net/~plevart/misc/LinearProbeHashTable/lpht_MethodType_probe_sequence.txt

Using those strategies does not affect the average length of probing 
sequence much (length of 0 means that the key was found at its home 
location, length of 1 means that one non-equal key was probed before 
finding the equal one, etc ...), but worst-case lookup performance is 
greatly impacted. Combining both strategies minimizes the worst-case 
lookup performance.


Benchmarking using those strategies reveals the average lookup 
performance is consistently better than using CHM:


http://cr.openjdk.java.net/~plevart/misc/LinearProbeHashTable/lpht_MethodType_bench.pdf

The last trick to make this happen is stolen from CHM. The method type's 
key is a WeakReference which caches the hashCode of 
MethodType. By using cached hashCode in the key's equals() 
implementation as a means of optimization, we achieve similar effect 
that CHM achieves when it caches key's hashCode(s) in its Entry objects.


Here's the source of above benchmark:

http://cr.openjdk.java.net/~plevart/misc/LinearProbeHashTable/lpht_MethodType_bench_src.tgz

3 variations of LinearProbeHashtable are compared with CHM:

LinearProbeHashtable - the plain one from webrev.04.4
LinearProbeHashtable1 - using sorting of keys when rehashing to 
optimize their placement
LinearProbeHashtable2 - combines sorting of keys with quadratic 
probe sequence


I think LinearProbeHashtable2 could be used in MethodType interning 
without fear of degrading lookup performance.



Regards, Peter

[1] https://en.wikipedia.org/wiki/Hopscotch_hashing

RFR: 8153652 Update javap to be multi-release jar aware

[Steve Drach]

Hi,

Please review the following changeset that simply supplies the help information 
for the already existing javap command line option, -multi-release.

webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ 

issue: https://bugs.openjdk.java.net/browse/JDK-8153652 


It turns out that javap forwards unrecognized command line options to the 
JavaFileManager for processing.  One such option is -multi-release.  The value 
that the -multi-release option is set to is used by JavaFileManager to open 
multi-release jar files so that the appropriate versioned view is presented to 
the client, javap in this case.  All this changeset does is add a help message 
describing the existing -multi-release command line option. 

The values that can be assigned to this option, and the corresponding 
multi-release modes that the jar file is configured for are:

9 -> JarFile.Release.VERSION_9
runtime   -> JarFile.Release.RUNTIME
all others -> JarFile.Release.BASE

If the option is not present, the jar file mode is JarFile.Release.Base.

Thanks,
Steve

RFR: 81536534 Update jdeps to be multi-release jar aware

[Steve Drach]

Hi,

Please review the following changeset to make jdeps multi-release jar aware.

webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html 

issue: https://bugs.openjdk.java.net/browse/JDK-8153654 


The changeset adds a new command line option to jdeps.  The -multi-release 
option can be set to the string “runtime” or an integral string value 
corresponding to the Java platform releases starting at 9 (i.e. 9, 10, 11, 
etc.).  Jar files that jdeps accesses, either on the class path or as a target, 
are opened with the appropriate JarFile.Release parameter.  The mapping from 
-multi-release value to JarFile.Release is:

9 -> JarFile.Release.VERSION_9
runtime   -> JarFile.Release.RUNTIME
all others -> JarFile.Release.BASE

If the option is not present, the jar file mode is JarFile.Release.Base.

Thanks,
Steve

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Phil Race]

Hmm .. given that the majority of the jdk changes are in client - 
specifically
swing & accessibility -  including the swing mailing list would have 
increased the

likelihood of the right people clicking on this webrev link.

IMO,  we should remove these unusable fields from the Swing API - where
we can - and I think some we can, and really it ought to be all.

So I suggest that you leave alone those files and submit
bugs against swing & accessibility and the area owner
can then make the decision as to the appropriate treatment.

You can keep the JDK buildable in the meanwhile by suppressing the
lint warnings on the desktop module.

-phil.


On 06/13/2016 09:12 AM, Jan Lahoda wrote:

Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when 
exported API refers to types not exported/accessible to the API clients.


I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

There are some warnings produced for existing code in the hotspot and 
jdk repositories (see the end for the warnings), I was using these 
patches to keep JDK buildable:

hotspot repository:
http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/

Any help with those (esp. those in the hotspot repository) would be 
wholeheartedly welcome.


Any feedback on this is welcome!

Thanks,
   Jan

The warnings:
-hotspot repository:
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
 ^
error: warnings found and -Werror specified
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
warning: unexported type referenced in exported API

public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
 ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
warning: unexported type referenced in exported API
public int adjustCompilationLevel(HotSpotVMConfig config, Class 
declaringClass, String name, String signature, boolean isOsr, int 
level) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


   ^
1 error
7 warnings

-jdk/java.desktop:
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: 
warning: inaccessible type referenced in exported API

protected DefaultAction defaultPressAction;
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: 
warning: inaccessible type referenced in exported API

protected DefaultAction defaultReleaseAction;
  ^
error: warnings found and -Werror specified
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
warning: inaccessible type referenced in exported API

protected MetalBumps bumps = new MetalBumps( 10, 10,
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
warning: inaccessible type referenced in exported API
protected DirectoryComboBoxRenderer 
createDirectoryComboBoxRenderer(JFileChooser fc) {

  ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalScrollBarUI.java:65: 
warning: inaccessible type referenced in exported API

protected MetalBumps bumps;
  ^
Note: Some input files use or override a deprecated API.
No

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Philip Race]

PS .. also you probably should  just suppress lint on the jdk.jsobject 
module


The change you propose to JSObject is going to cause a potential conflict
with the ongoing review discussion about this here :-

http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html

-phil.

On 6/13/16, 10:59 AM, Phil Race wrote:
Hmm .. given that the majority of the jdk changes are in client - 
specifically
swing & accessibility -  including the swing mailing list would have 
increased the

likelihood of the right people clicking on this webrev link.

IMO,  we should remove these unusable fields from the Swing API - where
we can - and I think some we can, and really it ought to be all.

So I suggest that you leave alone those files and submit
bugs against swing & accessibility and the area owner
can then make the decision as to the appropriate treatment.

You can keep the JDK buildable in the meanwhile by suppressing the
lint warnings on the desktop module.

-phil.


On 06/13/2016 09:12 AM, Jan Lahoda wrote:

Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when 
exported API refers to types not exported/accessible to the API clients.


I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

There are some warnings produced for existing code in the hotspot and 
jdk repositories (see the end for the warnings), I was using these 
patches to keep JDK buildable:

hotspot repository:
http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/

Any help with those (esp. those in the hotspot repository) would be 
wholeheartedly welcome.


Any feedback on this is welcome!

Thanks,
   Jan

The warnings:
-hotspot repository:
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72: 
warning: unexported type referenced in exported API

public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
 ^
error: warnings found and -Werror specified
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54: 
warning: unexported type referenced in exported API

public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
 ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73: 
warning: unexported type referenced in exported API
public int adjustCompilationLevel(HotSpotVMConfig config, 
Class declaringClass, String name, String signature, boolean 
isOsr, int level) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70: 
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider 
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode 
compiledCode) {


   ^
1 error
7 warnings

-jdk/java.desktop:
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333: warning: 
inaccessible type referenced in exported API

protected DefaultAction defaultPressAction;
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344: warning: 
inaccessible type referenced in exported API

protected DefaultAction defaultReleaseAction;
  ^
error: warnings found and -Werror specified
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742: 
warning: inaccessible type referenced in exported API

protected MetalBumps bumps = new MetalBumps( 10, 10,
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java:926: 
warning: inaccessible type referenced in exported API
protected DirectoryComboBoxRe

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Alan Bateman]

On 13/06/2016 20:26, Philip Race wrote:
PS .. also you probably should  just suppress lint on the jdk.jsobject 
module


The change you propose to JSObject is going to cause a potential conflict
with the ongoing review discussion about this here :-

http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
Speaking of, shouldn't this have forRemoval=true? The reason that 
jdk.jsobject doesn't `requires public java.desktop` is because we expect 
getWindow(Applet) will eventually be removed and we don't want to trip 
up those that might be relying on it to access APIs exported by 
java.desktop.


-Alan

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Philip Race]

Alan,

See the comment here : 
http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html


Probably you should chime in directly on that discussion with such input ..

-phil.

On 6/13/16, 12:47 PM, Alan Bateman wrote:



On 13/06/2016 20:26, Philip Race wrote:
PS .. also you probably should  just suppress lint on the 
jdk.jsobject module


The change you propose to JSObject is going to cause a potential 
conflict

with the ongoing review discussion about this here :-

http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
Speaking of, shouldn't this have forRemoval=true? The reason that 
jdk.jsobject doesn't `requires public java.desktop` is because we 
expect getWindow(Applet) will eventually be removed and we don't want 
to trip up those that might be relying on it to access APIs exported 
by java.desktop.


-Alan

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Mandy Chung]

I agree JSObject.getWindow(Applet) should have forRemoval=true, as I raised in 
awt-dev thread.  The confusion there was when the API marked forRemoval=true in 
JDK 9 and when it should really be removed.

Mandy 

> On Jun 13, 2016, at 12:53 PM, Philip Race  wrote:
> 
> Alan,
> 
> See the comment here : 
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html
> 
> Probably you should chime in directly on that discussion with such input ..
> 
> -phil.
> 
> On 6/13/16, 12:47 PM, Alan Bateman wrote:
>> 
>> 
>> On 13/06/2016 20:26, Philip Race wrote:
>>> PS .. also you probably should  just suppress lint on the jdk.jsobject 
>>> module
>>> 
>>> The change you propose to JSObject is going to cause a potential conflict
>>> with the ongoing review discussion about this here :-
>>> 
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html
>> Speaking of, shouldn't this have forRemoval=true? The reason that 
>> jdk.jsobject doesn't `requires public java.desktop` is because we expect 
>> getWindow(Applet) will eventually be removed and we don't want to trip up 
>> those that might be relying on it to access APIs exported by java.desktop.
>> 
>> -Alan

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

[Brent Christian]

Hi,

Please review this Mac-only fix:

http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-7131356

Thanks go to Gerard Ziemski for the thorough investigation and detailed 
write-up in the bug report.


The symptoms:

On those OS X machines where the default system Java is not installed, 
any attempt to instantiate JVM from a local JDK (for example via JNI as 
shown in the bug) presents "No Java installed. Do you want to install 
Java?" dialog and refuses to run. Clearly, a valid local JDK should be 
able to run in this case.


The problem:

In java_props_macosx.c, there is code that dynamically looks up 4 
methods in JavaRuntimeSupport.framework (JRS) and calls into them to 
find out localized OS version, default locale and the preferred 
language, but JRS checks for a system available Java and refuses to run 
if none found.


Background:

JavaRuntimeSupport.framework (JRS) is a framework implemented and 
provided by Apple for use by Java.  It is a "black box" that wraps SPIs 
required by the Apple-provided implementation of JDK, exposing them to 
the JDK as APIs.


Now that the JDK implementation ownership has changed from Apple to 
Oracle, we have the issue that we don't control the JRS implementation, 
but rely on Apple to support it for our JDK to continue to run. 
Depending on a private framework provided by a third party for our code 
to continue to run doesn't seem like a good long term bet (see also 
8024281).


Proposed solution:

Apple suggested changing the JDK initialization order so any access to 
JRS happens only after the JLI_MemAlloc symbol is available.  We believe 
a better solution is to re-implement the JSR APIs in question, as a move 
toward eventually dropping reliance on JSR altogether.  The three main 
changes are:


1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using 
"CFLocaleCopyPreferredLanguages", which gives us the preferred language 
as set in "System Preferences"->"Language & Text"->"Language" in the 
form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The 
original Apple code then calls into 
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into 
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though 
this appears to be unnecessary.  Following the call to 
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map 
the language to a default country, per this comment:


 * If the locale name (without .encoding@variant, if any) matches
 * any of the names in the locale_aliases list, map it to the
 * corresponding full locale name.  Most of the entries in the
 * locale_aliases list are locales that include a language name but
 * no country name, and this facility is used to map each language
 * to a default country if that's possible.

I tried out a few locales, for English (en_US, en_GB), German (de_DE, 
de_CH) and French (fr_FR, fr_CA).  Language/country system properties 
behave the same before and after this change, as does the 
java.util.Locale test attached to the bug.


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".


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



Thanks,
-Brent

1. 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c

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

[Naoto Sato]

Hi Brent,

On 6/13/16 1:58 PM, Brent Christian wrote:


Apple suggested changing the JDK initialization order so any access to
JRS happens only after the JLI_MemAlloc symbol is available.  We believe
a better solution is to re-implement the JSR APIs in question, as a move
toward eventually dropping reliance on JSR altogether.  The three main
changes are:

1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using
"CFLocaleCopyPreferredLanguages", which gives us the preferred language
as set in "System Preferences"->"Language & Text"->"Language" in the
form of "xx" (ie. just the language code - ex. "en", "fr", etc.).  The
original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
this appears to be unnecessary.  Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country, per this comment:

 * If the locale name (without .encoding@variant, if any) matches
 * any of the names in the locale_aliases list, map it to the
 * corresponding full locale name.  Most of the entries in the
 * locale_aliases list are locales that include a language name but
 * no country name, and this facility is used to map each language
 * to a default country if that's possible.

I tried out a few locales, for English (en_US, en_GB), German (de_DE,
de_CH) and French (fr_FR, fr_CA).  Language/country system properties
behave the same before and after this change, as does the
java.util.Locale test attached to the bug.


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?


Also, the array index "2" to assume the language length is 2 is not 
correct, as there are three letter language codes. So the code should 
literally look for "-" instead.


Naoto

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

[Mandy Chung]

Hi Steve,

> On Jun 13, 2016, at 11:02 AM, Steve Drach  wrote:
> 
> Hi,
> 
> Please review the following changeset to make jdeps multi-release jar aware.
> 
> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html 
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8153654 
> 
> 
> The changeset adds a new command line option to jdeps.  The -multi-release 
> option can be set to the string “runtime” or an integral string value 
> corresponding to the Java platform releases starting at 9 (i.e. 9, 10, 11, 
> etc.).  Jar files that jdeps accesses, either on the class path or as a 
> target, are opened with the appropriate JarFile.Release parameter.  The 
> mapping from -multi-release value to JarFile.Release is:
> 
> 9 -> JarFile.Release.VERSION_9
> runtime   -> JarFile.Release.RUNTIME
> all others -> JarFile.Release.BASE
> 
> If the option is not present, the jar file mode is JarFile.Release.Base.

Have you considered parsing all versioned entries in MRJAR as the default and 
include the version information in the output?  

A relevant implementation details:

jdeps is using its runtime environment to analyse the class dependencies.  The 
potential missing information when analyzing a MR jar is some JDK internal APIs 
not present in the current runtime but exists in the older release. jdeps 
maintains a small list of the removed sun.misc and sun.reflect internal APIs to 
emit useful information since existing libraries may depend on those removed 
types that already have replacement; otherwise, they will be shown as not found 
which is accurate as CNFE may be thrown if that library is running on JDK 9.

Mandy

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

[Brent Christian]

Hi, Naoto.  Thank you for having a look.

On 13/06/2016 14:43, Naoto Sato wrote:

On 6/13/16 1:58 PM, Brent Christian wrote:


The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
this appears to be unnecessary.  Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country, per this comment:

 * If the locale name (without .encoding@variant, if any) matches
 * any of the names in the locale_aliases list, map it to the
 * corresponding full locale name.  Most of the entries in the
 * locale_aliases list are locales that include a language name but
 * no country name, and this facility is used to map each language
 * to a default country if that's possible.

I tried out a few locales, for English (en_US, en_GB), German (de_DE,
de_CH) and French (fr_FR, fr_CA).  Language/country system properties
behave the same before and after this change, as does the
java.util.Locale test attached to the bug.


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?


The new code has the same behavior as the existing code.

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.



Also, the array index "2" to assume the language length is 2 is not
correct, as there are three letter language codes. So the code should
literally look for "-" instead.


Great, thanks.  I will fix that.

-Brent

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

[Naoto Sato]

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

Hi, Naoto.  Thank you for having a look.

On 13/06/2016 14:43, Naoto Sato wrote:

On 6/13/16 1:58 PM, Brent Christian wrote:


The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
this appears to be unnecessary.  Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country, per this comment:

 * If the locale name (without .encoding@variant, if any) matches
 * any of the names in the locale_aliases list, map it to the
 * corresponding full locale name.  Most of the entries in the
 * locale_aliases list are locales that include a language name but
 * no country name, and this facility is used to map each language
 * to a default country if that's possible.

I tried out a few locales, for English (en_US, en_GB), German (de_DE,
de_CH) and French (fr_FR, fr_CA).  Language/country system properties
behave the same before and after this change, as does the
java.util.Locale test attached to the bug.


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?


The new code has the same behavior as the existing code.

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.


Naoto