RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method

https://bugs.openjdk.java.net/browse/JDK-8194133 http://cr.openjdk.java.net/~bpb/8194133/webrev.00/ Add jdk.internal.io.IOSupport with copy() methods for InputStream-to-OutputStream copying and modify some classes to use these new methods. One thing that I noticed when looking at this is that

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

On Dec 22, 2017, at 11:57 AM, John Rose wrote: > > On Dec 21, 2017, at 5:31 PM, Stuart Marks wrote: >> >> I'd like a blanket assertion that view collections are not serializable. >> >> Now this should be considered distinct from whether view

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

On Dec 21, 2017, at 5:31 PM, Stuart Marks wrote: > > I'd like a blanket assertion that view collections are not serializable. > > Now this should be considered distinct from whether view collections are > value-based; I'm fine with considering view collections to be

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

What are your thoughts on pushing the static EMPTY_XXX declarations from ImmutableCollections down in to each respective inner class? Doing that should allow for on demand class loading instead of getting everything when any factory is used.

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 12/22/17 2:16 AM, Chris Hegarty wrote: Webrev with the test updated as suggested:   http://cr.openjdk.java.net/~chegar/8179424/webrev.03/ Looks good.  Thanks for updating the test. Mandy

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Peter, On Dec 22, 2017, at 1:21 AM, Peter Levart wrote: > I think this looks good. No more suggestions from my side for this patch. As > Paul notes, it would be interesting to see if using > Unsafe.allocateUninitializedArray() to allocate the final array (and >

Re: Adding SocketChannel toString to connection exception messages

Hello, I also dearly miss Socket addresses in connection exceptions, however it looks like it is not going to make it. However if we add a getter for the Peer address (not included in toString) then logging frameworks could detect instances of ConnectException and process them accordingly.

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Hi Martin, I've just pushed the fix to jdk8u/jdk8u-dev [1] so it should be in the next regular 8u update (probably 8u172 ?). You can of course test it any time by building the tip of http://hg.openjdk.java.net/jdk8u/jdk8u-dev yourself :) Merry Christmas and a happy new year, Volker [1]

Re: Adding SocketChannel toString to connection exception messages

Hi David, you can "abuse" of the suppressed exception feature for that, i.e add a CommentException as suppressed exception to the SocketException with no stacktrace and a descriptive error message. Rémi - Mail original - > De: "David Lloyd" > À: "David Holmes"

Re: Adding SocketChannel toString to connection exception messages

On Thu, Dec 21, 2017 at 6:35 PM, David Holmes wrote: > I believe there are concerns with too much information that can be > considered "sensitive" (like host names and IP addresses) appearing in error > messages due to them ending up in log files and bug reports. I tend

Re: Adding SocketChannel toString to connection exception messages

On 22/12/17 14:59, Seán Coffey wrote: As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute,

Re: Adding SocketChannel toString to connection exception messages

As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute, diagnosing network issues is sure to

Re: [10] RFR 8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations

> De: "Paul Sandoz" > À: "Remi Forax" > Cc: "core-libs-dev" > Envoyé: Vendredi 22 Décembre 2017 01:38:37 > Objet: Re: [10] RFR 8075939: Stream.flatMap() causes breaking of > short-circuiting of terminal operations >> On

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 21/12/17 21:40, mandy chung wrote: ... > ReflectionFactory or other class in sun.reflect package would do it. and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. That’s what the test now does with my changes. Why separate it out into a separate issue?

Re: Adding SocketChannel toString to connection exception messages

On 22/12/17 01:27, David Holmes wrote: cc'ing net-dev as that might be the more appropriate list. On 22/12/2017 10:59 AM, Steven Schlansker wrote: On Dec 21, 2017, at 4:35 PM, David Holmes wrote: On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Brian, On 12/21/2017 09:44 PM, Brian Burkhalter wrote: On Dec 21, 2017, at 11:44 AM, Paul Sandoz wrote: I concur that this horse is almost dead from the beatings but since I already hacked up Peter’s suggestion which eliminates intermediate copies I might as well