Hi Alan,
Thank you for your comment. I was not fully aware of the possibility of
attacking...
I updated the patch to check if the current thread is the same as the
thread cached the loader.
Updated webreb: http://cr.openjdk.java.net/~horii/8188858/webrev.01/
Regards,
Ogata
From: Alan B
Yes. Please go ahead and file a bug report. Thanks.
Naoto
On 10/11/17 5:04 PM, Clément Guillaume wrote:
Hi,
I verified that using java.locale.providers=COMPAT with java 9 makes the
AKST to be parsed as America/Juneau
Is http://bugreport.java.com/ the correct way to file a jira?
Le mer. 11
This wave introduces a more clickable overview Home Page:
http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html
8188900: ConcurrentLinkedDeque linearizability
8188853: java/util/concurrent/ExecutorService/Invoke.java Assertion failure
8188047: Add SplittableRandom.
Hi Christoph,
I agree to bring-in optimizations in small chunks. So your proposed
handler invoke() method is as follows:
public Object invoke(Object proxy, Method method, Object[] args) {
String member = method.getName();
int parameterCount = method.getParameterCount();
+1
On 10/11/17, 9:15 AM, Claes Redestad wrote:
Hi,
please review this bug fix to ensure we don't reject jar
and zip files due to entries having malformed timestamps.
Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8188869
I opted to o
Hi,
sure, with the 6-month cadence it makes sense to push this partial fix
to 8029019 now,
and not hinge it on whether Peter (or anyone) picks up and provides a
satisfactory
solution to 8029019 in time.
Let's file a separate RFE and push this. I assume you need a sponsor to
do both?
Thank
(replying to appropriate aliases, instead of generic jdk9-dev alias)
Hi Clément,
The locale data, where those time zone names are derived from, have been
switched to use Unicode Consortium's CLDR, instead of the ones that are
previously used prior to JDK9. So there will be some differences you
Hi,
please review this bug fix to ensure we don't reject jar
and zip files due to entries having malformed timestamps.
Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8188869
I opted to only fall back to the more lenient JDK 8 version w
Hi Vyom,
Comments:
- update copyright
- use @since 18.3 instead of @since 10
- ExtendedSocketOptions.java: 265,269 include the "TCP_QUICKACK" in the
exception messages.
Line 144: if you are going to keep the assert, add a explanation
about how it could happen.
I'd remove the ass
Hi Matthias,
On 2017-10-10 18:23, Baesken, Matthias wrote:
Hi Claes, to me it looks like the old jdk8 coding is not slower than the
jdk9/10 coding .
a simple and somewhat naïve JMH benchmark to assess performance:
http://cr.openjdk.java.net/~redestad/scratch/ZipUtils.java
I've benchmarked t
Hi Jack,
I would prefer to see an updated webrev so that we do not inadvertently
push these changes.
Best
Lance
> On Oct 11, 2017, at 3:26 AM, Jack Li wrote:
>
> Hi Lance
>
> I will update them in Metro repository, do I need to regenerate webrev?
> or can you skip the files this time and I fix
Hi Lance
I will update them in Metro repository, do I need to regenerate webrev?
or can you skip the files this time and I fix it in next integration?
> On Oct 9, 2017, at 19:35, Lance Andersen wrote:
>
> Hi Jack,
>
> UnMarshaller also has the same issue. I would update the webrev given the
12 matches
Mail list logo
