Hi Andrew/Jonathan,
Thanks a lot for sharing this work. Copying hotspot-compiler-dev to get their
feedback as well.
Couple of thoughts/observations below:
* Supporting ByteBuffer on persistent memory using existing FileChannel and
MappedByteBuffer mechanism sounds like a very good idea.
*
On Wed, May 30, 2018 at 7:43 PM, Gregg Wonderly wrote:
> I am not sure I understand this implementation, but isn’t
>
> >long s = convert(duration.getSeconds(), SECONDS);
>
> needing to actually be
>
> >long s = convert(duration.getSeconds(), NANOSECONDS);
>
> so that s+n is in a
Hi Lance, Michal,
When I looked into javadoc rules last week it seemed that links to
methods should include the () if no-args ie.
+ * {@link #find find} methods.
should be
+ * {@link #find() find} methods.
Of course now I can't find those rules! The javadoc guide [1] doesn't
seem
Hello!
I'd like to backport the fix to JDK 8u-dev.
Both source patch and the regression test had to be adjusted slightly
due to the code divergence, thus the review request.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203368
Jdk 8u webrev:
I agree with "tempest in a teapot". The practical effect either way will
be small. We seem unlikely to convince each other with new arguments.
My thinking may be influenced by my growing belief that having
ConcurrentModificationException in the core libraries at all was a mistake
- they belong
v.0.2 has both conversion methods in TimeUnit. The unexpected weirdness is
that convert(Duration) saturates while toDuration throws
ArithmeticException, but both seem author-culture-consistent. Perhaps
TimeUnit#toDuration doesn't provide enough value in view of the existing
Duration.of and
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing
javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK
releases), and was delivered as part of the JavaFX build. The
On 5/22/18 2:58 PM, Stuart Marks wrote:
On 5/22/18 8:50 AM, Martin Buchholz wrote:
We seem to have enough consensus to change the modCount behavior of
replaceAll.
Sorry, I don't agree that there is such consensus. There are about half a dozen
different issues all at play, spread across
I thought there would be some hint from Alan about which of the two
paths we should take for more refinement.
The Tony's:
http://cr.openjdk.java.net/~tonyp/8202788/webrev.1/
Or the Alan's with my mods:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.02/
Regards, Peter
Тагир, привет,
Слушай, а что с лицензией твоих примеров на гитхабе? Не мог бы ты
какую-то лицензию упомянуть в шапке?
Скажем, вот этот:
https://gist.github.com/amaembo/cbe9e1a8f3f8d240beb080343670f0c2
Спасибо,
Ваня
Hi all,
Any more thoughts on this? (with apologies for the ping)
Tony
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On May 18, 2018 at 3:58:57 PM, Tony Printezis (tprinte...@twitter.com)
wrote:
Hi again,
Stylistically, I strongly prefer this version over the previous one
I reviewed the delta-webrev (v3). Looks good. Thanks for fixing
missing newlines in launcher.properties
Mandy
On 5/30/18 12:00 PM, Jonathan Gibbons wrote:
Please review a minor update to the proposed implementation of JEP 330.
The primary change is to disallow the use of the "shebang"
Please review a minor update to the proposed implementation of JEP 330.
The primary change is to disallow the use of the "shebang" feature in
Java source files
(i.e. files whose name ends in ".java") as recently proposed on this
list [1].
There is some additional minor cleanup to the
Kurt's initial post did not make it to concurrency-interest. At this
point, it is probably least confusing if interested readers who aren't
on core-libs-dev follow this on archives:
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
On 05/30/2018 01:36 PM, Martin Buchholz wrote:
>
Belated reply, but yes, thanks for pointing this out.
-- Jon
On 05/12/2018 09:21 PM, Jaikiran Pai wrote:
Just gave the patch a try by locally building it. Works great! :)
A minor comment- the java usage/help text shows this:
Usage: java [options] [args...]
(to execute a class)
On 30 May 2018 at 18:15, Kurt Alfred Kluever wrote:
> 1. Rename ALL existing unitless primitive method parameters to include
> their time unit.
This seems like a simple win. AFAIK, parameter names can be changed
freely in the JDK.
> 2. Add a java.time overload to some APIs ...
> Note that new
On 30 May 2018 at 18:36, Martin Buchholz wrote:
> Stephen/Doug: is there any reason we didn't add conversions between Duration
> and TimeUnit when we added conversions to ChronoUnit?
I don't remember the idea being discussed. The proposed implementation
seems reasonable.
thanks
Stephen
>
+1
—
Actually… even small API tweaks are not easy :-), this got me thinking whether
this method should explicitly state negate is called, since it has implications
for subtypes. Something to consider as a follow on tweak perhaps.
Paul.
> On May 29, 2018, at 5:52 AM, Jim Laskey wrote:
>
>
Obvious progress would seem to be more conversion methods. Conversion code
tends to be annoying/errorprone because of having to deal with overflow.
Stephen/Doug: is there any reason we didn't add conversions between
Duration and TimeUnit when we added conversions to ChronoUnit?
Here's a
+1
Paul.
> On May 29, 2018, at 12:22 PM, Xueming Shen wrote:
>
> Hi,
>
> Please help review the proposed api spec update for JDK-8203839 (and its CSR)
>
> issue: JDK-8203839: API clarification: versioned jar entry verification in
> multi-release jar file
> csr:
Hi Michal,
I made a couple of additional minor tweaks
- Cleaned the line length in a couple of places
- Addressed an inconsistency where Matcher’s was used in place of matcher’s
(which is used everywhere else in the javadoc)
Here is the updated diff:
——
$ hg diff
Hi Lance,
thanks, I'd appreciate that
On 05/30/2018 04:32 PM, Lance Andersen wrote:
I can sponsor this for you
On May 30, 2018, at 7:17 AM, Michal Vala wrote:
Hi,
please review and eventually sponsor this small doc patch fixing method links
in java.util.regex.Matcher
webrev:
Hi,
An updated webrev is here:
http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/complete/
A webrev showing changes from the previous revision is here:
http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/delta/
The changes are:
-updated src/jdk.internal.le/share/legal/jline.md
-the
I can sponsor this for you
> On May 30, 2018, at 7:17 AM, Michal Vala wrote:
>
> Hi,
>
> please review and eventually sponsor this small doc patch fixing method links
> in java.util.regex.Matcher
>
> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8190417/webrev.00/
>
> Thanks!
>
>
Hi Jim,
looks good.
Rémi
- Mail original -
> De: "Jim Laskey"
> À: "core-libs-dev"
> Envoyé: Mardi 29 Mai 2018 14:52:24
> Objet: RFR: JDK-8050818 Predicate::not - provide an easier way to negate a
> predicate
> Introduce a new static method Predicate::not which will allow developers
On 2018-05-29 14:52, Jim Laskey wrote:
Introduce a new static method Predicate::not which will allow developers to
negate predicate lambdas trivially.
webrev: http://cr.openjdk.java.net/~jlaskey/8050818/webrev/index.html
Implementation and test looks good to me.
Thanks!
/Claes
Hi,
please review and eventually sponsor this small doc patch fixing method links in
java.util.regex.Matcher
webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8190417/webrev.00/
Thanks!
--
Michal Vala
OpenJDK QE
Red Hat Czech
On 29/05/2018 20:22, Xueming Shen wrote:
Hi,
Please help review the proposed api spec update for JDK-8203839 (and
its CSR)
issue: JDK-8203839: API clarification: versioned jar entry
verification in multi-release jar file
csr: https://bugs.openjdk.java.net/browse/JDK-8203840
webrev:
28 matches
Mail list logo
