Hi Sherman,
src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java
72 public static ZipCoder get(String csn) {
73 try {
74 Charset cs = Charset.forName(csn);
75 if (cs.name().equals("UTF-8")) {
76 return utf8;
77 }
78 return n
Joseph, all,
Thanks for the clarification.
Are there chances to establish such guaranteed ordering in a future
Java version? As pointed out, it'd be very helpful to Bean Validation
and I reckon other cases, too.
Thanks,
--Gunnar
2017-01-18 3:13 GMT+01:00 Joseph D. Darcy :
> Hello,
>
> Follow
> On Jan 17, 2017, at 3:45 AM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a patch that adds a test that verifies that
> LogManager, Handlers, and config classes can be implemented
> from within a module (provided they are exported to java.logging).
>
> JBS: https://bugs.openjdk.java.net
Using a stable field will consume less meta-space than a nested class, all
other things being equal.
– John
> On Jan 17, 2017, at 5:48 PM, Paul Sandoz wrote:
>
> It’s either place the static finals in separate nested classes, or use
> @Stable on non-final statics with lazy initialization in
Hello,
I just closed out JDK-6321873 adding the comment:
Much of this contents of this issue was addressed by JDK-8071434;
JDK-8172928 has been filed to add additional doc linkages between
System.identityHashCode and Object.hashCode.
-Joe
On 1/17/2017 7:12 AM, Roger Riggs wrote:
Hi,
I wo
Hello,
Following up on Joel's message, IIRC this ordering issue did come up
during the design and testing of repeating annotations.
As noted previously in the thread, while the ordering of the annotations
in a container annotation is guaranteed, there is *not* a general
ordering constraint o
> On 17 Jan 2017, at 08:06, Claes Redestad wrote:
>
> Hi,
>
> as a follow-up to JDK-8086045, further analysis has found a number of small,
> simple improvements that can be made to further improve startup
> characteristics of typical usage of java.lang.invoke:
>
> - CallSite:: looks up two M
Hi Amy,
RangeCheckMicroBenchmark.java measures access for ArrayList. Did you update
ArrayList? (i don’t see it in your current patch).
Paul.
> On 16 Jan 2017, at 01:41, Amy Lu wrote:
>
> Thank you Paul and Martin for your review.
>
> On 1/13/17 12:52 AM, Paul Sandoz wrote:
>> HI Amy,
>>
>>
On 1/17/17, 3:24 PM, Claes Redestad wrote:
Looks good - I stumbled on the ZipPath::getResolved changes at first,
but they seem sound and I can see how the previous test was likely to
unnecessarily create a new byte[] on most regular files.
It's a little hacky to only go into resolve0 for "." or
Hi Sherman,
thanks for doing this!
Looks good - I stumbled on the ZipPath::getResolved changes at first,
but they seem sound and I can see how the previous test was likely to
unnecessarily create a new byte[] on most regular files.
Nits:
Code formatting seems unintentionally messed up in places
Hi,
Please review the following changes for zipfs implementation.
issue: https://bugs.openjdk.java.net/browse/JDK-8172921
webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
javac has moved to use zipfs (instead of ZipFile) to access jar files in
jdk9. Here are
some changes to improve
+1
I’m happy with the new reachabilityFence calls.
Mandy
> On Jan 17, 2017, at 10:23 AM, Naoto Sato wrote:
>
> Thanks, Peter & Daniel.
>
> I modified the webrevs accordingly:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
> http://cr.openjdk.java.net/~naoto/8171140/webrev.01/
>
>
Hi Peter,
I was very happy when I saw this on the mailing list today as I'm the one who
brought this up again end of November. Thank you for taking the time! I hope
you don't mind my comments on this one.
> This is a preview of a patch that addresses the following issue:
>
> https://bugs.
On 17/01/17 18:23, Naoto Sato wrote:
Thanks, Peter & Daniel.
I modified the webrevs accordingly:
http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
http://cr.openjdk.java.net/~naoto/8171140/webrev.01/
+1
best regards,
-- daniel
The one for 8171139 is the same as Peter's latest one, and
Thanks, Peter & Daniel.
I modified the webrevs accordingly:
http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
http://cr.openjdk.java.net/~naoto/8171140/webrev.01/
The one for 8171139 is the same as Peter's latest one, and the latter
one for 8171140 was modified following that change.
Naot
Hi,
as a follow-up to JDK-8086045, further analysis has found a number of
small, simple improvements that can be made to further improve startup
characteristics of typical usage of java.lang.invoke:
- CallSite:: looks up two MethodHandles that aren't used in many
typical applications and sho
Thanks for review. I’ve update patch
http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/
—Andrey
> On 3 Jan 2017, at 14:25, Chris Hegarty wrote:
>
> Andrey,
>
>> On 30 Dec 2016, at 14:11, Andrey Nazarov wrote:
>>
>> Hi,
>>
>> Following tests for Jar tool were added:
>>
>> Tests for API
Hi,
I would close 6321873. Informatively, it is already linked as related
to 8071434.
System.identityHashCode is specified as using the same value as the
default Object.hashCode
and not say anything to weaken the statements aboutr uniqueness.
Other suggestions?
$.02, Roger
On 1/15/2017 4
Hi,
This is a preview of a patch that addresses the following issue:
https://bugs.openjdk.java.net/browse/JDK-8029019
But it is also an attempt to clean-up failure reporting for invalid
annotation types. Here's the 1st webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotati
+1
With Peter's proposed changes if I'm not mistaken then all methods
that operate on the CacheKey (findBundle, findBundleInCache,
putBundleInCache, loadBundle, loadBundleFromProvider) are all
called from a point originating from within the block now protected
by the reachability fences, so the
Hi Naoto,
Sorry for joining late for review. Thanks for taking this on. I think it
is shaping well...
On 01/14/2017 01:54 AM, Naoto Sato wrote:
http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
Tho things...
1. As said, the "cloning" of CacheKey has no purpose in the following
secti
Hi,
Please find below a patch that adds a test that verifies that
LogManager, Handlers, and config classes can be implemented
from within a module (provided they are exported to java.logging).
JBS: https://bugs.openjdk.java.net/browse/JDK-8172886
webrev: http://cr.openjdk.java.net/~dfuchs/webrev
22 matches
Mail list logo
