Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

I > believe it would be much more logical to throw a recoverable RuntimeException > in this case (e.g. java.lang.ArrayOverflowException, as an analog of > java.nio.BufferOverflowException). > > Anthony > > On 12/03/2017 15:53, Christoph Engelbert wrote: >> Hey Anthon

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

Hey Anthony, The meaning is already overloaded, as "Cannot create native thread" is also an OutOfMemoryError and in like 99% of the cases means "Linux ran out of filehandles". The chance the OS really couldn't allocate a thread for the reason of no main memory available is very narrow :) Chris

Re: Cleaner cleanup

Hey Peter, I just realized, there are two mistakes in the Javadoc code example inside the Cleaner Javadoc: private final State; -> private final State state; private final Cleaner.Cleanable cleanable -> private final Cleaner.Cleanable cleanable; Chris > On 16 May 2016, at 00:08, Peter Levart

Re: Cleaner cleanup

art <peter.lev...@gmail.com> wrote: > > Correction in line... > > On 05/16/2016 12:54 PM, Peter Levart wrote: >> Hi Christoph, >> >> >> On 05/16/2016 10:37 AM, Christoph Engelbert wrote: >>> Hey Peter, >>> >>> First of all,

Re: Cleaner cleanup

Peter, Just as a quick correction of the previous example, obviously Buffer::deallocate wouldn’t work, but I guess you get the point. Chris > On 16 May 2016, at 10:37, Christoph Engelbert <m...@noctarius.com> wrote: > > Hey Peter, > > First of all, I really love this Cl

Re: Cleaner cleanup

Hey Peter, First of all, I really love this Cleanup API! Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. Made up example: public T execute(BufferAction bufferAction) { Buffer buffer =

Re: Expecting Integer.valueOf(String) to accept Literal format ...

Hey Andrew, Not sure it would risk breaking compatibility. It’s fairly easy to support it by just replacing underscore before parsing. Do you think of code that is expected to not parse underscore arguments? I think it’s a fair request to support underscore based integer representations, even

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hey guys, I really like the proposal! I also have the strong feeling it should be proposed with an VarHandles in mind. So far VarHandles can only build views on top of ByteBuffers, which stuck with 32bit indexing. Wouldn’t it make sense to also support 64bit addressing when allocating memory?

Re: 8139891: Prepare Unsafe for true encapsulation

Hey Chris, I don’t like to say it but it sounds very wrong to have another Unsafe like thinggy in the future instead of providing public alternatives right from the start. I agree it might be a faster to just write adapter classes and I really don’t like to repeat what I said in the past but

Re: Replacement for sun.misc.Unsafe.allocateInstance(Class?) ?

Hey Jörg, It will not yet be unaccessible, you just have to force JDK 9 to export the sun.misc package to be visible to user code. There will be a command line flag for that purpose, however I agree eventually we’ll need a replacement, whatever it looks like. Chris Am 31.07.2015 um 20:33

Re: JEP 193: Enhanced Volatiles

Am 05.03.2014 um 08:40 schrieb Jeroen Frijters jer...@sumatra.nl: My goal here is to make sure that expert users can get their job done somehow, *without* making the job of mainstream developers harder. The add lvalues to Java so experts can write CAS-libraries fails that test miserably.

Re: Draft JEP on enhanced volatiles

Am 07.02.2014 um 21:44 schrieb Brian Goetz brian.go...@oracle.com: And, it is reasonably consistent with other similar uses of keywords for qualifying access to functionality, such as I.super or Outer.this. Brian’s right, if you see it the same way as super and this it doesn’t even looks so