Hi Patrick,
I reviewed the CSR with some minor changes as you will have seen. The webrev
looks OK. I’ve not been following this thread that closely so perhaps someone
else should also review it. I can be the committer if need be.
Thanks,
Brian
On Jun 22, 2018, at 11:21 AM, Patrick Reinhart w
On 6/22/18 3:58 PM, Paul Sandoz wrote:
Hi Smita,
I am ok with it if Vladimir is :-) One slight concern is this may be biasing
towards the x86 implementation of the intrinsic.
Looking on code and it will be a lot of changes in Base64.java. I am
concern about that late in JDK 11.
I think we
Hi Smita,
I CCing to Libs to review code changes in Base64.java.
Looks like you changed all need place to implement intrinsic.
One question so: why you have own copy of base64 charsets and not using
one in library:
private int encode0(byte[] src, int off, int end, byte[] dst) {
Hi Vladimir,
Please see my answers to your questions as below:
1) One question so: why you have own copy of base64 charsets and not using one
in library:
I am using vpgatherdd instruction to fetch multiple values from base64 array in
a single instruction with a vector index. Vpgatherdd instruct
+1
Mandy
On 6/22/18 7:49 AM, Roger Riggs wrote:
Hi Brian, Mandy,
Listing the open file descriptors can be a useful utility. Originally I
thought it was a temporary and throw away code.
To be a utility it needed to be a bit more general (sending the output
to a particular stream).
Thanks for
Hi Paul
I have updated the patch in this webrev:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.04/
Will push that soon.
Regards,
Vivek
-Original Message-
From: Deshpande, Vivek R
Sent: Thursday, June 21, 2018 4:14 PM
To: Paul Sandoz
Cc: roger.ri...@oracle.com; Da
Hi everybody,
The JDK 11 ramp down fase is coming soon and I would like to have that fixed
before that. Please review the CSR and the proposed webrev:
http://cr.openjdk.java.net/~reinhapa/reviews/8204930/webrev
Thanks for your replies and a sponsoring committer
-Patrick
On 6/22/2018 10:51 AM, Martin Buchholz wrote:
On Fri, Jun 22, 2018 at 10:28 AM, Paul Sandoz
wrote:
---
We've been unable to reach agreement on 8203662 - it remains in limbo.
8203662: remove increment of modCount from ArrayList and Vector
replaceAll()
http://cr.openjdk.java.net/~martin/webre
Hi,
> On Jun 21, 2018, at 9:32 AM, Andrew Dinn wrote:
>
> Hi Paul,
>
> Sorry for the delay in responding to this -- holiday and then an urgent
> bug fix intervened . . .
>
> On 08/06/18 01:42, Paul Sandoz wrote:
>> Sandhya gave an overview to a few of us Oracle folks. I agree with
>> what Sand
On Fri, Jun 22, 2018 at 10:28 AM, Paul Sandoz
wrote:
>
> > ---
> > We've been unable to reach agreement on 8203662 - it remains in limbo.
> >
> > 8203662: remove increment of modCount from ArrayList and Vector
> replaceAll()
> > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-
> integration
On Fri, Jun 22, 2018 at 10:28 AM, Paul Sandoz
wrote:
>
> TimeUnit.java
> —
>
> * is equivalent to
> * {@code unit.convert(n, NANOSECONDS)}, and
> * {@code unit.convert(Duration.of(n, unit.toChronoUnit()))}
> * is equivalent to {@code n} (in the absence of overflow).
>
Hi Roger,
Looks good!
Thanks,
Brian
On Jun 22, 2018, at 7:49 AM, Roger Riggs wrote:
> Listing the open file descriptors can be a useful utility. Originally I
> thought it was a temporary and throw away code.
> To be a utility it needed to be a bit more general (sending the output to a
> par
> On Jun 21, 2018, at 6:28 PM, Martin Buchholz wrote:
>
> JDK 11 draws nigh.
>
Indeed, comments below,
Paul.
> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
>
> 8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the constructor
> called
> http:
Hi Dora,
You could move those two lines that sets the locale to en-US before the
for-loop, so that if "args" contains -J-Duser.language/country then it
can override the default en-US.
The JIRA issue needs noreg-self label.
Naoto
On 6/22/18 1:26 AM, Dora Zhou wrote:
Hello,
Please help revi
+1
Naoto
On 6/22/18 9:55 AM, mandy chung wrote:
webrev.01 looks better and it wraps long lines.
Mandy
On 6/22/18 9:34 AM, Rachna Goel wrote:
Hi Mandy,
Thanks for the review.
Unicode 10.0.0 and ICU 60.2 were integrated with :
https://bugs.openjdk.java.net/browse/JDK-8191410
and CLDR 33 w
webrev.01 looks better and it wraps long lines.
Mandy
On 6/22/18 9:34 AM, Rachna Goel wrote:
Hi Mandy,
Thanks for the review.
Unicode 10.0.0 and ICU 60.2 were integrated with :
https://bugs.openjdk.java.net/browse/JDK-8191410
and CLDR 33 was: https://bugs.openjdk.java.net/browse/JDK-820253
Hi Stuart,
Do you still fear that "single-threaded-object" idiom is not safe?
I would just like to comment on the last approach...
On 06/19/2018 07:01 PM, Peter Levart wrote:
Here's another attempt that uses the same technique but relaxes the
possible concurrent source map scenario (where numb
Hi Mandy,
Thanks for the review.
Unicode 10.0.0 and ICU 60.2 were integrated with :
https://bugs.openjdk.java.net/browse/JDK-8191410
and CLDR 33 was: https://bugs.openjdk.java.net/browse/JDK-8202537
Linked mentioned issues with this one.
Thanks,
Rachna
On 6/22/18 9:57 PM, mandy chung wro
Hi,
Kindly ignore patch mentioned in previous mail.
patch for review is :
http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.01/
Thanks,
Rachna
On 6/22/18 7:24 PM, Rachna Goel wrote:
Hi,
Kindly review fix to update legal files for Unicode, CLDR and ICU.
Issue: https://bugs.openjdk.jav
On 6/22/18 6:54 AM, Rachna Goel wrote:
Hi,
Kindly review fix to update legal files for Unicode, CLDR and ICU.
Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
Looks okay.
What are the issues that upgrades these librar
Following on from the recent JDK-8203629 code review, I'd like to
propose enhancements on how we can record events in security libs. The
introduction of the JFR libraries can give us much better ways of
examining JDK actions. For the initial phase, I'm looking to enhance
some key security libra
Hi Brian, Mandy,
Listing the open file descriptors can be a useful utility. Originally I
thought it was a temporary and throw away code.
To be a utility it needed to be a bit more general (sending the output
to a particular stream).
Thanks for the suggestions.
Please review:
http://cr.openj
Can I also add that, when a buffer in the cache needs to be replaced with a
new (and typically larger) one, the old buffer is explicitly freed. So, the
code already assumes that buffers that are in the cache should not be
reachable from anywhere else. Explicitly freeing them when the thread exits
i
The DnD & clipboard cases on such a desktop are the only possible use I
can think of
for this charset, so if it were to exist anywhere it would be in the
desktop module,
since it depends on all the X decoders that were moved there.
But since MToolkit is gone so we don't have direct need for it.
Hi,
Kindly review fix to update legal files for Unicode, CLDR and ICU.
Issue: https://bugs.openjdk.java.net/browse/JDK-8205158
Patch :http://cr.openjdk.java.net/~rgoel/JDK-8205158/webrev.02/
--
Thanks,
Rachna
On 06/22/2018 11:50 AM, Alan Bateman wrote:
On 21/06/2018 18:29, Peter Levart wrote:
On 06/21/2018 07:01 PM, Tony Printezis wrote:
I’m trying exactly that. :-)
Sorry, I didn't know. Here's my attempt:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/
I also added @
Hi Tony,
On 06/21/2018 07:39 PM, Tony Printezis wrote:
Peter,
The changes to TestMaxCachedBufferSize.java look fine. One point
though: Why do you need the TmpDirectBuffersReclamation.java test? In
TestMaxCachedBufferSize.java you just call checkDirectBuffers(0, 0);
after you the main thread
Thanks Alan.
Now we can use OpenJDK JDK11 GUI feature on IBM AIX's CJK locales.
And AIX's desktop is still CDE/Motif...
We may need COMPOUND_TEXT charset for clipboard and DnD feature against
CDE/Motif.
To 2d-dev:
Could you reconsider about COMPOUND_TEXT charset ?
Thanks,
Ichiroh Takiguchi
IB
Hi Tagir,
> What if it's TreeSet with custom comparator which may differentiate elements
> equal by .equals()? Or, even simpler, Collections.newSetFromMap(new
> IdentityHashMap<>())? In both cases Set.of(array) would throw.
You are right. I haven't thought about this cases. OK, then we should
at l
Hello!
What if it's TreeSet with custom comparator which may differentiate
elements equal by .equals()? Or, even simpler,
Collections.newSetFromMap(new IdentityHashMap<>())? In both cases
Set.of(array) would throw.
With best regards,
Tagir Valeev.
On Fri, Jun 22, 2018 at 4:43 PM Andrej Golovnin
On 21/06/2018 21:13, Florian Weimer wrote:
* Tony Printezis:
There are a few obvious ways to mitigate this, e.g., cause a Full GC /
concurrent GC cycle at regular intervals. However, the best solution IMHO
is to explicitly free any direct buffers that are still in the cache when a
thread exits.
On 21/06/2018 18:29, Peter Levart wrote:
On 06/21/2018 07:01 PM, Tony Printezis wrote:
I’m trying exactly that. :-)
Sorry, I didn't know. Here's my attempt:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/
I also added @run main/othervm to TempDirectBuffersReclamatio
> Hi all,
>
> the current implementation of Set.copyOf(Collection coll)
> creates an intermediate HashSet object to remove duplicates even when
> coll is already a Set. The attached patch adds an additional check
> whether coll is already a Set and if yes, then calls #toArray()
> directly on coll a
On 21/06/2018 11:41, Dave Hobbs wrote:
Yes, the proposal is to create a new module outside the JDK.
:
A service provider module appears to be the recommended approach according
the Java api documentation. However writing charset classes is made a lot
more difficult by not having the sun.nio.cs
Hi all,
the current implementation of Set.copyOf(Collection coll)
creates an intermediate HashSet object to remove duplicates even when
coll is already a Set. The attached patch adds an additional check
whether coll is already a Set and if yes, then calls #toArray()
directly on coll and passes the
Hello,
Please help review the fix for JDK-8194152. Thank you.
The test compares output with expected error messages in English, set
locale to en-US so that the output are not translated into other languages.
Bug: https://bugs.openjdk.java.net/browse/JDK-8194152
Webrev: http://cr.openjdk.java.
On 22/06/2018 06:47, Ichiroh Takiguchi wrote:
Hello.
JDK8 Linux build has COMPOUND_TEXT charset, but it seems it's missing
on JDK11 Linux build.
I checked Bug DB, I could not find out the reason why COMPOUND_TEXT
charset was missing.
This was removed more than 3 years ago during JDK 9 developm
37 matches
Mail list logo
