8285445: Would it make sense to add an java.nio.channels.FileChannel::nullFileChannel()

Hi Brian & Alan, I just run also into this issue and saw that that Alan suggested the use of OutputStream.nullOutputStream() that we implemented a while ago:

Re: Specification of Properties.load() does not define behaviour in case of duplicate keys

I see the the problematic there. At least we should clarify the actual behavior within the load() method specification stating the current state. Having done this the question would be what could be an appropriate method name/signature for the new behavior? loadUnique() loadDistinct() or

Specification of Properties.load() does not define behaviour in case of duplicate keys

He everyone, When loading a properties file using java.util.Properties.load() the behaviour for duplicate key values is not yet specified. The actual implementation overwrites existing key/value defined within the current file by the further down without any warning or exception. This has

Re: Querstion about ForkJoinPool / SecurityManager interoperability

2018 at 4:37 AM Patrick Reinhart <mailto:patr...@reini.net>> wrote: > > Even if the security manager is enabled before the initialize of the > ForkJoinPool not all work is delegated to > InnocuousForkJoinWorkerThread > instances (sometimes it picks

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Wow - nice :-) On 2018-12-14 13:43, Doug Lea wrote: On 12/13/18 2:34 PM, Patrick Reinhart wrote: Should I prepare a webrev for this change? No, I think we are all set (thanks Martin!) https://bugs.openjdk.java.net/browse/JDK-8215359

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Should I prepare a webrev for this change? -Patrick Am 13.12.18 um 15:15 schrieb Doug Lea: > On 12/13/18 8:44 AM, Patrick Reinhart wrote: >> This special case could have been handled also by the >> InnocuousForkJoinWorkerThread >> could in my opinion be relaxed to acce

Re: Querstion about ForkJoinPool / SecurityManager interoperability

Hi Dough, Thanks first of all for that quick answer... On 2018-12-13 14:23, Doug Lea wrote: On 12/13/18 7:36 AM, Patrick Reinhart wrote: Now the special case of using those special threads with no permission are only created when the ForkJoinPool is initialized with a security manager

Querstion about ForkJoinPool / SecurityManager interoperability

Hi everybody, I'm not sure if this mailing list the correct one, if not please give me a note where to place that question. When trying to use the Weld SE with together with a SecurityManager and I got a exception thrown out of the ForkJoinWorkerThread: java.lang.SecurityException:

Re: 8143850: retrofit ArrayDeque to implement List

Am 31.07.2018 um 21:10 schrieb Patrick Reinhart: > Hi Alex, > > I can do that for you > > -Patrick > Here it is: http://cr.openjdk.java.net/~reinhapa/reviews/8143850/webrev -Patrick

Re: 8143850: retrofit ArrayDeque to implement List

Hi Alex, I can do that for you -Patrick Am 31.07.2018 um 21:08 schrieb Alex Foster: > Sure, I don't mind. I would have done that myself but I don't think I have > access to upload to cr.openjdk.java.net. > > > Alex > > > From: Stuart Marks > Sent: July

Re: RFR JDK-8205090 / JDK-8204930

uld also review it. I can be the committer if need be. > > Thanks, > > Brian > >> On Jun 22, 2018, at 11:21 AM, Patrick Reinhart wrote: >> >> The JDK 11 ramp down fase is coming soon and I would like to have that fixed >> before that. Please review the CS

RFR JDK-8205090 / JDK-8204930

Hi everybody, The JDK 11 ramp down fase is coming soon and I would like to have that fixed before that. Please review the CSR and the proposed webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8204930/webrev Thanks for your replies and a sponsoring committer -Patrick

RFR: JDK-8205090 Update of the Reader:nullReader() spec for the mark() method

Hi Everybody, In the process of solving the issue [1] a part of the proper solution should be a partially change of the Reader.nullReader() specification. I opened a new CSR to address this. The main change would be to change to following lines: |* The {@code markSupported()} method returns

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

On 2018-06-14 13:03, Alan Bateman wrote: On 14/06/2018 11:50, Patrick Reinhart wrote: Hi everybody, I re-proposed the CSR with the changed API. The CSR is associated with the original change-set that was pushed a few months so the simplest is to just create a follow-up CSR that is linked

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

Sorry, everybody it seems, that I completely messed things up :-(( @Alan can you help me getting that back in order again? -Patrick On 2018-06-14 13:03, Alan Bateman wrote: On 14/06/2018 11:50, Patrick Reinhart wrote: Hi everybody, I re-proposed the CSR with the changed API. The CSR

Re: RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

Hi everybody, I re-proposed the CSR with the changed API. Somehow I'm not able to add the comment explaning the change. (Tried both in proposed and draft state) :-( I also updated the webrev to represent the two small changes as proposed from Brian. -Patrick On 2018-06-13 23:16, Brian

RFR JDK-8204930 Reader:nullReader() spec does not match the behavior

Hi everybody, While looking into the current Reader Spec and the failing methods I found that the ready() method actually does behave wrong and I fixed this. For the case of mark() I would like to revise the specification to align with the Reader’s default behavior that states for the mark

Re: RFR 8196298 Add null Reader and Writer with latest changes

Hi Roger, Seems there are no more comments...   - all shocked :-) -Patrick Am 16.03.2018 um 16:21 schrieb Roger Riggs: > Hi Patrick, > > Looks good, > > If there are no more comments, I can sponsor the commit. > > Thanks, Roger > > > On 3/16/18 2:10 AM, Patrick

RFR 8196298 Add null Reader and Writer with latest changes

://bugs.openjdk.java.net/browse/JDK-8196350 > Am 07.03.2018 um 11:41 schrieb Patrick Reinhart <patr...@reini.net>: > > I applied those changes here: > > http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.02 > > -Patrick > > >> Am 06.03.2018 um 23:12 schr

Re: RFR 8196298 Add null Reader and Writer with latest changes

I applied those changes here: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.02 -Patrick > Am 06.03.2018 um 23:12 schrieb Brian Burkhalter : > > Yes, I think so and and also the parameter ‘csq' is allowed to be null so > Objects.requireNonNull(csq)

Re: RFR 8196298 Add null Reader and Writer with latest changes

Updated the CSR API with webrev's content and finalized it.. -Patrick Am 06.03.2018 um 17:35 schrieb Alan Bateman: > On 05/03/2018 21:45, Patrick Reinhart wrote: >> I tried to incorporate all feedback I received so far and updated the >> webrev accordingly: >> >>

RFR 8196298 Add null Reader and Writer with latest changes

I tried to incorporate all feedback I received so far and updated the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 -Patrick

RFR 8196298 Add null Reader and Writer

Hi every boy that reviewed I tried to incorporate all feedback I received so far and updated the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.01 -Patrick

Re: RFR 8196298 Add null Reader and Writer

Hi everyone responded so far. How should we proceed now? -Patrick Am 07.02.2018 um 18:38 schrieb Patrick Reinhart: >> Am 07.02.2018 um 14:03 schrieb Alan Bateman <alan.bate...@oracle.com>: >> >> On 03/02/2018 17:05, Patrick Reinhart wrote: >>> : &g

Re: RFR 8196298 Add null Reader and Writer

> Am 07.02.2018 um 14:03 schrieb Alan Bateman <alan.bate...@oracle.com>: > > On 03/02/2018 17:05, Patrick Reinhart wrote: >> : >> I reworked the tests and Writer implementation accordingly >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8

Re: RFR 8196298 Add null Reader and Writer

> Am 02.02.2018 um 02:45 schrieb Stuart Marks <stuart.ma...@oracle.com>: > > > > On 2/1/18 10:35 AM, Patrick Reinhart wrote: >> Here is my first shot of the actual implementation and tests: >> http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.00 &

Re: JDK-8196298: Add null Reader and Writer

> Am 01.02.2018 um 22:26 schrieb Brian Burkhalter <brian.burkhal...@oracle.com>: > > > On Jan 30, 2018, at 8:52 AM, Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > >>> Am 30.01.2018 um 16:02 schrieb Alan Bateman &l

Re: RFR 8196298 Add null Reader and Writer

Hi Rémi, I also found, that I missed the throw an ReadOnlyBufferException on a passed in read only CharBuffer. > Am 01.02.2018 um 19:49 schrieb Remi Forax : > > Hi Patrick, > I believe read(CharBuffer), like read(char[], int, int), should test if there > are remaining chars

RFR 8196298 Add null Reader and Writer

Hi, Here is my first shot of the actual implementation and tests: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.00 Thanks for feedback -Patrick

Re: JDK-8196298: Add null Reader and Writer

> Am 30.01.2018 um 16:02 schrieb Alan Bateman : > > On 29/01/2018 22:55, Brian Burkhalter wrote: >> I made a few minor changes to the CSR [1] verbiage. Probably the >> nullWriter() documentation should also be updated to explicitly mention all >> variants of both

Re: JDK-8196298: Add null Reader and Writer

o be > filed). > > Thanks, > > Brian > > On Jan 27, 2018, at 12:45 AM, Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > >> I saw that great extension on InputStream/OutputStream adding a Null >> implementation there. Bas

JDK-8196298: Add null Reader and Writer

Hi there, I saw that great extension on InputStream/OutputStream adding a Null implementation there. Based on those I would propose a similar addition to the Reader/Writer. -Patrick Here is what the API would look like based on the existing from InputStream/OutputStream:     /** *

Re: RFR 4358774: Add null InputStream and OutputStream

That’s my favorite too… -Patrick > Am 05.01.2018 um 16:31 schrieb Roger Riggs : > > +1 > > C) InputStream.nullInputStream() and OutputStream.nullOutputStream().

Re: RFR 4358774: Add null InputStream and OutputStream

Sorry, missed that thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050458.html -Patrick Am 09.12.2017 um 22:28 schrieb Patrick Reinhart: > Hi Brian, > >> All previous suggested changes have been made in >> >> http://cr.openjdk.java.ne

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Brian, > All previous suggested changes have been made in > > http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ > 99 @Override 100 public int read(byte[] b, int off, int len) throws IOException { 101 Objects.checkFromIndexSize(off, len,

Re: RFR 4358774: Add null InputStream and OutputStream

(); > > Comments? > > Thanks, > > Brian > > On Dec 6, 2017, at 12:36 PM, Patrick Reinhart <patr...@reini.net> wrote: > >> Is there also a issue for the same kind of methods for Reader and Writer? >

Re: RFR 4358774: Add null InputStream and OutputStream

> Am 06.12.2017 um 21:43 schrieb Brian Burkhalter <brian.burkhal...@oracle.com>: > > On Dec 6, 2017, at 12:36 PM, Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > >> Sounds great, perfect to remove some more own code… >

Re: RFR 4358774: Add null InputStream and OutputStream

Sounds great, perfect to remove some more own code… Is there also a issue for the same kind of methods for Reader and Writer? -Patrick > Am 06.12.2017 um 20:00 schrieb Brian Burkhalter : > > https://bugs.openjdk.java.net/browse/JDK-4358774 >

Re: JDK-8191706: Proposal to add Reader::transferTo(Writer)

Webrev and CSR updated accordingly... -Patrick Am 22.11.2017 um 09:23 schrieb Alan Bateman: > > > On 21/11/2017 19:56, Patrick Reinhart wrote: >> Hi there out a the review [1] for  JDK-8066870, that will need some more >> working on, I created this specific issue to add

Re: RFR: JDK-8191706: Add Reader::transferTo(Writer)

t; On Nov 21, 2017, at 2:33 PM, Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > >> Here's the implementation and test.. >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 >> <http://cr.openjdk.java.net/%7Erein

RFR: JDK-8191706: Add Reader::transferTo(Writer)

Here's the implementation and test.. http://cr.openjdk.java.net/~reinhapa/reviews/8191706/webrev.00 -Patrick Am 21.11.2017 um 23:07 schrieb Brian Goetz: > Looks good. > > On 11/21/2017 2:56 PM, Patrick Reinhart wrote: >> Hi there out a the review [1] for  JDK-8066870, that will

JDK-8191706: Proposal to add Reader::transferTo(Writer)

Hi there out a the review [1] for  JDK-8066870, that will need some more working on, I created this specific issue to add an transferTo method to the java.io.Reader as it seems more clear as of the similarity to java.io.InputStream.transferTo(java.io.OutputStream) in terms of the API. To start

Re: RFR: 8066870 Add Readable::transferTo(Appendable)

> have a much better implementation for Reader->Writer than for > Readable->Appendable. (Do we get patches for those 30 places too?) > > > > On 11/19/2017 3:01 PM, Patrick Reinhart wrote: >> Having a static method on Appendable instead of a default on

Re: RFR: 8066870 Add Readable::transferTo(Appendable)

able. > > I know default methods on highly abstract interfaces are very tempting, and > the siren song of fluency calls to us, but we should be very, very careful > about adding default methods to interfaces like Iterable or Readable -- > essentially any of the Xxxable interfaces. >

RFR: 8066870 Add Readable::transferTo(Appendable)

Hi Roger and Alan, I incorporated the latest feedback using version 1) from this latest post: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050004.html The actual webrev is here: http://cr.openjdk.java.net/~reinhapa/reviews/8066870/webrev.00 -Patrick

Re: JDK-8067661: transferTo proposal for Appendable

Just to see if I picked up the Discussion so far. The discussion is about that original sentence from: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 "Depending on which class implements the appendable, there may be a limit of data that can written to which in turn could lead to

Re: JDK-8067661: transferTo proposal for Appendable

> Am 14.11.2017 um 16:33 schrieb Brian Burkhalter : > > > On Nov 14, 2017, at 3:45 AM, Alan Bateman > wrote: > >> - Readable "hence unspecified". In several other places, including >>

Re: JDK-8067661: transferTo proposal for Appendable

s a {@link CharBuffer}, {@code put(CharBuffer)} is invoked on it > with this buffer as parameter. Otherwise {@link > Appendable#append(CharSequence, int, int)} is invoked on it with this buffer > and its position and length as parameters.” > Seems also improve the wording - changed &

Re: JDK-8067661: transferTo proposal for Appendable

Latest changes: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 -Patrick > Am 13.11.2017 um 15:35 schrieb Roger Riggs : > > Hi Patrick, > > Comments on http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.02: > > Readable.java: > 74: „to an

Re: JDK-8067661: transferTo proposal for Appendable

An updated webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.01 > A few comments: > > Readable.java: > 67: + it may be worth mentioning that the input might not fit in output (as > seen in the CharBuffer case) > Though I see we didn’t call that out in the other transferTo

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Stuart, After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would seem to me a logical enhancement in the sense of the existing

Re: JDK-8067661: transferTo proposal for Appendable

.@oracle.com>: > > Hi Patrick, > > On Nov 7, 2017, at 3:01 PM, Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > >> I integrated your changes into my current version which I will look into >> tomorrow with Alan at Devoxx. I think

Re: JDK-8067661: transferTo proposal for Appendable

gt; > If an I/O error occurs during the operation, then not all characters might > have been transferred > and the source or destination could be left in an inconsistent state. The > caller of this method > should therefore ensure in such a case that measures are taken to release any > re

Re: RFR: 8067661 transferTo() for Appendable

> Am 05.11.2017 um 11:02 schrieb Alan Bateman <alan.bate...@oracle.com>: > > On 05/11/2017 08:34, Patrick Reinhart wrote: >> After discussing [0] for about the API for the new transferTo() method on >> Appendable, I have created an initial >> Version of the

RFR: 8067661 transferTo() for Appendable

After discussing [0] for about the API for the new transferTo() method on Appendable, I have created an initial Version of the actual implementation for review: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.00/index.html Any comments/suggestions are welcome, also I will need a

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, I will have a version ready at Devoxx next week ;-) -Patrick > Am 03.11.2017 um 13:49 schrieb Alan Bateman <alan.bate...@oracle.com>: > > On 02/11/2017 19:55, Patrick Reinhart wrote: >> : >> If we are all happy with the API so far, I could start adding an

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

from itself or a Set implementation has not to check for duplicate entries or similar. -Patrick > > > On 11/1/2017 4:29 PM, Patrick Reinhart wrote: >> In this case I would prefer a non static copyOf() method on the list >> to create a unmodifiable list/set/map, where the optimal factor

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, > Am 02.11.2017 um 20:34 schrieb Alan Bateman <alan.bate...@oracle.com>: > > On 02/11/2017 18:36, Patrick Reinhart wrote: >> : >> That would read then something like this: >> >> * Reads all characters from this readable and writes the c

Re: JDK-8067661: transferTo proposal for Appendable

Hi Alan, The latest version is here: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/signature > Am 02.11.2017 um 14:52 schrieb Alan Bateman <alan.bate...@oracle.com>: > > On 01/11/2017 14:57, Patrick Reinhart wrote: >> I tried to put that in my latest proposal: &

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

gt; Our experience has been that specializing for N=0 and N=1 does pay off. > Probably not N=2, though? > > On Wed, Nov 1, 2017 at 12:45 PM Patrick Reinhart <patr...@reini.net > <mailto:patr...@reini.net>> wrote: > > > Am 01.11.2017 um 20:25 schrieb Stuart Marks

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

> Am 01.11.2017 um 20:25 schrieb Stuart Marks : > > On 10/31/17 5:52 PM, Bernd Eckenfels wrote: >> Having a List.of(List) copy constructor would save an additional array copy >> in the collector Which uses (List)List.of(list.toArray()) > > The quickest way to get all

Re: JDK-8067661: transferTo proposal for Appendable

I tried to put that in my latest proposal: /**  * Reads all characters from this readable and writes the characters to  * the given appendable in the order that they are read. On return, this  * readable will be at end its data.  *  * This method may block indefinitely reading from the readable,

Re: JDK-8067661: transferTo proposal for Appendable

a > buffer and read > characters and then append them to the appendable.  I don't remember > if a 'pull' API was > considered for streams in which the dest could provide its own buffer > to the reader > and benefit from one less copy of the bytes. > > Thanks, Roger &g

JDK-8067661: transferTo proposal for Appendable

Hi There, Based on the *transferTo* Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.    /**   

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Hi Jason, At the moment, a subclass would need to overwrite this method with the same behaviour. The other solution would be to make the internal state auto-flush to no longer be final. -Patrick On 2016-12-21 22:40, Jason Mehrens wrote: Patrick, How is 'withAutoFlush' expected to behave

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Hi Roger, I tried to put your suggested changes, into the following webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.01 - 375: Can this use the new private constructor that will handle psOut. >>> Here I can not get hold on the encoding at this point or have I missed

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

> Am 05.12.2016 um 22:44 schrieb Roger Riggs <roger.ri...@oracle.com>: > > Hi Patrick, > > On 11/30/2016 4:47 PM, Patrick Reinhart wrote: >> ... >>> A few comments on the webrev: >>> >>> - 359: The withAutoFlush javadoc sho

Re: On what issues could I help clean up for JDK 9

What was the outcome of that discussion? I seem to miss that one. My question comes from the past presentation I gave about contributing to the OpenJDK. And one of the main things was not only to do some local hacking but instead try to solve some small issues, that else would not be fixed

On what issues could I help clean up for JDK 9

Hi there, I wanted to ask if there is a simple JBS query to find small clean up parts to help with? Seems to me a good starting point for some „hacking-on-the-OpenJDK-sessions“ -Patrick

Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

ush methods. I will move that out to a new Test as soon we are more clear about the other points > That's all I have time for at the moment, > > Regards, Roger > > > On 11/29/2016 4:15 PM, Patrick Reinhart wrote: >> Does anyone sponsor this fix? >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 >> >> -Patrick >

Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Does anyone sponsor this fix? http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 -Patrick

RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Any sponsor for this? > Am 23.11.2016 um 21:53 schrieb Patrick Reinhart <patr...@reini.net>: > > Hi Stephen, > > I changed the webrev accordingly: > > http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 > > -Patrick > >> Am 23.11.2016 um

Re: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Hi Stephen, I changed the webrev accordingly: http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 -Patrick > Am 23.11.2016 um 14:45 schrieb Stephen Colebourne : > > Returning the writer was my intention. I also intended it to return a > new instance, to avoid

Re: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

On 2016-11-23 14:35, Jonathan Bluett-Duncan wrote: Hi Patrick, Have you considered making `withAutoFlush()` return the `PrintWriter` itself, allowing fluent code snippets like the following? ``` PrintWriter writer = new PrintWriter(new File("path/to/file.txt"),

RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Added those new public constructors: PrintWriter(OutputStream, Charset) PrintWriter(File, Charset) withAutoFlush() Also added a new private constructor: PrintWriter(OutputStream, Charset, boolean) and rewired the OutputStream constructor calls to this private constructor. Here's the

Re: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Hi Stephen, On 2016-11-23 12:04, Stephen Colebourne wrote: Perhaps a method withAutoFlush(boolean) could reduce the number of To make that work, we would have to make the boolean field "autoFlush" writeable. Also the auto flush behaviour could be changed at any time. I would then prefer

RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Are there any obligations to add those constructors? -Patrick On 2016-11-18 10:19, Patrick Reinhart wrote: I was looking at the existing JDK 9 issues for some simple ones I could solve and found this one. I wanted to know if it makes sense to add additional constructors here? Now you need

JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

I was looking at the existing JDK 9 issues for some simple ones I could solve and found this one. I wanted to know if it makes sense to add additional constructors here? Now you need to do this: try { new PrintWriter(file, "UTF-8"); } catch

Request to review: JDK-8169659 (JDK-8168836 seems the wrong id)

, 2016, at 1:22 PM, Patrick Reinhart <patr...@reini.net> wrote: Ups, previous mail contained wrong URL. Here’s the correct one: http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 879 log.println(getMessage("err.missing.dependences")); This should

Re: JShell doesn't provide a ToolProvider

Hi Remi, At the moment there is only the both outputs and the arguments. So there seems to be no way to actually interact with a ToolProvider using the "run" method. Since there is no way to interact, the benefit is not given this way or am I wrong here? -Patrick On 2016-11-16 10:23, Remi

Re: RFR: JDK-8168836 Minor clean up on warning/error messages

Applied changes to http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 -Patrick On 15.11.2016 00:20, Mandy Chung wrote: >> On Nov 14, 2016, at 1:22 PM, Patrick Reinhart <patr...@reini.net> wrote: >> >> Ups, previous mail contained wrong URL. Here’s the

Re: RFR: JDK-8168836 Minor clean up on warning/error messages

Ups, previous mail contained wrong URL. Here’s the correct one: http://cr.openjdk.java.net/~reinhapa/reviews/8168836/webrev.00 -Patrick > Am 14.11.2016 um 22:19 schrieb Patrick Reinhart <patr...@reini.net>: > > Webrev containing the changes: > > http://cr.openjdk.java.

RFR: JDK-8168836 Minor clean up on warning/error messages

Webrev containing the changes: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 -Patrick > Am 14.11.2016 um 17:32 schrieb Mandy Chung <mandy.ch...@oracle.com>: > > >> On Nov 14, 2016, at 5:30 AM, Patrick Reinhart <patr...@reini.net> wrote: >>

Question about jdeps internalization

Hi there, I have taken a look into the jdeps utility in order to may extend it to supply an additional parameter to scan an entire directory for all existing JAR files. In doing that, I stumbled over some output that has no direct resource bundle externalization. My question is now if this

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

You’re welcome :-) -Patrick > Am 12.10.2016 um 22:41 schrieb Stuart Marks : > > Tests passed, spec change approved, changeset pushed: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af71f6a36731 > >

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Here is the latest webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.02 -Patrick > Am 07.10.2016 um 12:00 schrieb Jonathan Bluett-Duncan > : > > Hi all, > > Sorry for the delayed response, I've been busy lately with university and > other things.

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, As soon you got all the changes together, we can go thru them and I will recreate the webrev… -Patrick > Am 05.10.2016 um 18:07 schrieb Jonathan Bluett-Duncan > : > > Stuart, thank you very much for your continued review of this changeset, > and for

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hello together, I tried to process all suggested change input into the following new webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 Give me feedback if something is missing/wrong -Patrick On 2016-09-15 13:48, Pavel Rappo wrote: Daniel, Claes, List.of() and

RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, Here are your changes in a webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 <http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00> -Patrick > Am 13.09.2016 um 14:45 schrieb Patrick Reinhart <patr...@reini.net>: > > Hi Jonatha

Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK

at 21:08, Patrick Reinhart <patr...@reini.net> wrote: Hi Jonathan, As just also wanted to help some more clean-up in the JDKs final phase, I could offer you to hold that patch. Just send it to me and I will prepare the webrev for you…. -Patrick -Patrick

Re: [PATCH] JDK-8134373: explore potential uses of convenience factories within the JDK

Hi Jonathan, As just also wanted to help some more clean-up in the JDKs final phase, I could offer you to hold that patch. Just send it to me and I will prepare the webrev for you…. -Patrick > Am 12.09.2016 um 20:36 schrieb Jonathan Bluett-Duncan > : > > Hi David,

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

I tried to include all the feedback here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.04 -Patrick On 08.09.2016 20:09, Paul Sandoz wrote: >> On 8 Sep 2016, at 08:20, Patrick Reinhart <patr...@reini.net> wrote: >>> And one more thing. Because we have now o

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

On 2016-09-08 09:16, Andrej Golovnin wrote: Hi all, Maybe I'm wrong but I think the JavaDocs for the new method need more love. The JavaDocs mention at multiple places that resources are loaded, e.g.: 1362 * Returns a stream that loads the resources with the given name. 1375 *

Re: Review Request: JDK-8165563 ClassLoader::getSystemClassLoader will never be null

Hi Mandy Found a tiny typo ony line 1453, that could also be fixed with this change: 1451 * @throws IOException 1452 * If I/O errors occur 1453 1454 * @since 1.2 1455 */ 1456 public static Enumeration getSystemResources(String name) -Patrick On 07.09.2016

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hi Paul, On 07.09.2016 22:59, Paul Sandoz wrote: >> On 7 Sep 2016, at 13:14, Patrick Reinhart <patr...@reini.net> wrote: >> >> >> Hi Paul, >> >> With the change for https://bugs.openjdk.java.net/browse/JDK-8165563 >> that Mandy has sent to

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

gt; } catch (IOException e) { > throw new UncheckedIOException(e); > } > }; > return StreamSupport.stream(si, …); > > ? > > Paul. > > >> On 7 Sep 2016, at 11:38, Patrick Reinhart <patr...@reini.net> wrote: >> >> The current changes can be found here: >> >> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 >> > > >

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

The current changes can be found here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.03 On 07.09.2016 02:39, Mandy Chung wrote: > There was already an discussion about this with Alan Bateman: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042792.html >> > I

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

Hi Mandy, The current changes can be found here: http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.02 On 02.09.2016 23:11, Mandy Chung wrote: >> On Sep 2, 2016, at 2:50 AM, Patrick Reinhart <patr...@reini.net> wrote: >> >> Updated the existing >> http:/

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

On 2016-09-02 10:10, Tagir Valeev wrote: Also small thing: Spliterator.NONNULL & Spliterator.IMMUTABLE Should be Spliterator.NONNULL | Spliterator.IMMUTABLE With best regards, Tagir Valeev. Updated the existing http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01 - Patrick

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

On 2016-09-02 08:09, Andrej Golovnin wrote: src/java.base/share/classes/java/lang/ClassLoader.java The constant RESOURCE_CHARACTERISTICS in the line 215 should be defined near the #streamOf()-method. The distance between the line 1412 where the #streamOf()-method is defined and the line 215 is

  1   2   >