Re: RFR JDK-8187485: Update Zip implementation to use Cleaner, not finalizers

On 12/7/17, 8:31 AM, mandy chung wrote: On 12/4/17 3:14 PM, Xueming Shen wrote: issue: https://bugs.openjdk.java.net/browse/JDK-8185582 webrev: http://cr.openjdk.java.net/~sherman/8185582/webrev ZStreamRef.java 79 static ZStreamRef get(Object owner, LongSupplier addr, LongConsumer

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 8, 2017, at 6:19 PM, Claes Redestad wrote: > > I think one can interpret the @implSpec in AbstracList::subList to suggest > that the implementation retrieved will subclass AbstractList, which implies > it's *not* Serializable. As we move away from AbstractList

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On 2017-12-09 02:09, John Rose wrote: On Dec 8, 2017, at 7:13 AM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8193128/open.03/ +for (int i = elements.length - 1; i > 0; i--) { There's an OBOE in this line; should be i >= 0. I thought I

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi John, On 2017-12-09 02:20, John Rose wrote: On Dec 8, 2017, at 4:45 PM, John Rose > wrote: Can anyone point out a reason why the value based lists of List.of() should serialize while the value based lists of List.of().subList() should

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 8, 2017, at 4:45 PM, John Rose wrote: > > Can anyone point out a reason why the value based > lists of List.of() should serialize while the value based > lists of List.of().subList() should not? Or is there some > reason we should not allow subList to produce

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

+1 (there should) On Dec 8, 2017, at 9:44 AM, Martin Buchholz wrote: > > Should there be changes to general purpose collection testing classes like > test/jdk/java/util/concurrent/tck/CollectionTest.java > test/jdk/java/util/Collection/MOAT.java > that would have caught

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 8, 2017, at 7:13 AM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8193128/open.03/ > +for (int i = elements.length - 1; i > 0; i--) { There's an OBOE in this line; should be i >= 0. Errors like this are a risk of

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 8, 2017, at 5:06 PM, Sergey Bylokhov wrote: > On 08/12/2017 16:49, Brian Burkhalter wrote: >> I agree it looks strange but it is intentional as it matches the existing >> InputStream.read(byte[],int,in) [1]. (I will remove line 167 as part of this >> patch.)

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Brent, On Dec 8, 2017, at 4:50 PM, Brent Christian wrote: > I just noticed a couple small things in the test: > > test/jdk/java/io/InputStream/NullInputStream.java > > […] > > Line 113 should read "... != 0", yes? > > […] > > On 132, it's "skip() != 0". You

Re: RFR 4358774: Add null InputStream and OutputStream

On 08/12/2017 16:49, Brian Burkhalter wrote: I agree it looks strange but it is intentional as it matches the existing InputStream.read(byte[],int,in) [1]. (I will remove line 167 as part of this patch.) Note that the IOE for the stream being closed would not be thrown in the current code

Re: RFR 4358774: Add null InputStream and OutputStream

Hi, Brian On 12/8/17 3:12 PM, Brian Burkhalter wrote: http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ The changes look good to me. I just noticed a couple small things in the test: test/jdk/java/io/InputStream/NullInputStream.java 109 @Test(groups = "open") 110 public

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Sergey, On Dec 8, 2017, at 4:34 PM, Sergey Bylokhov wrote: > One more issue that according to the spec the new method > read(byte[], int, int) should throw an exception if the stream was closed, > but as far as I understand it can return "0" if "len=0" even if

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

On Dec 7, 2017, at 3:41 PM, Claes Redestad wrote: > > - the ListFactories test didn't explicitly verify that sublists retrieved > from various List.of() impls aren't Serializable. Added tests to check no > sub-list is Serializable, > and as a bonus this test now

Re: RFR 4358774: Add null InputStream and OutputStream

Hi, Brian. On 08/12/2017 15:12, Brian Burkhalter wrote: All previous suggested changes have been made in http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ One more issue that according to the spec the new method read(byte[], int, int) should throw an exception if the stream was closed, but

Re: RFR (JDK10) 8183743: Umbrella: add overloads that take a Charset parameter

Thanks Roger, Alan for the comments! I've updated the webrev accordingly. Here's the current webrev: http://cr.openjdk.java.net/~joehw/jdk10/8183743/webrev/index.html -Joe On 12/4/17, 7:52 PM, Joe Wang wrote: On 12/3/17, 11:34 AM, Alan Bateman wrote: On 01/12/2017 20:35, Joe Wang wrote:

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Please, let's not derail this thread. :-) I think would be a good thing to think about, so I've filed a JIRA issue to track it: https://bugs.openjdk.java.net/browse/JDK-8193279 s'marks On 12/8/17 1:45 AM, Remi Forax wrote: Let's gently derail this thread, the is another pain point with

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. This looks good. The naming is consistent and I think better than the "getWhenPresent" proposed in the original thread. i agree with Alan. Having a

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 8, 2017, at 8:29 AM, Brian Burkhalter wrote: > On Dec 8, 2017, at 4:39 AM, Alan Bateman wrote: > >>> http://cr.openjdk.java.net/~bpb/4358774/webrev.02/. >>> >> I read through the javadoc again and I think it looks good. >> >> On

RFR: JDK-8184947:,ZipCoder performance improvements

Hi, Please help review the changes for j.u.z.ZipCoder/JDK-8184947 (which also includes cleanup/improvement work in java.lang.StringCoding.java to speed up general String coding performance, especially for UTF8). issue: https://bugs.openjdk.java.net/browse/JDK-8184947 webrev:

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Pushed. In future I will use the phrase "Best of a Bad Lot Practice". On Mon, Dec 4, 2017 at 4:20 PM, Stuart Marks wrote: > If you don't like my alternative, fine; it has its own set of tradeoffs >>> that might be net positive or negative. If you want to

RFR JDK-6372077: Manifest should handle manifest attribute names up to 70 bytes

Hi everyone, After I haven't found a sponsor so far, I try to make it even easier this time by providing a hopefully ready patch this time. See http://files.paratix.ch/jdk/6372077/webrev.01/ or the attached 6372077.patch. In short, this patch increases the manifest files line width by two

Re: RFR 4358774: Add null InputStream and OutputStream

I like the nullInputStream() nullOutputStream() as I would first search for those names, also nullReader() / nullWriter() seem to fit more than Sink/Source or Stream -Patrick > Am 08.12.2017 um 19:38 schrieb Brian Burkhalter : > > Patrick’s comment made us think

Re: RFR 8193271 : ProblemList tools/launcher/TestXcheckJNIWarnings.java

Thanks, Joe -B On 12/8/17 11:45 AM, joe darcy wrote: +1 Cheers, -Joe On 12/8/2017 11:44 AM, Brent Christian wrote: Hi, Please review my change to add the intermittently-failing tools/launcher/TestXcheckJNIWarnings.java to the problem list. diff -r a1f88c937a77

Re: RFR 8193271 : ProblemList tools/launcher/TestXcheckJNIWarnings.java

+1 Cheers, -Joe On 12/8/2017 11:44 AM, Brent Christian wrote: Hi, Please review my change to add the intermittently-failing tools/launcher/TestXcheckJNIWarnings.java to the problem list. diff -r a1f88c937a77 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txtTue Nov 28 10:15:47

RFR 8193271 : ProblemList tools/launcher/TestXcheckJNIWarnings.java

Hi, Please review my change to add the intermittently-failing tools/launcher/TestXcheckJNIWarnings.java to the problem list. diff -r a1f88c937a77 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Tue Nov 28 10:15:47 2017 -0800 +++ b/test/jdk/ProblemList.txt Fri Dec 08 11:42:55 2017

Re: Proposal for New Functionality: Allow module-info merging in GenModuleInfoSource.java

Moving this to jigsaw-dev On 12/6/17 8:38 AM, Adam Farley8 wrote: Hi All, Currently, GenModuleInfoSource.java does not allow you to merge extra module-info files into the primary module-info file (for a given module) at build time. This tool intends to augment platform-specific

Re: RFR 4358774: Add null InputStream and OutputStream

On Fri, Dec 8, 2017 at 1:03 PM, Brian Burkhalter wrote: > On Dec 8, 2017, at 10:52 AM, David Lloyd wrote: > >> On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter >> wrote: >>> Patrick’s comment made us think again

Re: RFR 4358774: Add null InputStream and OutputStream

Like David, I prefer the `null{$ClassName}` alternative to `null{Source|Sink}`. (I assume from his wording that he prefers `null{$ClassName}`.) I prefer `null{$ClassName}` not only because it's less ambiguous, but also because Guava has existing types `{Byte|Char}Source` and `{Byte|Char}Sink`, so

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 8, 2017, at 10:52 AM, David Lloyd wrote: > On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter > wrote: >> Patrick’s comment made us think again about the naming here as >> “nullStream()” would not fit for eventual equivalent methods on

Re: RFR 4358774: Add null InputStream and OutputStream

On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter wrote: > Patrick’s comment made us think again about the naming here as “nullStream()” > would not fit for eventual equivalent methods on Reader and Writer. It might > be better to go with something like > >

Re: RFR 4358774: Add null InputStream and OutputStream

Patrick’s comment made us think again about the naming here as “nullStream()” would not fit for eventual equivalent methods on Reader and Writer. It might be better to go with something like InputStream InputStream.nullSource(); OutputStream.nullSink(); and later Reader.nullSource();

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Should there be changes to general purpose collection testing classes like test/jdk/java/util/concurrent/tck/CollectionTest.java test/jdk/java/util/Collection/MOAT.java that would have caught this bug? (although those are mostly designed for mutable collections, but I think some immutable

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 8, 2017, at 4:39 AM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~bpb/4358774/webrev.02/. >> > I read through the javadoc again and I think it looks good. > > On the implementation then Sergey has a point, the requireNonNull isn't > needed to check b when

Re: RFR: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value

+1 On 12/8/2017 10:56 AM, Daniel Fuchs wrote: Hi, Please find below a straightforward fix for: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value https://bugs.openjdk.java.net/browse/JDK-8187073 webrev:

RFR: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value

Hi, Please find below a straightforward fix for: 8187073: The java.util.logging.Level.findLevel() will not correctly find a Level by it's int value https://bugs.openjdk.java.net/browse/JDK-8187073 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8187073/webrev.00/ As expected, the

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi, On 2017-12-08 07:54, Andrej Golovnin wrote: Hi Claes, http://cr.openjdk.java.net/~redestad/8193128/open.02/ I think you should provide specialised implementations of the #indexOf() and #lastIndexOf() methods in the classes List12 and ListN. Using an iterator in List12 is an overkill. But

RE: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Hi Rob, a little style nit: Is it really a good idea to use import java.util.*; in src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java? I thought one is supposed to only use qualified exports nowadays (with all the IDE support). Best regards Christoph -Original

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 12/8/17 4:28 AM, Alan Bateman wrote: On 07/12/2017 16:55, Daniel D. Daugherty wrote: : Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8182307

Re: RFR 4358774: Add null InputStream and OutputStream

On 07/12/2017 22:55, Brian Burkhalter wrote: Hi Roger, I agree. It does not seem that whatever performance improvement might accrue from not using the Objects methods is offset by the increased code readability in addition to mitigating the risks mentioned in [1]. I have reinstated this

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/08/2017 04:09 AM, David Lloyd wrote: Yes! It would be even better for the "toArray(Class)" case if Class had a "getArrayClass()" method which returned the Class, which would allow: return (T[]) Arrays.copyOf(elementData, size, componentType.getArrayClass()); and similar for

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

Thanks Mandy! -- daniel On 07/12/2017 23:59, mandy chung wrote: On 12/7/17 6:38 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8191033 Regression in logging.properties: specifying .handlers= for     root logger (instead of handlers=) no longer works

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

On 07/12/2017 19:15, Martin Buchholz wrote: I'm not a logging expert, but this change Looks Good To Me. Thanks Martin! > configure => configured +// For backward compatibility: add any handlers configure using Fixed. Thanks for spotting that! --- A bunch of

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Let's gently derail this thread, the is another pain point with the current optional API, it seems that are no simple way to transform an Optional to an OptionalInt and vice-versa. It's painful because we start to see interface that returns by example OptionalInt while the implementation you

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

- Mail original - > De: "Alan Bateman" > À: "Stuart Marks" , "core-libs-dev" > > Envoyé: Vendredi 8 Décembre 2017 10:10:15 > Objet: Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred >

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 07/12/2017 16:55, Daniel D. Daugherty wrote: : Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8182307 : For the gory details of the reasons

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 08/12/2017 00:33, Stuart Marks wrote: Hi all, Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. This looks good. The naming is consistent and I think better than the "getWhenPresent" proposed in