Re: JDK 9 RFR of 8059175: Zero BigDecimal with negative scale prints leading zeroes in String.format

Catching up on reviews, the change looks fine. Cheers, -Joe On 12/23/2014 3:27 PM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8059175 Patch: http://cr.openjdk.java.net/~bpb/8059175/webrev.00/ In java.util.Formatter.BigDecimalL

Re: JDK 9 RFR of 6481080 : (ann) @Deprecated annotation has no effect on packages

Hi joe, The update is clear Best Lance 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 Jan 6, 2015, at 6:12 PM, joe darcy wrote: > > Hello, > > As part of cle

JDK 9 RFR of 6481080 : (ann) @Deprecated annotation has no effect on packages

Hello, As part of cleaning up the deprecation facility in 9, please review this change to document when a @Deprecated annotation is a no-op: 6481080 : (ann) @Deprecated annotation has no effect on packages http://cr.openjdk.java.net/~darcy/6481080.0/ Since the @Deprecated feature was

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Thanks, I will update it. Tristan > On Jan 6, 2015, at 2:27 PM, huizhe wang wrote: > > > On 1/6/2015 2:25 PM, Lance Andersen wrote: >> One more thing :-) >> >> Remember to update your copyright year to 2015 also > > Indeed, that applies to my webrevs as well :-) > > Joe > >> >> Best >> Lan

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

On 1/6/2015 2:25 PM, Lance Andersen wrote: One more thing :-) Remember to update your copyright year to 2015 also Indeed, that applies to my webrevs as well :-) Joe Best Lance On Jan 6, 2015, at 5:04 PM, Lance Andersen > wrote: On Jan 6, 2015, at 4:31

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

One more thing :-) Remember to update your copyright year to 2015 also Best Lance On Jan 6, 2015, at 5:04 PM, Lance Andersen wrote: > > On Jan 6, 2015, at 4:31 PM, Tristan Yan wrote: > >> Thank you Lance and Joe. > > You are very welcome. >> I am working on the fix. > > No rush from my per

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

On Jan 6, 2015, at 4:31 PM, Tristan Yan wrote: > Thank you Lance and Joe. You are very welcome. > I am working on the fix. No rush from my perspective, have a lot to keep me busy in the interim before your next webrev . :-) > it may take a couple of days that the code needs some refactor. Und

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Thank you Lance and Joe. I am working on the fix. it may take a couple of days that the code needs some refactor. I will send out next review once I finish it. Thanks Tristan > On Jan 6, 2015, at 1:22 PM, huizhe wang wrote: > > Thanks for taking the initiative and effort to refactor and clean u

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Thanks for taking the initiative and effort to refactor and clean up all of the Functional tests in previous changeset! We've gone through several iterations for the new ones (xslt tests). I totally agree with Lance, it looks very good overall, a lot better than its original form. It's nice

Re: RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry

And here's the update: http://cr.openjdk.java.net/~igerasim/8067951/6/webrev/ As you suggested, the psCount is calculated in the first loop along the way. Another change is that a quotation mark is used as the new path separator. I also thought it's better to add a short comment, as now it may l

Re: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

I only looked at test, looks good to me. I'd rarely ask to remove extra prints in tests. It adds initial debugging data points in case something breaks down the road. Brad On 1/4/2015 8:25 AM, Peter Levart wrote: Hi Brad, So I created another webrev (just removed the unneeded import and l

Re: RFR: JDK-8051563: Convert JAXP function tests in xslt components: : org.apache.qetest.dtm package, org.apache.qetest.trax package to openjdk

Hi Tristan, Sorry for the delay but with the holidays and the number of files, it took a while to go through :-) Overall, it looks pretty good. A couple of suggestions, but I would not necessarily hold back from committing: - For tests where you are not caring about the actual exception that

Re: RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry

Hi Ivan, Yes, it looks better and should run faster as it doesn't need to worry about quote in second loop. I was a little hesitated when suggested to replace the ps with 0, though I'm pretty much sure a \u should never be a legal character in a windows' path :-) Anyone can think about any

Re: Explicit Serialization API and Security

On 01/06/2015 06:21 PM, Chris Hegarty wrote: On 6 Jan 2015, at 15:06, Peter Levart wrote: On 01/06/2015 04:03 PM, Peter Levart wrote: private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { ObjectInputStream.GetField fields = in.readFields(); // thi

Re: Explicit Serialization API and Security

On 6 Jan 2015, at 15:06, Peter Levart wrote: > On 01/06/2015 04:03 PM, Peter Levart wrote: >> private void readObject(ObjectInputStream in) throws IOException, >> ClassNotFoundException { >>ObjectInputStream.GetField fields = in.readFields(); // this already >> validates the types >

Re: Explicit Serialization API and Security

On 01/06/2015 04:03 PM, Peter Levart wrote: private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { ObjectInputStream.GetField fields = in.readFields(); // this already validates the types Well, not true currently. But type validation could be added

Re: Explicit Serialization API and Security

Hi Chris, On 01/06/2015 12:10 PM, Chris Hegarty wrote: On 6 Jan 2015, at 07:27, Peter Levart wrote: Hi Brian, On 01/05/2015 09:51 PM, Brian Goetz wrote: Thanks Peter(s): I think it's just about time to re-sync on the goals, since there are an infinitude of issues with serialization, only som

Re: RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry

Hi Sherman! I took your suggestion and rewrote the method to moved the logic, which removes the quotes to the top. I think the code became cleaner, so thank you for suggestion! Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8067951/5/webrev/ Sincerely yours, Ivan On 06.01.2

Re: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec is not completely consistent with the rest of the API

+1 On Jan 6, 2015, at 3:58 AM, A. Sundararajan wrote: > > > > Forwarded Message > Subject: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec > is not completely consistent with the rest of the API > Date: Tue, 06 Jan 2015 13:27:40 +0530 > From: A. Sundar

Re: RFR: 8067951: System.loadLibrary cannot find library when path contains quoted entry

Hi Alan! I'm not sure why it would be an improvement to make it a method. As Roger said, with a final variable, the compiler is able to eliminate dead code altogether. I think, if later there's a need to make the decision dynamic/overridable, it can be easily changed, as it's not part of pub

Re: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec is not completely consistent with the rest of the API

Thanks. Broke that sentence into two for clarity. -Sundar On Tuesday 06 January 2015 04:46 PM, Alan Bateman wrote: On 06/01/2015 07:57, A. Sundararajan wrote: Please review http://cr.openjdk.java.net/~sundar/8068462/ for https://bugs.openjdk.java.net/browse/JDK-8068462 I think this is okay a

Re: Explicit Serialization API and Security

On 6 January 2015 at 11:46, Chris Hegarty wrote: > With shallow/no hierarchies, and others, the serialization proxy pattern > works quite well. The overhead of course being the creation of the proxy > itself, but this is typically a minimal container with just the state needed > to create the “

Re: Explicit Serialization API and Security

On 6 Jan 2015, at 11:13, Stephen Colebourne wrote: On 6 January 2015 at 10:25, Chris Hegarty wrote: >> On 6 Jan 2015, at 08:31, Stephen Colebourne wrote: >>> I've thought on a number of occasions that what I wanted from >>> serializable was a merger of readObject and readResolve >>> >>> private

Re: Explicit Serialization API and Security

On 5 Jan 2015, at 20:51, Brian Goetz wrote: > Thanks Peter(s): I think it's just about time to re-sync on the goals, since > there are an infinitude of issues with serialization, only some of which we > can address. > > To that end, let me toss out some of the results of our recent exploration

Re: Explicit Serialization API and Security

- Original message - > > > On 5/01/2015 6:51 PM, Peter Firmstone wrote: > > > > Thanks Dave, > > > > > > > > That's another way of checking invariants, you could expose A's > > > > check method but you'd also need a couple of additional static > > > > methods to obtain integers upper and l

Re: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec is not completely consistent with the rest of the API

On 06/01/2015 07:57, A. Sundararajan wrote: Please review http://cr.openjdk.java.net/~sundar/8068462/ for https://bugs.openjdk.java.net/browse/JDK-8068462 I think this is okay and doesn't require an update to JSR 223. One suggestion (feel free to ignore) to to split the sentence into two so t

Re: Explicit Serialization API and Security

On 6 January 2015 at 10:25, Chris Hegarty wrote: > On 6 Jan 2015, at 08:31, Stephen Colebourne wrote: >> I've thought on a number of occasions that what I wanted from >> serializable was a merger of readObject and readResolve >> >> private Object readObjectAndResolve(ObjectInputStream in) throws

Re: Explicit Serialization API and Security

On 6 Jan 2015, at 07:27, Peter Levart wrote: Hi Brian, > > On 01/05/2015 09:51 PM, Brian Goetz wrote: >> Thanks Peter(s): I think it's just about time to re-sync on the goals, since >> there are an infinitude of issues with serialization, only some of which we >> can address. >> >> To that end

Re: Explicit Serialization API and Security

On 6 Jan 2015, at 08:31, Stephen Colebourne wrote: > On 6 January 2015 at 07:27, Peter Levart wrote: >> readObject() can be used on both ends of the spectrum or anywhere >> in-between. It can be used for explicit deserialization or just for >> validation of default deserialized state. Would sepa

Re: String.indexOf optimization

Hi, On 05/01/15 18:59, Zoltan Sziladi wrote: > This discussion was a long time ago, I was just reading through it to check > again what was the last state of the discussion about the String.indexOf. > There is one part which I still do not understand, hopefully someone could > shed some light on

Re: Explicit Serialization API and Security

On 6 January 2015 at 07:27, Peter Levart wrote: > readObject() can be used on both ends of the spectrum or anywhere > in-between. It can be used for explicit deserialization or just for > validation of default deserialized state. Would separate validation method > give us anything more or simplify