Thank you for the review comments. I realized that only TextStyle.NARROW
and NARROW_STANDALONE should return the abbreviation to be consistent
with locale data. I've changed the implementation, which should have
"fixed" the NPE issue, and added more test cases.
Revised webrev:
http://cr.openjd
On 12/10/2016 09:00 PM, Uwe Schindler wrote:
Hi,
We noticed that buffers with zero length also have no cleaner. This is
why we also have the null check in our code (see Github) and the
guardWithTest in the MethodHandle, although we never free duplicates.
So a noop is better imho.
Oh yes,
Hi Vincent,
177 public static Stream dumpToStream(byte[] bytes, int fromIndex,
178 int toIndex) {
179 Objects.requireNonNull(bytes);
180 Arrays.rangeCheck(bytes.length, fromIndex, toIndex);
181
182 return StreamSupport.stream(
183 Spliter
Hello,
i would agree that a hexdumper is too specific for java.base module.
But what about hex encoding and parsing (similiar to java.util.Base64. Since
java.xml.bind is no longer in the base modules an alternative for
DataTypeConverter in SE is missing.
Gruss
Bernd
--
http://bernd.eckenfels.ne
Hi,
We noticed that buffers with zero length also have no cleaner. This is why we
also have the null check in our code (see Github) and the guardWithTest in the
MethodHandle, although we never free duplicates. So a noop is better imho.
I like the Unsafe approach. To me both variants are fine.
Hi Chris,
On 12/10/2016 06:11 PM, Chris Hegarty wrote:
How about: Unsafe::deallocate(ByteBuffer directBuffer)?
http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/
Apart from the fact that Unsafe is (was?) reserved for low-level stuff,
I think this approach is reasonable. Is the method i
Hi Vinnie,
I think this doesn't belong in the java.base module; it doesn't add
enough value for a average developer
and it is not essential to the core. I don't have another module
suggestion but would suggest
looking elsewhere.
$.02, Roger
On 12/9/2016 8:02 PM, Vincent Ryan wrote:
Thank
On 10.12.2016 13:08, Alan Bateman wrote:
On 10/12/2016 09:13, Jochen Theodorou wrote:
Hi all,
motivated by the recent "Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch" thead, I thought I ask... there is
AcccessibleObject#setAccessible(boolean), which will ask the
SecurityMa
I think it best to keep whatever we do here simple and straight forward.
It is, after all, just a stop gap until a public API can be put in place
in a future release ( which I believe is a realistic possibility
given some of the discussions that I have heard about, but that is for
another day).
If
Hi Brent,
This looks really good now!
best regards,
-- daniel
On 10/12/16 01:16, Brent Christian wrote:
On 12/07/2016 04:05 PM, Mandy Chung wrote:
I suggest to add two utility methods rather than the has method:
boolean dropClassLoaderName()
boolean dropModuleVersion()
Done.
430
Hi Uwe,
On 12/10/2016 01:33 PM, Uwe Schindler wrote:
Hi Peter,
this would be a great fix! Thanks!!!
I also think the non-static method is superior to my original
proposal, because it allows us to do the security check **once**,
which is really needed for Lucene. I am still fine if the perm
Hi Peter,
this would be a great fix! Thanks!!!
I also think the non-static method is superior to my original proposal, because
it allows us to do the security check *once*, which is really needed for
Lucene. I am still fine if the permission is still checked on every unmapping,
but we ne
On 10/12/2016 08:22, Jochen Theodorou wrote:
:
A fix for this is already committed, we are only waiting for release
of Groovy 2.4.8. Of course even with the fix Groovy code can possibly
break... for example if you did the direct buffer access in Groovy.
Thanks for sharing, that is very usefu
On 10/12/2016 11:09, Peter Levart wrote:
:
Something like the following?
http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/
Sort of although I think the proposal will be more specific, as in
unmap(MappedByteBuffer) on an existing class.
The other update to JEP 2
On 10/12/2016 09:13, Jochen Theodorou wrote:
Hi all,
motivated by the recent "Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch" thead, I thought I ask... there is
AcccessibleObject#setAccessible(boolean), which will ask the
SecurityManager for permissions and then make its
Hi,
On 12/10/2016 06:14 AM, Alan Bateman wrote:
On 09/12/2016 22:32, Uwe Schindler wrote:
Hi,
I updated our Jenkins server for the JDK 9 preview testing to use
build 148. Previously we had build 140 and build 147, which both
worked without any issues. But after the update the following stu
Thanks Alan,
I will look forward to see a solution for this! THANKS! A static method
somewhere in jdk.internal to trigger the unmapping of a MappedByteBuffer would
be fine. This is easy to change in our code, we just need a MethodHandle to a
function with the following signature: static void un
Hi all,
motivated by the recent "Java 9 build 148 causes trouble in Apache
Lucene/Solr/Elasticsearch" thead, I thought I ask... there is
AcccessibleObject#setAccessible(boolean), which will ask the
SecurityManager for permissions and then make itself accessible
according to the boolean flag.
On 09.12.2016 23:32, Uwe Schindler wrote:
Hi,
I updated our Jenkins server for the JDK 9 preview testing to use build 148.
Previously we had build 140 and build 147, which both worked without any
issues. But after the update the following stuff goes wrong:
(1) Unmapping of direct buffers no l
19 matches
Mail list logo
