Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread FELIX YANG
Chris, excuse me, I'm not a reviewer but have some questions. at line 209, classes is actually trying to resolve a path like "c:\jdk1.9.0\modules", which never exists in JDK directory. It should be "c:\jdk1.9.0\lib\modules". 207 if (home.resolve("lib").toFile().exists()) {

JDK 9 RFR of 8060077: Class.toGenericString specification doesn't mention array types

2015-01-14 Thread joe darcy
Hello, Please review these changes to address JDK-8060077 : Class.toGenericString specification doesn't mention array types http://cr.openjdk.java.net/~darcy/8060077.0/ Thanks, -Joe

Re: Explicit Serialization API and Security

2015-01-14 Thread Peter Firmstone
The following is a summary of our exploration so far: We have narrowed down to two options: A. constructors with static invariant check methods. B. Continue to use readObject(), we have a proposed solution to the final field problem and could modify the jvm to register for finalization lat

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Mandy Chung
On 1/14/2015 8:31 AM, Chris Hegarty wrote: On 14/01/15 16:18, Mandy Chung wrote: On 1/14/2015 8:04 AM, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/ Looks okay to me. In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were thinking to pass

Re: Explicit Serialization API and Security

2015-01-14 Thread Peter Levart
On 01/14/2015 12:37 PM, Chris Hegarty wrote: What do you think? I agree completely. An API at the level that you are proposing will provide the necessary functionality and flexibility that is required to do validation in readObject. As you clearly stated, and is already the case, validation

Re: Explicit Serialization API and Security

2015-01-14 Thread Peter Firmstone
It's only top down if there are intra class invariants, in this case invariants are checked more than once. This done simply because we can't move up the constructor call chain untill all child class invariants have been satisfied. For simpler class relationships, invariant check order is botto

Re: RFR: 5050783: Throwable convenience method: String getStackTraceString()

2015-01-14 Thread Ivan St. Ivanov
Hi Remi, I tried it and, well, the JDK image now does not even compile classes that contain lambda expressions: javac -cp . ./LambdaMetaFactoryTester.java Exception in thread "main" Exception: java.lang.BootstrapMethodError thrown from the UncaughtExceptionHandler in thread "main" With the old T

Re: RFR: 5050783: Throwable convenience method: String getStackTraceString()

2015-01-14 Thread Remi Forax
While using a lambda is cool in that context, if someone tries to do a printStackTrace in the LambdaMetafactory (for debugging purpose by example), it will be fun to debug. cheers, Rémi On 01/14/2015 08:25 PM, Ivan St. Ivanov wrote: Hi Claes, core libs developers, As promised, we did yesterd

Re: RFR: 5050783: Throwable convenience method: String getStackTraceString()

2015-01-14 Thread Ivan St. Ivanov
Hi Claes, core libs developers, As promised, we did yesterday our hackathon in the Bulgarian Java User Group and incorporated the feedback that we got from you. Here is our next webrev: http://dmitryalexandrov.net/~bgjug/5050783/webrev.01/ As you can see: - We got rid of the inner classes altog

Re: JDK 9 RFR of JDK-8068948: Update java.base module to use new try-with-resources statement

2015-01-14 Thread joe darcy
Hello, On 1/13/2015 11:53 PM, Ivan Gerasimov wrote: Hi! A useful change! I agree :-) We haven't publicized the change very much yet, but it is part of JEP 213, Milling Project Coin, (http://openjdk.java.net/jeps/213) and went into JDK 9's javac late in 2014. Might it also make sense to al

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Chris Hegarty
On 14/01/15 16:18, Mandy Chung wrote: On 1/14/2015 8:04 AM, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/ Looks okay to me. In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were thinking to pass "pool" to the CallerSensitiveFinder construct

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Mandy Chung
On 1/14/2015 8:04 AM, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/ Looks okay to me. In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were thinking to pass "pool" to the CallerSensitiveFinder constructor. Looks like some editing you mea

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Mandy Chung
On 1/14/2015 5:55 AM, Chris Hegarty wrote: This test currently completes successfully, but indicates that it has "Parsed 0 classfiles". It doesn't do anything useful. The modular image no longer contains jar files. The test should use the JRT FileSystem to iterate over the image classfiles.

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Chris Hegarty
Alan, Paul, Sometimes with these changes you do not want to cloud the significant body of the change with other refactoring. That said, we are on round two, so it seems reasonable. I think I have captured/addressed all comments: http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/

Re: HashMap collision speed (regression 7->8)

2015-01-14 Thread Peter Levart
Hi, Loosely related to this topic, there is some local variable caching of comparableClassFor() result already being performed inside iterative/recursive methods of TreeNode, but this caching is just positive caching, meaning that null return is not cached. For keys that happen to implement C

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

2015-01-14 Thread Konstantin Shefov
On 14.01.2015 15:56, Alan Bateman wrote: Did we establish if this requires a specification change to clarify the characters allowed in the host component? Here http://docs.oracle.com/javase/7/docs/api/java/net/Inet6Address.html#scoped we can see that "The scope_id refers to an interface on th

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Paul Sandoz
On Jan 14, 2015, at 2:55 PM, Chris Hegarty wrote: > This test currently completes successfully, but indicates that it has "Parsed > 0 classfiles". It doesn't do anything useful. > > The modular image no longer contains jar files. The test should use the JRT > FileSystem to iterate over the im

Re: RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Alan Bateman
On 14/01/2015 13:55, Chris Hegarty wrote: This test currently completes successfully, but indicates that it has "Parsed 0 classfiles". It doesn't do anything useful. The modular image no longer contains jar files. The test should use the JRT FileSystem to iterate over the image classfiles. h

Re: Explicit Serialization API and Security

2015-01-14 Thread Chris Hegarty
On 14/01/15 12:58, Peter Firmstone wrote: Hi Chris, Sorry, no. Currently when an ObjectStreamClass is read in from the stream, the framework searches for the first zero arg constructor of a non serializable class and creates and instance of the class read and resolved from the stream, however i

RFR 8061297 : sun/reflect/CallerSensitive/CallerSensitiveFinder.java should use the JRT FileSystem

2015-01-14 Thread Chris Hegarty
This test currently completes successfully, but indicates that it has "Parsed 0 classfiles". It doesn't do anything useful. The modular image no longer contains jar files. The test should use the JRT FileSystem to iterate over the image classfiles. http://cr.openjdk.java.net/~chegar/8061297/w

Re: Explicit Serialization API and Security

2015-01-14 Thread Peter Firmstone
Hi Chris, Sorry, no. Currently when an ObjectStreamClass is read in from the stream, the framework searches for the first zero arg constructor of a non serializable class and creates and instance of the class read and resolved from the stream, however it does so using a super class constructor

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

2015-01-14 Thread Alan Bateman
On 14/01/2015 11:14, Konstantin Shefov wrote: Kindly reminder Did we establish if this requires a specification change to clarify the characters allowed in the host component? -Alan

Re: Explicit Serialization API and Security

2015-01-14 Thread Chris Hegarty
On 13/01/15 00:51, Peter Firmstone wrote: - Original message - > On 10/01/15 07:00, Peter Firmstone wrote: > > Again, thank you all for engaging in discussion of this very difficult > > topic. > > > > While we can't presently check intra object dependencies during > > deserializatio

Re: Explicit Serialization API and Security

2015-01-14 Thread Chris Hegarty
On 13/01/15 10:00, Peter Levart wrote: Hi Chris, I stepped back and asked myself what problem(s) we are searching solution(s) for and tried to see how existing API solves or doesn't solve them. I think that existing readObject() + GetFields API already solves most of the problems discussed so fa

Re: Explicit Serialization API and Security

2015-01-14 Thread Chris Hegarty
Peter F, I am still struggling with the basic concept of you proposal. Let me see if I understand it correctly. Does the following describe a similar scenario as you envisage: 1) For each Serializable type, T, in the deserialized types hierarchy, starting with the top most ( closest to j

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

2015-01-14 Thread Konstantin Shefov
Kindly reminder On 12.01.2015 17:37, Konstantin Shefov wrote: Hello, Chris You have asked "Have you seen NetworkInterface.getName() return names with ‘_’, ’.’, or ‘:’ ,or is this theoretical?" I can answer your question. I have named one of network interfaces on my Linux desktop like "eth0.

Re: JDK 9 RFR of JDK-8068948: Update java.base module to use new try-with-resources statement

2015-01-14 Thread Alan Bateman
On 14/01/2015 02:46, joe darcy wrote: Hello, Earlier in JDK 9, a language change was made so that if a resource for a try-with-resources statement is already final or effectively final, a new resource variable does *not* need to be declared to manage the variable. The java.base module shoul