Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

I'm actually very happy that we've dropped private patches against libz. And using the system libz seems like the right thing to do on Unix systems, where libz should be ubiquitous. On Wed, Feb 10, 2016 at 4:25 PM, Xueming Shen wrote: > > One of the benefits of moving to the system libz is actua

Re: RFR: jsr166 jdk9 integration wave 4

and ... webrev regenerated On Wed, Feb 10, 2016 at 3:32 PM, Martin Buchholz wrote: > The specdiff is very helpful. It was much easier to see that the > cross-method links from whenComplete to handle could be improved, so > we'll change (modulo reflow) > > --- src/main/java/util/concurrent/Comple

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

One of the benefits of moving to the system libz is actually for better/easy maintenance. Just replacing the offending version of libz with an earlier/later version that works, instead of waiting for a customized jdk/jre image with a working/bundled libz, or the next update release. Especially gi

Re: RFR: jsr166 jdk9 integration wave 4

The specdiff is very helpful. It was much easier to see that the cross-method links from whenComplete to handle could be improved, so we'll change (modulo reflow) --- src/main/java/util/concurrent/CompletionStage.java 24 Jan 2016 21:22:16 - 1.37 +++ src/main/java/util/concurrent/CompletionSta

Re: RFR: jsr166 jdk9 integration wave 4

> On 10 Feb 2016, at 15:53, Martin Buchholz wrote: > > Thanks for creating the specdiff, but ... it looks reversed; the green > is the old and the red is the new! D’oh, of course. Updated in-place. http://cr.openjdk.java.net/~chegar/jsr166-jdk9-integration-CompletableFuture/CompletionStage.htm

Re: RFR 9: 8142539 : Incorrect definition of ZoneOffset.MIN and other javadoc cleanup

The plusHours() change loses something in the fix. previously, it had an example for summer-to-summer, summer-to-winter, and winter-to-winter. Now the last of these has gone. This would be better: Adding one hour to 01:30+02:00 will result in 02:30+02:00 (both in summer time) Adding one hour to 02

Re: OpenJDK bug question (JDK-6519463)

On 10/02/2016 11:53 PM, David Hoffer wrote: No that file is not visible to me either. Should be now. David -Dave On Tue, Feb 9, 2016 at 9:56 PM, David Holmes mailto:david.hol...@oracle.com>> wrote: On 10/02/2016 2:20 PM, David Hoffer wrote: That issue has the same problem, it

Re: RFR 9: 8142539 : Incorrect definition of ZoneOffset.MIN and other javadoc cleanup

Looks OK Roger On Feb 10, 2016, at 3:25 PM, Roger Riggs wrote: > 8139529 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com

RFR 9: 8142539 : Incorrect definition of ZoneOffset.MIN and other javadoc cleanup

Please review a trio of javadoc fixes for java.time. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-typos-8142539/ Issues: 8142539: Incorrect definition of ZoneOffset.MIN 8140211: Example in the Documentation is wrong for java.time.ZonedDateTime.minusHours 8139529: java.time.tem

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

There's an endless debate about the pros and cons of "dynamic linking". I think it would be best for the JDK to link to system libraries by default, if possible. For a particular JDK image, one can drop a patched libz into a suitable lib directory to override the system one. It should also be rel

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

On 2016-02-10 02:03, Paul Sandoz wrote: On 10 Feb 2016, at 04:42, Mikael Vidstedt wrote: Can I please get a quick review of these updated webrevs: hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/ jdk: http://cr.openjdk.java.net/~mikael/webrevs/8141491/w

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

I've miss the fact that you call getName() after defineAnonymousClass. So you're right that each class has a different name but calling the dumper after calling defineAnonymousClass is a mistake in my opinion because you are not able to debug verification errors that will be raised by defineAnon

Re: Compact Strings and APIs for fast decoding of string data

On 02/10/2016 02:16 PM, Chris Vest wrote: I’m slightly more worried about their array and what it implies, though. This API requires of me that I’m able to present all of the relevant buffers up front. In my case, these buffers are shared between multiple threads, so they are guarded by locks

Re: RFR: jsr166 jdk9 integration wave 4

Thanks for creating the specdiff, but ... it looks reversed; the green is the old and the red is the new! Sorry for our "endless fiddling"; we do have future changes in mind, but no spec changes. On Wed, Feb 10, 2016 at 2:50 AM, Chris Hegarty wrote: > On 02/02/16 15:23, Martin Buchholz wrote: >>

Re: Compact Strings and APIs for fast decoding of string data

Hi Chris and others, On 02/10/2016 02:16 PM, Chris Vest wrote: It’d be a shame to loose the no-zeroing optimisation, so if that requires a constructor, then lets find a constructor. To recap, I have possibly multiple buffers and I only want to use parts of each. So with the composed buffer I’

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 10/02/16 14:29, Alan Bateman wrote: On 10/02/2016 13:57, Seán Coffey wrote: I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

I've uploaded testcase here: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java Yasumasa On 2016/02/10 23:34, Yasumasa Suenaga wrote: Hi Sherman, I've refactored a patch for this enhancement: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/ 1. I change

Re: [PING] PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi Sherman, I've refactored a patch for this enhancement: http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/ 1. I changed ZipCryption and implementation class to package private. 2. Encryption / Decryption key is allowed passphrase string. 3. I added passphrase and validation m

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 10/02/2016 13:57, Seán Coffey wrote: I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least conside

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10.02.2016 17:07, Chris Hegarty wrote: > Thanks Aleksey, your proposal is better. So the complete change is: > > diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java > b/src/java.base/share/classes/java/io/ObjectInputStream.java > --- a/src/java.base/share/classes/java/io/Obj

Re: Compact Strings and APIs for fast decoding of string data

> On 10 Feb 2016, at 14:16, Chris Vest wrote: > > It’d be a shame to loose the no-zeroing optimisation, so if that requires a > constructor, then lets find a constructor. > > To recap, I have possibly multiple buffers and I only want to use parts of > each. So with the composed buffer I’d hav

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10/02/16 13:57, Aleksey Shipilev wrote: Um (Integer.MAX_VALUE + 1L) is still a positive long, you probably want: int ilen = (int)utflen; if (ilen < 0) return ""; int initialCapacity = Math.min(ilen, 16384); ...or: if (utflen < 0 || utflen > Integer.MAX_INT) ret

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 10.02.2016 16:51, Chris Hegarty wrote: > On 08/02/16 21:54, Aleksey Shipilev wrote: >> ... >> Still, the corrupted stream may call readUTFBody(1L + >> Integer.MAX_VALUE), that yields initial capacity of -2147483648, which >> in turn fails StringBuilder(...) with NegativeArraySizeException. But I

Re: RFR: JDK-8031767 Support system or alternative implementations of zlib

On 08/02/16 09:55, Alan Bateman wrote: On 08/02/2016 10:42, Seán Coffey wrote: Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries. JD

Re: OpenJDK bug question (JDK-6519463)

No that file is not visible to me either. -Dave On Tue, Feb 9, 2016 at 9:56 PM, David Holmes wrote: > On 10/02/2016 2:20 PM, David Hoffer wrote: > >> That issue has the same problem, it references files that are not in the >> bug report so it won't help, really need all files to be attached to

Re: RFR [9]8134424: BlockDataInputStream.readUTFBody: examine sizing local StringBuffer with the given length

On 08/02/16 21:54, Aleksey Shipilev wrote: ... Still, the corrupted stream may call readUTFBody(1L + Integer.MAX_VALUE), that yields initial capacity of -2147483648, which in turn fails StringBuilder(...) with NegativeArraySizeException. But I wonder if that is actually a valid UTF8 input, becaus

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Thanks guys, pushed. -Aleksey On 10.02.2016 16:19, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 2/10/16 3:51 PM, Aleksey Shipilev wrote: >> See new webrev that adds a few more tests: >> http://cr.openjdk.java.net/~shade/8149459/webrev.02/ >> >> On 10.02.2016

Re: [PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

Hi Ramanand! Your fix looks good to me. I'm forwarding your request to net-...@openjdk.java.net which is probably more appropriate to review this fix. It would be good, if net-dev people can confirm they're Okay with the fix. Sincerely yours, Ivan On 10.02.2016 10:08, Ramanand Patil wrote:

Re: RFR (S): 8149529: Adapt SAP copyrights to new company name in jdk repository

Thanks Chris! On Wed, Feb 10, 2016 at 12:30 PM, Chris Hegarty wrote: > On 10/02/16 11:15, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for this boring change which simply changes >> all the SAP copyright messages from "SAP AG" to "SAP SE". The reason >> for this change is tha

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Looks good. Best regards, Vladimir Ivanov On 2/10/16 3:51 PM, Aleksey Shipilev wrote: See new webrev that adds a few more tests: http://cr.openjdk.java.net/~shade/8149459/webrev.02/ On 10.02.2016 14:25, Remi Forax wrote: Hi Aleksey, if you have a dumper, you should append a value at the end

Re: Compact Strings and APIs for fast decoding of string data

It’d be a shame to loose the no-zeroing optimisation, so if that requires a constructor, then lets find a constructor. To recap, I have possibly multiple buffers and I only want to use parts of each. So with the composed buffer I’d have to first extract view buffers and then compose those, so I

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

> On 10 Feb 2016, at 13:51, Aleksey Shipilev > wrote: > > See new webrev that adds a few more tests: > http://cr.openjdk.java.net/~shade/8149459/webrev.02/ > +1 Paul.

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

> 2016-02-08 15:05 GMT+01:00 Paul Sandoz : > >> On 8 Feb 2016, at 14:53, Tagir F. Valeev wrote: >> >> PS> Why don’t you check if "buffer == null” at #189? i.e. similar to >> forEachRemaining: >> >> That would make minimal behavioral change to fix this issue (fix >> flatMap keys only, but not affe

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

See new webrev that adds a few more tests: http://cr.openjdk.java.net/~shade/8149459/webrev.02/ On 10.02.2016 14:25, Remi Forax wrote: > Hi Aleksey, if you have a dumper, you should append a value at the > end of the generated class otherwise if you have more than one string > concatenation, you

Re: New Collection framework?

On 10/02/16 12:55, Remi Forax wrote: Java 8 to the rescue :) The problem you have is that you don't know if the list is the result of a calculation or if it reflect an internal state thus has to be immutable. The idea is not to use the interface List in both cases, the result of a calculation

Re: ObjectInputStream SPI

Thanks Chris, Over the last year I've been working on reimplimenting OIS, I've been able to retain serial form compatibility, but have made some changes to deserialization api. With the reimpl, existing Serializable objects that are stateless or those with only primitive fields are allowed to

RE: RFR (S): 8149529: Adapt SAP copyrights to new company name in jdk repository

Hi Volker, thanks for doing this tedious change :) It looks good, I checked these are all. Best regards, Goetz > -Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: Mittwoch, 10. Februar 2016 12:15 > To: Java Core Libs > Cc: Lindenmaier, Goetz > Subje

Re: New Collection framework?

- Mail original - > De: "Stanislav Baiduzhyi" > À: core-libs-dev@openjdk.java.net > Envoyé: Mercredi 10 Février 2016 12:17:48 > Objet: Re: New Collection framework? > > On 10/02/16 05:03, David Holmes wrote: > >> * The main Collection interface allowes too much. If you get a > >> Collecti

Re: RFR (S): 8149529: Adapt SAP copyrights to new company name in jdk repository

On 10/02/16 11:15, Volker Simonis wrote: Hi, can I please have a review for this boring change which simply changes all the SAP copyright messages from "SAP AG" to "SAP SE". The reason for this change is that SAP changed from a German stock corporation (AG) to a European one (SE). http://cr.ope

Re: RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Hi Aleksey, if you have a dumper, you should append a value at the end of the generated class otherwise if you have more than one string concatenation, you will see only one class on the disk. regards, Rémi - Mail original - > De: "Aleksey Shipilev" > À: "Java Core Libs" > Envoyé: Me

Re: New Collection framework?

On 10/02/16 05:03, David Holmes wrote: * The main Collection interface allowes too much. If you get a Collection and you should not modify it, your programm will either behave stragly with a hard to detect bug, or crash with some kind of UnsupportedOperationException, when you do it. I have my pr

RFR (S): 8149529: Adapt SAP copyrights to new company name in jdk repository

Hi, can I please have a review for this boring change which simply changes all the SAP copyright messages from "SAP AG" to "SAP SE". The reason for this change is that SAP changed from a German stock corporation (AG) to a European one (SE). http://cr.openjdk.java.net/~simonis/webrevs/2016/8149529

Re: Compact Strings and APIs for fast decoding of string data

Or as Chris explain, having a string that span on more than one buffer is a corner case of this software, so for most of the strings, the constructor that takes a buffer is fine, and for the corner case, a constructor of String that takes a CharSequence seems to be easier to implement than creat

Re: RFR: jsr166 jdk9 integration wave 4

On 02/02/16 15:23, Martin Buchholz wrote: On Tue, Feb 2, 2016 at 6:37 AM, Chris Hegarty wrote: On 1 Feb 2016, at 18:45, Martin Buchholz wrote: After much debate on what to do when CompleteableFuture.whenComplete encounters an exception in both the source and the action, we chose what was ac

Re: RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

> On 10 Feb 2016, at 09:06, Paul Sandoz wrote: > > >> On 10 Feb 2016, at 08:00, shilpi rastogi wrote: >> >> Hi All, >> >> Please review my updated patch >> http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/ >> >> > > Just add

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

> On 10 Feb 2016, at 04:42, Mikael Vidstedt wrote: > > > Can I please get a quick review of these updated webrevs: > > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/ > jdk: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/jdk/webrev/ > > i

RFR (S) 8149459: StringConcatFactory should be synced up with LambdaMetafactory

Hi, I would like to make StringConcatFactory more coherent with existing LambdaMetafactory: https://bugs.openjdk.java.net/browse/JDK-8149459 http://cr.openjdk.java.net/~shade/8149459/webrev.01/ Testing: jdk/test/java/String/concat jtreg, JPRT Cheers, -Aleksey

Re: API review of VarHandles

> On 10 Feb 2016, at 02:03, Hans Boehm wrote: > > I found this a bit scary for naive readers: > > * The Java Language Specification permits operations to be executed in > * orders different than are apparent in program source code, subject to > * constraints arising, for example, from the use o

Re: RFR: 8071368 Use more concrete types for NamedFunction constants in the code

Hi, I'll be happy to sponsor this. Best, Michael > Am 10.02.2016 um 09:03 schrieb Paul Sandoz : > > Hi Shilpi, > > I think you can consider this reviewed. It got the ok from Vladimir, with > reference to John’s feedback in the bug. > > Pau. > >> On 10 Feb 2016, at 08:01, shilpi rastogi wr

Re: RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

Hi, I'll be happy to sponsor this. Best, Michael > Am 10.02.2016 um 09:06 schrieb Paul Sandoz : > > >> On 10 Feb 2016, at 08:00, shilpi rastogi wrote: >> >> Hi All, >> >> Please review my updated patch >> http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/ >>

Re: Compact Strings and APIs for fast decoding of string data

Hi, A more functional approach would be to compose a sequence buffers into one view, perhaps read-only. Then there would be no need to accept arrays of buffers. That should work well for bulk operations. That’s a non-trivial but not very difficult amount of work, and possibly simplified if rest

Re: RFR 8138884:MethodHandles.Lookup.findVirtual() Javadoc fails to consider private interface methods

> On 10 Feb 2016, at 08:00, shilpi rastogi wrote: > > Hi All, > > Please review my updated patch > http://cr.openjdk.java.net/~srastogi/8138884/webrev.01/ > > Just add a “,” after the new statement .. {@code static}, No need for a

Re: RFR: 8071368 Use more concrete types for NamedFunction constants in the code

Hi Shilpi, I think you can consider this reviewed. It got the ok from Vladimir, with reference to John’s feedback in the bug. Pau. > On 10 Feb 2016, at 08:01, shilpi rastogi wrote: > > > Gentle Reminder! >> >> On 2/5/2016 9:18 PM, Vladimir Ivanov wrote: >>> Proposed fix looks good. >>> >>>