Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

thanks Roger ... will reduce the focus of the test regards Mark On 09/06/2016 15:58, Roger Riggs wrote: Hi Mark, With respect to the test, it seems to do a lot more than just be the test for the current issue. Perhaps some javadoc in the test could identify the the important parts of the

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

OK I'll look into this again. I'll remove and re check everything. The reason why is that during the execution of the tests there where various problems where there is attempt in java.base to access sun.corba.BridgePermission at one stage there were failure such as

Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hello, I find the "concurrent/synchronous" comment a bit confusing. How about: # Number of attempts to obtain lock file in FileHandler # Implemented by incrementing the %u placeholder as documented # in FileHandler Javadoc In the test I would add a comment "200 raises the default limit of

Re: New jtreg test about StackWalker's JDK-8147039 and JDK-8156073: qword decoding from frame locals

Hi, I'm attaching an updated test: now it also perform assertions about stack operands (they seem to behave like locals). I also converted it to "testng/othervm" with a data provider for several "StackWalker" option combinations. Thanks, -- Fabio Tudone On 06/07/2016 05:18 AM, Mandy Chung

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Thanks Sean, I'll incorporate your amendments wrt static ports, it is a problems, but for these test one that is unavoidable ConcurrentHashMapTest incurs intermittent failures due to port already in use issue. I'll make a change for a bug against this, in the near future, to overcome and

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi Mark, With respect to the test, it seems to do a lot more than just be the test for the current issue. Perhaps some javadoc in the test could identify the the important parts of the test as opposed to the supporting infrastructure. If there is more code than is needed for this issue then

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi Chris, thanks for the feedback yes, that's correct the granting of the all permissions to corba, allows this solution to work. Without all permission the RuntimePermission accessDeclaredField is needed and the doPrivilege is redundant, but the module-info export is needed. It is possible

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Thanks Seán! On 09.06.2016 17:22, Seán Coffey wrote: Looks fine to me Ivan. Nice find. Regards, Sean. On 09/06/2016 14:52, Ivan Gerasimov wrote: Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with

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

Hi, The patch for this issue is a result of the following discussion on mlvm-dev list: http://mail.openjdk.java.net/pipermail/mlvm-dev/2016-May/006602.html I propose the following improvement to the implementation of ClassValue API:

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot ...

Hi Paul, The blog entry specifically referred to the original java.util.Date API. JSR 310[1] (java.time) from its inception made the design choice to simplify the API and rely on operating systems to provide a stable and smooth time without leapseconds. The definition of the time scales used

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Thanks Roger! On 09.06.2016 17:17, Roger Riggs wrote: +1 Roger On 6/9/2016 9:52 AM, Ivan Gerasimov wrote: Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with Arrays.hashCode(char/byte[]). The regression test

Re: RFR: 9: 8158274: ProblemList java/nio/file/Files/probeContentType/Basic.java on solaris-sparc

Hello, I agree it would be helpful if the test handled this failure condition with a more informative message. Thanks, -Joe On 6/9/2016 7:31 AM, Roger Riggs wrote: Hi, It might be worthwhile to add code to the test to check the GNOME configuration and skip the test if incorrect. At the

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Roger, what should I make of this announcement then? [1] A quote from it: "Although the Java API defines a second as a number between 0 and 61 to accommodate leap seconds, some applications may have taken short-cuts to assume that there are 60 seconds in a minute or 86400 seconds in a day.

Re: RFR: 9: 8158274: ProblemList java/nio/file/Files/probeContentType/Basic.java on solaris-sparc

Hi, It might be worthwhile to add code to the test to check the GNOME configuration and skip the test if incorrect. At the least the failure of the test could pinpoint the configuration error. Misconfigured systems will continue to exist and quickly identifying them would save time on

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

> On 9 Jun 2016, at 15:18, Roger Riggs wrote: > > Hi Mark, > > IIOPInputStream.java: > > - Does adding doPriv overhead to every field access have a noticeable impact > on performance? > If most of the fields are accessible or can easily be checked as being in > the

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Looks fine to me Ivan. Nice find. Regards, Sean. On 09/06/2016 14:52, Ivan Gerasimov wrote: Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with Arrays.hashCode(char/byte[]). The regression test confirms that the

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Oh BTW, I assume the changes to the java.corba module-info are not needed right? Maybe left over from some debugging? -Chris. > On 9 Jun 2016, at 13:35, Chris Hegarty wrote: > > >> On 8 Jun 2016, at 23:18, Mark Sheppard wrote: >> >> >> Hi

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi Mark, IIOPInputStream.java: - Does adding doPriv overhead to every field access have a noticeable impact on performance? If most of the fields are accessible or can easily be checked as being in the base module, I could see trying the access directly and catching the security

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

+1 Roger On 6/9/2016 9:52 AM, Ivan Gerasimov wrote: Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with Arrays.hashCode(char/byte[]). The regression test confirms that the change is good. With kind regards, Ivan

Re: [jdk9] RFR: 8158802: com.sun.jndi.ldap.SimpleClientId produces wrong hash code

Could someone please help review this? The essential part of the fix is quite simple: i.e. replacing char/byte[].hashCode() with Arrays.hashCode(char/byte[]). The regression test confirms that the change is good. With kind regards, Ivan On 06.06.2016 19:58, Ivan Gerasimov wrote: Hello!

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Paul, Right, java.time cannot represent time with that precision. Roger On 6/8/2016 6:37 PM, Paul Benedict wrote: So does that mean you can't use Java to represent a snapshot (instant) in the past where a leap second existed? On Jun 8, 2016 4:17 PM, "Roger Riggs"

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hey Mark, Looks fine. A few comments. 2291 Class declaredFieldClass = declaredClassField.getType(); 2292 2293 if (declaredFieldClass == null) { 2294 continue; 2295 } I'm not sure if this check is

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Java is like many other systems, it uses a single count of seconds since a fixed epoch 1970-01-01 ignoring leap seconds (86400 second days). Such a representation cannot store a representation of a past leap second. But this thread is about offsets, which are completely unaffected by this! Stephen

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

"absHours / 10 > 0" would be simpler as "absHours >= 10" Around line 3595 we have boolean paddedHour = isPaddedHour(); but 6 lines down isPaddedHour() is used, not the local variable There is an extra space in the message here: new DateTimeException(" Value out of Range also, I'd use "range",

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Roger, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.07/ Thanks and regards, Nadeesh On 6/9/2016 2:36 AM, Roger Riggs wrote: HI Nadeesh, Looking better DateTimeFormatterBuilder: - line 3678: If array[1] == 24, offsetSeconds will

Re: RFR: 9: 8158274: ProblemList java/nio/file/Files/probeContentType/Basic.java on solaris-sparc

On 09/06/2016 01:26, Rajan Halade wrote: Thanks Joe! I see only following exception in jtr so it's hard to know that it is due to machine misconfiguration. I've looked at the logs and it seems to be an issue with the GNOME configuration. No issue excluding it for now but we need to track down

Re: RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

Hi Shilpi, I will be happy to sponsor the push. Best, Michael > Am 07.06.2016 um 11:39 schrieb shilpi.rast...@oracle.com: > > Thanks Joseph!! > Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.05/ > > Regards, > Shilpi > > On 6/7/2016 6:00 AM, Joseph D. Darcy wrote: >> Hello,

Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi Ramanand, Thanks for the updated. I still have some remarks: FileHandler.java: 98 *specifies the maximum number of concurrent locks hold by 99 *FileHandler (defaults 100). Is the verb form correct: hold => held ? logging.properties: 42 # when the unique field %u