Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-09 Thread John Rose 
On Apr 8, 2015, at 7:52 PM, David Holmes david.hol...@oracle.com wrote:
 
 Meta-question: if this is non-Java code then what does/should simpleName 
 even mean? Returns the simple name of the underlying class as given in the 
 source code. If there is no (java) source code does this have any meaning? 
 Should it return  ?

Non-Java languages can use the JVM's features, including the InnerClasses 
attribute.

The simple name of a class has a natural (JVM-level) definition in terms of the 
contents of the class's InnerClasses attribute.

Parsing the name string was always a buggy stopgap.  It doesn't fully make 
sense for either Java or non-Java programs.

— John

[9] RFR (XXS): 8077054: DMH LFs should be customizeable

2015-04-09 Thread Vladimir Ivanov 

http://cr.openjdk.java.net/~vlivanov/8077054/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8077054

It's a followup fix for JDK-8069591 [1].

As Charlie observed, it's important to customize DirectMethodHandles as 
well. Otherwise, additional frame for DMH LambdaForm is created and it 
causes observable peak performance regression in some situations (e.g. 
JRuby9K).


Testing: manual (microbenchmark, compilation log inspection).

Thanks!

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8069591
 Customize LambdaForms which are invoked using
  MH.invoke/invokeExact

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-09 Thread David Holmes 

Hi Remi,

On 9/04/2015 4:10 PM, Rémi Forax wrote:

Hi David,
The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l
i.WrongMethodTypeException uses MethodType.toString.

So if getSimpleName returns a blank string, you destroy the debuggability of 
any invokedynamic/methodhandle calls.


Okay, so an alternative there is for MethodType.toString to not use 
getSimpleName :)


More seriously perhaps things like getSimpleName need to be re-specified 
to account for classes coming from other than Java source code? Even the 
INNERCLASSES_Attribute associates the name with Java source code: 
original simple name of C, as given in the source code from which this 
class file was compiled. And what is a simple name? It should be the 
most basic name given to a class without any prefix that indicates an 
enclosing type or containing package - but if non-Java-language-names 
are allowed how can you recognize such a prefix?


Cheers,
David


regards,
Rémi

Le 9 avril 2015 04:52:15 CEST, David Holmes david.hol...@oracle.com a écrit :

Hi Vladimir,

On 9/04/2015 1:41 AM, Vladimir Ivanov wrote:

http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk
http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot
https://bugs.openjdk.java.net/browse/JDK-8057919

The logic to compute simple name (Class.getSimpleName()) for
inner/nested/local classes is tightly coupled with Java naming scheme
and sometimes fails for classes generated from non-Java code.


Meta-question: if this is non-Java code then what does/should
simpleName even mean? Returns the simple name of the underlying
class
as given in the source code. If there is no (java) source code does
this have any meaning? Should it return  ?


Instead of parsing class name and try to extract simple name based on
JLS rules, the fix I propose is to use InnerClasses attribute from

the

class file. Simple name is already recorded there.

JVMS-4.7.6: The InnerClasses Attribute
inner_name_index: If C is anonymous (JLS §15.9.5), the value of the
inner_name_index item must be zero. Otherwise, the value of the
inner_name_index item must be a valid index into the constant_pool
table, and the entry at that index must be a CONSTANT_Utf8_info
structure (§4.4.7) that represents the original simple name of C, as
given in the source code from which this class file was compiled.

Since I consider backporting the fix into 8u60, I'd like to hear
opinions about backward compatibility of such change.

As an alternative solution, I can restore original logic and consult
InnerClasses attribute when class name parsing logic fails.


I think I'd prefer to see the VM call only used as a fallback if the
regular parsing fails. That would prevent any compatibility issues for
the 8u backport (ignoring tests that deliberately generate invalidly
named classes).

Thanks,
David


Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/

Thanks!

Best regards,
Vladimir Ivanov

Re: RFR: 8076090: jimage extract + recreate broken again

2015-04-09 Thread Mandy Chung 

On 4/9/15 7:59 AM, Jim Laskey (Oracle) wrote:

Thanks Mandy.  Changed the main to ;

 public static void main(String[] args) {
 final String JAVA_HOME = System.getProperty(java.home);
 Path jimagePath = Paths.get(JAVA_HOME, bin, jimage);
 Path bootimagePath = Paths.get(JAVA_HOME, lib, modules, 
bootmodules.jimage);

 if (Files.exists(jimagePath)  Files.exists(bootimagePath)) {
 String jimage = jimagePath.toAbsolutePath().toString();
 String bootimage = bootimagePath.toAbsolutePath().toString();
 String extractDir = Paths.get(., 
extract).toAbsolutePath().toString();
 String recreateImage = Paths.get(., 
recreate.jimage).toAbsolutePath().toString();

 exec(new String[] {jimage, extract, --dir, extractDir, 
bootimage});
 exec(new String[] {jimage, recreate, --dir, extractDir, 
recreateImage});

 System.err.println(Test successful);
  } else {
 System.err.println(Test skipped, no module image);
  }
 }

Running jprt - okay to push after that?



Looks good and yes okay to push after jprt job succeeds. Nit: System.err 
- System.out as it's not an error.


Mandy

RFR (XXS) : 8050123: Incorrect property name documented in CORBA InputStream API

2015-04-09 Thread Seán Coffey 

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

diff --git 
a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java 
b/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java
--- 
a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java
+++ 
b/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java

@@ -77,7 +77,7 @@
  *
  * throw SecurityException if SecurityManager is installed and
  * enableSubclassImplementation SerializablePermission
- * is not granted or jdk.corba.allowOutputStreamSubclass system
+ * is not granted or jdk.corba.allowInputStreamSubclass system
  * property is either not set or is set to 'false'
  */
 public InputStream() {

--
Regards,
Sean.

Re: [9] RFR (XXS): 8077054: DMH LFs should be customizeable

2015-04-09 Thread John Rose 
Looks good.  Would you please also check the number of distinct LFs compiled 
when running standard benchmarks?  (With and without the change.)  The number 
should go up, but only slightly.

Thanks!
— John

On Apr 9, 2015, at 11:44 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:
 
 http://cr.openjdk.java.net/~vlivanov/8077054/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8077054
 
 It's a followup fix for JDK-8069591 [1].
 
 As Charlie observed, it's important to customize DirectMethodHandles as well. 
 Otherwise, additional frame for DMH LambdaForm is created and it causes 
 observable peak performance regression in some situations (e.g. JRuby9K).
 
 Testing: manual (microbenchmark, compilation log inspection).
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 [1] https://bugs.openjdk.java.net/browse/JDK-8069591
 Customize LambdaForms which are invoked using
  MH.invoke/invokeExact
 ___
 mlvm-dev mailing list
 mlvm-...@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-09 Thread Rémi Forax 
Hi David,
The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l
i.WrongMethodTypeException uses MethodType.toString.

So if getSimpleName returns a blank string, you destroy the debuggability of 
any invokedynamic/methodhandle calls.

regards,
Rémi 

Le 9 avril 2015 04:52:15 CEST, David Holmes david.hol...@oracle.com a écrit :
Hi Vladimir,

On 9/04/2015 1:41 AM, Vladimir Ivanov wrote:
 http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk
 http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot
 https://bugs.openjdk.java.net/browse/JDK-8057919

 The logic to compute simple name (Class.getSimpleName()) for
 inner/nested/local classes is tightly coupled with Java naming scheme
 and sometimes fails for classes generated from non-Java code.

Meta-question: if this is non-Java code then what does/should 
simpleName even mean? Returns the simple name of the underlying
class 
as given in the source code. If there is no (java) source code does 
this have any meaning? Should it return  ?

 Instead of parsing class name and try to extract simple name based on
 JLS rules, the fix I propose is to use InnerClasses attribute from
the
 class file. Simple name is already recorded there.
 
 JVMS-4.7.6: The InnerClasses Attribute
 inner_name_index: If C is anonymous (JLS §15.9.5), the value of the
 inner_name_index item must be zero. Otherwise, the value of the
 inner_name_index item must be a valid index into the constant_pool
 table, and the entry at that index must be a CONSTANT_Utf8_info
 structure (§4.4.7) that represents the original simple name of C, as
 given in the source code from which this class file was compiled.

 Since I consider backporting the fix into 8u60, I'd like to hear
 opinions about backward compatibility of such change.

 As an alternative solution, I can restore original logic and consult
 InnerClasses attribute when class name parsing logic fails.

I think I'd prefer to see the VM call only used as a fallback if the 
regular parsing fails. That would prevent any compatibility issues for 
the 8u backport (ignoring tests that deliberately generate invalidly 
named classes).

Thanks,
David

 Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/

 Thanks!

 Best regards,
 Vladimir Ivanov

Re: RFR (XXS) : 8050123: Incorrect property name documented in CORBA InputStream API

2015-04-09 Thread Lance @ Oracle 
+1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad

 On Apr 9, 2015, at 9:42 AM, Seán Coffey sean.cof...@oracle.com wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8050123
 
 diff --git 
 a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java 
 b/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java
 --- a/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java
 +++ b/src/java.corba/share/classes/org/omg/CORBA_2_3/portable/InputStream.java
 @@ -77,7 +77,7 @@
  *
  * throw SecurityException if SecurityManager is installed and
  * enableSubclassImplementation SerializablePermission
 - * is not granted or jdk.corba.allowOutputStreamSubclass system
 + * is not granted or jdk.corba.allowInputStreamSubclass system
  * property is either not set or is set to 'false'
  */
 public InputStream() {
 
 -- 
 Regards,
 Sean.

Re: RFR: 8076090: jimage extract + recreate broken again

2015-04-09 Thread Jim Laskey (Oracle) 
Thanks Mandy.  Changed the main to ;

public static void main(String[] args) {
final String JAVA_HOME = System.getProperty(java.home);
Path jimagePath = Paths.get(JAVA_HOME, bin, jimage);
Path bootimagePath = Paths.get(JAVA_HOME, lib, modules, 
bootmodules.jimage);

if (Files.exists(jimagePath)  Files.exists(bootimagePath)) {
String jimage = jimagePath.toAbsolutePath().toString();
String bootimage = bootimagePath.toAbsolutePath().toString();
String extractDir = Paths.get(., 
extract).toAbsolutePath().toString();
String recreateImage = Paths.get(., 
recreate.jimage).toAbsolutePath().toString();

exec(new String[] {jimage, extract, --dir, extractDir, 
bootimage});
exec(new String[] {jimage, recreate, --dir, extractDir, 
recreateImage});

System.err.println(Test successful);
 } else {
System.err.println(Test skipped, no module image);
 }
}

Running jprt - okay to push after that?

Cheers,

-- Jim








 On Apr 8, 2015, at 3:37 PM, Mandy Chung mandy.ch...@oracle.com wrote:
 
 Forwarding to core-libs-dev for review (bcc jdk9-dev)
 
 On 4/8/2015 11:02 AM, Jim Laskey (Oracle) wrote:
 The fix addresses problem with the jimage tool rebuilding meta data on 
 windows systems (\ in path.)  Including new test to verify that jimage tool 
 does successfully extract and recreate.
 
 JBS: https://bugs.openjdk.java.net/browse/JDK-8076090
 Webrev: http://cr.openjdk.java.net/~jlaskey/8076090/webrev/index.html
 
 Looks fine to me.
 
 The test will need to check if $JAVA_HOME is an exploded image 
 ($JAVA_HOME/lib/modules not exists); if so, it should simply exit. Otherwise 
 the test will fail.   Nit: line 24 is not unused.
 
 FYI.  jdk/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java could be 
 used.
 
 Mandy

RFR 9: 8077350 Process API Updates Implementation Review

2015-04-09 Thread Roger Riggs 

Please review the API and implementation of the Process API Updates
described inJEP 102 https://bugs.openjdk.java.net/browse/JDK-8046092. 
Please  review and comment by April 23rd.


The recommendation to make ProcessHandle an interface is included
allowing the new functions to be extended by Process subclasses.
The implementation covers all functions on Unix, Windows, Solaris, and 
Mac OS X.


The API doc: http://cr.openjdk.java.net/~rriggs/ph-apidraft/

The webrev: http://cr.openjdk.java.net/~rriggs/webrev-ph

Issue: JDK-8077350 https://bugs.openjdk.java.net/browse/JDK-8077350 
Process API Updates Implementation


The code is in the jdk9 sandbox on branch JDK-8046092-branch.

Please review and comment, Roger

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-09 Thread Vladimir Ivanov 

David, thanks for the feedback!

Updated webrev:
  http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk
  http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot

I restored original logic and call into VM only if it fails.


The logic to compute simple name (Class.getSimpleName()) for
inner/nested/local classes is tightly coupled with Java naming scheme
and sometimes fails for classes generated from non-Java code.


Meta-question: if this is non-Java code then what does/should
simpleName even mean? Returns the simple name of the underlying class
as given in the source code. If there is no (java) source code does
this have any meaning? Should it return  ?
My reading of the JVMS is that InnerClasses attribute can be freely used 
by non-Java compilers to store simple names for classes they generate. 
The current wording for inner_name_index doesn't mention Java language.


Best regards,
Vladimir Ivanov


Instead of parsing class name and try to extract simple name based on
JLS rules, the fix I propose is to use InnerClasses attribute from the
class file. Simple name is already recorded there.

 

JVMS-4.7.6: The InnerClasses Attribute
inner_name_index: If C is anonymous (JLS §15.9.5), the value of the
inner_name_index item must be zero. Otherwise, the value of the
inner_name_index item must be a valid index into the constant_pool
table, and the entry at that index must be a CONSTANT_Utf8_info
structure (§4.4.7) that represents the original simple name of C, as
given in the source code from which this class file was compiled.

Since I consider backporting the fix into 8u60, I'd like to hear
opinions about backward compatibility of such change.

As an alternative solution, I can restore original logic and consult
InnerClasses attribute when class name parsing logic fails.


I think I'd prefer to see the VM call only used as a fallback if the
regular parsing fails. That would prevent any compatibility issues for
the 8u backport (ignoring tests that deliberately generate invalidly
named classes).

Thanks,
David


Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/

Thanks!

Best regards,
Vladimir Ivanov

Re: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

2015-04-09 Thread Vladimir Ivanov 

On 4/9/15 9:10 AM, Rémi Forax wrote:

Hi David,
The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l
i.WrongMethodTypeException uses MethodType.toString.

So if getSimpleName returns a blank string, you destroy the debuggability of 
any invokedynamic/methodhandle calls.
Debuggability is a different story. MethodType.toString() can produce 
ambiguous description, since it doesn't print all the details about the 
structure.


Right now, if a MethodType refers to a problematic class, 
MethodType.toString() throws an InternalError(Malformed class name).


Best regards,
Vladimir Ivanov



regards,
Rémi

Le 9 avril 2015 04:52:15 CEST, David Holmes david.hol...@oracle.com a écrit :

Hi Vladimir,

On 9/04/2015 1:41 AM, Vladimir Ivanov wrote:

http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk
http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot
https://bugs.openjdk.java.net/browse/JDK-8057919

The logic to compute simple name (Class.getSimpleName()) for
inner/nested/local classes is tightly coupled with Java naming scheme
and sometimes fails for classes generated from non-Java code.


Meta-question: if this is non-Java code then what does/should
simpleName even mean? Returns the simple name of the underlying
class
as given in the source code. If there is no (java) source code does
this have any meaning? Should it return  ?


Instead of parsing class name and try to extract simple name based on
JLS rules, the fix I propose is to use InnerClasses attribute from

the

class file. Simple name is already recorded there.

JVMS-4.7.6: The InnerClasses Attribute
inner_name_index: If C is anonymous (JLS §15.9.5), the value of the
inner_name_index item must be zero. Otherwise, the value of the
inner_name_index item must be a valid index into the constant_pool
table, and the entry at that index must be a CONSTANT_Utf8_info
structure (§4.4.7) that represents the original simple name of C, as
given in the source code from which this class file was compiled.

Since I consider backporting the fix into 8u60, I'd like to hear
opinions about backward compatibility of such change.

As an alternative solution, I can restore original logic and consult
InnerClasses attribute when class name parsing logic fails.


I think I'd prefer to see the VM call only used as a fallback if the
regular parsing fails. That would prevent any compatibility issues for
the 8u backport (ignoring tests that deliberately generate invalidly
named classes).

Thanks,
David


Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/

Thanks!

Best regards,
Vladimir Ivanov

Re: JDK-8060068/JDK-8067904 DriverManager clean-up introduces bootstrap problem that breaks production drivers

2015-04-09 Thread Robert Gibson 
Hi again,
I just realised that I missed an important bit from the test case in my earlier 
mail.
The jar file used for the test needs to contain, in addition to the class 
files, a text file called META-INF/services/java.sql.Driver containing the text
MyDriver
since it is the interaction between the driver being loaded manually and 
through the Service Provider mechanism which causes the dysfunction.
Regards,
Robert

On Friday, 3 April 2015, 14:07, Robert Gibson robbiexgib...@yahoo.com wrote:



Thanks Alan,
Note that the repro given in my mail is a bit simpler than the current defect 
description, especially if you don't have access to the MyFace JDBC driver.
Regards,
Robert 




On Friday, 3 April 2015, 13:04, Alan Bateman alan.bate...@oracle.com wrote:
On 03/04/2015 10:33, Robert Gibson wrote:
 Hi there,

 We are doing some early testing with JDK 9 and have discovered that the 
 changes made to java.sql.DriverManager back in November/December have 
 introduced an incompatibility with our JDBC driver (that we have used 
 unchanged since Java 6) when it is pre-loaded with Class.forName (as 
 recommended by Tomcat and specified as being harmless in the JavaDoc). We 
 filed a bug report but it got an incident ID JI-9019539 and then disappeared 
 into a black hole.

There does appear to be an issue with those changes. I've located the 
incident and moved it to the JDK project as JDK-8076639 [1].

-Alan




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