Re: RFR (JAXP): 8142463: Xml schema validation failing after Xerces update; maxOccurs ignored

Looks OK Joe Best Lance On Nov 30, 2015, at 2:33 PM, huizhe wang wrote: > Hi, > > This is a quick one-line fix. > > For the UPA [1] processing, the DFA was compacted. A flag > (fIsCompactedForUPA) was added to indicate whether the DFA was compacted. In > the previous

RE: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Hi Paul, >> Tests don't think we use testng with any hotspot tests so not sure >> about that part. > >There are already quite a few, primarily in the serviceability area, search >for “testng”. We don't use testng for our runtime tests, please change these into normal jtreg tests.

Re: RFR: JDK-8142936:Additional java.time.Duration methods

This is all about fixing a messy API that was created in 8. The methods propose are all about consistency. The toSeconds() method completes the set. For each unit there is a toXxx() and a toXxxPart(). Missing one out makes everything worse. Stephen On 30 November 2015 at 19:02, Roger Riggs

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. Thanks, Christian - Original Message - From: paul.san...@oracle.com Cc: hotspot-compiler-...@openjdk.java.net, core-libs-dev@openjdk.java.net Sent: Monday, November

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On 30 Nov 2015, at 22:17, Christian Tornqvist > wrote: > > Hi Paul, > > >>> Tests don't think we use testng with any hotspot tests so not sure >>> about that part. >> >> There are already quite a few, primarily in the serviceability area, search >>

Re: RFR:8143413:add toEpochSecond methods for efficient access

Converting LocalDate <-> java.util.Date is the question with the largest number of votes on SO: http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 The proposed method is designed to make the conversion easier. It also plugs an obvious gap in the API.

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On 29 Nov 2015, at 17:08, Alan Bateman wrote: > > On 27/11/2015 09:06, Paul Sandoz wrote: >> : >> >>> Also wondering how these tests will access jdk.internal once we're using >>> the modular image? >>> >> I believe it is sufficient to include: >> >> 28 *

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Aleksey, > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.05/ src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 669 final boolean sized; 670 final boolean exact; The fields can be declared private.

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, To complete my earlier reply: On 30/11/15 18:25, Daniel Fuchs wrote: If it can't be undeprecated what is the proper way to target support as low as JDK7 but might end up executing on JDK9? Well - a lib using LogRecord.getMillis() could use @SuppressWarnings("deprecation') when

PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi all, Our customers have to handle password-protected zip files. However, Java SE does not provide the APIs to handle it yet, so we must use third party library so far. Recently, we found JDK-4347142: "Need method to set Password protection to Zip entries", and we tried to implement it. The

Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant". I can see marking

RE: RFR 8124977 cmdline encoding challenges on Windows

Hi Kumar, Please find updated webreview here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.04/ Thanks, Vladimir. -Original Message- From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com] Sent: Sunday, November 22, 2015 8:14 AM To: Martin Sawicki Cc:

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:04, Jason Mehrens wrote: Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/2015 11:54, Chris Hegarty wrote: On 30/11/15 11:31, Claes Redestad wrote: On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up

Re: RFC: AbstractStringBuilder sharing its buffer with String

On 11/30/2015 03:19 PM, Vitaly Davidovich wrote: Hi Peter, I see your point about someone deliberately doing this to break String invariants. But by this logic, everything should be "threadsafe" in case someone attempts to break it via concurrency. Anything related to security, yes.

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

> On 25 Nov 2015, at 10:53, Paul Sandoz wrote: > > Hi, > > And this is the review for the Java part: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ > > Which will be updated to add @HotSpotIntrinsicCandidate when

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 2015-11-30 16:37, Alan Bateman wrote: On 30/11/2015 11:54, Chris Hegarty wrote: On 30/11/15 11:31, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8143926/webrev.03 This looks ok to me Claes. This version looks okay to me too although the /*package-private*/ comments are a

Re: Reference.reachabilityFence

On 30/11/15 12:41, Paul Sandoz wrote: On 30 Nov 2015, at 12:48, Chris Hegarty wrote: I looked at the jdk webrev, looks fine. Out of curiosity, what is the point of running the test with -Xint? Does it verify anything useful? It tests our assumptions are

Re: RFR:8143413:add toEpochSecond methods for efficient access

This is based on user difficulties picked up via Stack Overflow. These methods aim to provide a simpler and faster approach, particularly for cases converting to/from java.util.Date. For the time cases, the convention of 1970-01-01 is natural and commonly used in many codebases. Stephen On 30

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi Stephen, Nadeesh, The toXXXPart methods look fine. I'm not entirely convinced that the toSeconds() method is worth it and may be deemed as confusing with the new toSecondsPart method. How many people have problems with getSeconds()? The toXXXPart tests could have used a single

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:43, Roger Riggs wrote: Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Thanks Roger, Jason, I logged https://bugs.openjdk.java.net/browse/JDK-8144262 best regards, -- daniel Roger On 11/30/2015 12:25 PM, Daniel Fuchs wrote:

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Roger On 11/30/2015 12:25 PM, Daniel Fuchs wrote: On 30/11/15 18:04, Jason Mehrens wrote: Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps

Re: RFR:8143413:add toEpochSecond methods for efficient access

Hi, While it is kinda understandable to have LocalDate.toEpochSecond(...) to get the epoch seconds since 1970.1.1, with the assumption of the time is at the midnight of that day. It is strange to have the Local/OffsetTime to have two public methods with the assumption of the "date" is at epoch

Re: Deprecation of LogRecord.getMillis in JDK9

Sure. I'm just trying to pick a path forward so that in X years when someone does code review (like my future self) can avoid, "What was this guy thinking calling such a SUPERSEDED, DANGEROUS, and CONDEMNED method?" when confronted with using getMillis. I would assume JEP 277 would mark

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, On 30/11/15 18:57, Jason Mehrens wrote: Sure. I'm just trying to pick a path forward so that in X years when someone does code review (like my future self) can avoid, "What was this guy thinking calling such a SUPERSEDED, DANGEROUS, and CONDEMNED method?" when confronted with

Re: RFR:8143413:add toEpochSecond methods for efficient access

On 11/30/2015 10:37 AM, Stephen Colebourne wrote: This is based on user difficulties picked up via Stack Overflow. These methods aim to provide a simpler and faster approach, particularly for cases converting to/from java.util.Date. Can you be a little more specific on this one? We now have

RFR (JAXP): 8142463: Xml schema validation failing after Xerces update; maxOccurs ignored

Hi, This is a quick one-line fix. For the UPA [1] processing, the DFA was compacted. A flag (fIsCompactedForUPA) was added to indicate whether the DFA was compacted. In the previous update however, the line that set the flag was missed. This fix recovers the previous update. All tests

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: On 2015-11-25 02:54, Iris Clark wrote: Hi. Please review the new classes jdk.Version and jdk.OracleVersion. These are simple Java APIs to parse, validate, and compare version numbers. Bug 8072379: Implement

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Update: After some significant back-and-forth between Doug and I on naming and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what we think is a good spec and name selection for this thing. We're proposing to add a new static method to the Runtime class: class Runtime {

JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

Hi all, Would you please help to review the test development of JDK-8144215 : Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service. webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ Thank

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On 30 Nov 2015, at 23:05, Christian Tornqvist > wrote: > > Because jtreg is the test framework that we use, we've been working hard to > reduce the number of test frameworks in use. > jtreg comes bundled with testng so what is there to reduce? It’s being

Re: Deprecation of LogRecord.getMillis in JDK9

Hi all, Thanks for considering JEP 277 in this discussion. It's far from being finalized at this point, but SUPERSEDED seems like the most likely of the deprecation reasons from the proposal that would be applied here. While it seems that getMillis() is merely a convenience method for

Re: RFR:8143413:add toEpochSecond methods for efficient access

On 11/30/2015 01:26 PM, Stephen Colebourne wrote: Converting LocalDate<-> java.util.Date is the question with the largest number of votes on SO: http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 The proposed method is designed to make the

Re: [9] RFR of 8032027: Add BigInteger square root methods

Hi Joe, On Nov 29, 2015, at 10:01 AM, joe darcy wrote: > The "if (...) " logic that is repeated a few times in this method could be > pulled out into its own method, possibly one structured a bit differently to > return the number of errors. > > I think it would be

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On Wed, Nov 25, 2015 at 2:52 PM, wrote: > Have you looked anything at the performance of the generated code? No. I looked at the emitted code, saw 'MOVQDU' instruction being used (it was 'MOVQDA' before that resulted in alignment error), and concluded that

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hello, FYI, I've requested backport approval for this fix to 8u. http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-November/004540.html Best, Michael > Am 09.11.2015 um 16:28 schrieb Michael Haupt : > > ... thanks a lot, Peter and Vladimir! > > Best, > >

Re: Reference.reachabilityFence

I looked at the jdk webrev, looks fine. Out of curiosity, what is the point of running the test with -Xint? Does it verify anything useful? -Chris. On 26/11/15 16:22, Paul Sandoz wrote: Hi, I have updated the patches:

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/15 11:31, Claes Redestad wrote: On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up once/if these classes become properly

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/15 11:35, Peter Levart wrote: ... Wouldn't it be nice to offer this often needed functionality as a public API? It would fit naturally on the java.lang.Class as an instance method. I don't have a strong opinion either way on this. I'm ok with Claes proceeding with this bug as is. Any

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ Regards, Nadeesh TV On 11/27/2015 11:20 PM, Stephen Colebourne wrote: "Overall, looks pretty good. There a a number of double spaces that should be single spaces in the Javadoc. Change "This is based on

RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

Hi all, Would you please help to review for http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug https://bugs.openjdk.java.net/browse/JDK-8144214. Thank you -Hamlin

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 29/11/15 16:42, Claes Redestad wrote: On 2015-11-29 17:18, Alan Bateman wrote: On 29/11/2015 14:30, Claes Redestad wrote: On 2015-11-25 16:23, Aleksey Shipilev wrote: On 11/25/2015 06:14 PM, Claes Redestad wrote: Inlining the isPrimitive check should be enough to avoid extra comparisons:

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up once/if these classes become properly encapsulated? I see that BytecodeDescriptor has

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 11/30/2015 11:38 AM, Chris Hegarty wrote: On 29/11/15 16:42, Claes Redestad wrote: On 2015-11-29 17:18, Alan Bateman wrote: On 29/11/2015 14:30, Claes Redestad wrote: On 2015-11-25 16:23, Aleksey Shipilev wrote: On 11/25/2015 06:14 PM, Claes Redestad wrote: Inlining the isPrimitive

RFR:8143413:add toEpochSecond methods for efficient access

Hi all, Please review a fix for Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 Issue - add toEpochSecond methods for efficient access webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Aleksey, > Yes, thanks for more polishing, I have uploaded the updates to: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.06/ Maybe one more: 1342 Class[] cls = new Class[cnt]; 1343 for (int i = 0; i < cnt; i++) { 1344

Re: Reference.reachabilityFence

> On 30 Nov 2015, at 12:48, Chris Hegarty wrote: > > I looked at the jdk webrev, looks fine. > > Out of curiosity, what is the point of running the test with > -Xint? Does it verify anything useful? > It tests our assumptions are correct about the interpreter that

Re: RFC: AbstractStringBuilder sharing its buffer with String

Hi Peter, I see your point about someone deliberately doing this to break String invariants. But by this logic, everything should be "threadsafe" in case someone attempts to break it via concurrency. sent from my phone On Nov 28, 2015 7:19 PM, "Peter Levart" wrote: > >