Hi Bob,
On 5/30/18 12:45 PM, Bob Vandette wrote:>
RFE: Container Metrics
https://bugs.openjdk.java.net/browse/JDK-8203357
WEBREV:
http://cr.openjdk.java.net/~bobv/8203357/webrev.00
Looks fine in general. It's good to have this internal API ready
for JFR and other library code to use.
I
+1
Paul.
> On May 31, 2018, at 2:24 PM, Claes Redestad wrote:
>
> Hi,
>
> please review this tiny fix that removes the eager creation of
> asCollectorCache, which saves us a few milliseconds on certain startup tests
> with no observed peak performance penalties.
>
> Bug:
Hi,
please review this tiny fix that removes the eager creation of
asCollectorCache, which saves us a few milliseconds on certain startup
tests with no observed peak performance penalties.
Bug: https://bugs.openjdk.java.net/browse/JDK-8204194
Patch: [1]
Thanks!
/Claes
[1]
diff -r
Hi all,
I have uploaded another iteration of the implementation of the constants
API + the javadoc.
Thanks for the comments so far,
Vicente
[1] http://cr.openjdk.java.net/~vromero/constant.api/webrev.09
[2] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.09
On 05/24/2018 09:09 PM,
Hi folks,
Apologies for wide distribution, this was meant to be a private mail.
Cheers,
Ivan
Since I am already making the noise - my question was about the sample
code for article [1] which I found interesting and it is actually
related to this alias.
Kudos to Per-Åke Minborg for the
HI Michal, David,
Thank you both. I am doing a build, will sanity check the changes via the
generated javadoc
Best
Lance
> On May 31, 2018, at 8:00 AM, Michal Vala wrote:
>
> Hi Lance,
>
> here's current webrev:
> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8190417/webrev.01/
>
Hi,
The changes for JDK 8 look fine to me.
Thanks, Roger
On 5/30/18 9:40 PM, Ivan Gerasimov wrote:
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:
Hi Lance,
here's current webrev:
http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8190417/webrev.01/
On 05/31/2018 12:45 PM, Lance Andersen wrote:
Hi Michal,
Any additional changes we can use this bug.
If you have made additional changes, please point me to your latest update when
you think
Hi Michal,
Any additional changes we can use this bug.
If you have made additional changes, please point me to your latest update when
you think you have made your last set of tweaks.
Best
Lance
> On May 31, 2018, at 6:09 AM, Michal Vala wrote:
>
> Hi Lance, David,
>
> I've found few more
Hi Ivan,
we are not Tagir :)
The code is quite fun but i would not recommend to use that hack in real life.
Rémi
- Mail original -
> De: "Ivan Krylov"
> À: "core-libs-dev"
> Envoyé: Mercredi 30 Mai 2018 22:48:39
> Objet: github
> Тагир, привет,
>
> Слушай, а что с лицензией твоих
Hi Lance, David,
I've found few more javadoc line length issues, so I've fixed that.
Regarding to linking methods, I guess all links should have arguments. Now when
I link `#appendTail`, it goes to first instance, which is
appendTail(StringBuffer). So it should be explicit everywhere, Right?
Hi,
I'd like to upgrade the JOpt Simple library we are using to version 5.0.4.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203891
Complete webrev:
http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/complete/
Delta webrev only showing (all) JDK changes in JOpt Simple and related
Hello.
8202322 was integrated into jdk-11+15.
I'm using XLC 13.1.3 on AIX 7.1.4.
Build was failed because of "-qvisibility=hidden" on
make/lib/LibCommon.gmk.
According to "XL C/C++ for AIX 13.1.3" documentation [1],
"-qvisibility=hidden" cannot create shared libraries entry points.
For example,
On 30/05/2018 16:06, Jan Lahoda wrote:
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
Looks fine.
Approved for jdk8u-dev.
regards,
Sean.
On 31/05/2018 02:40, Ivan Gerasimov wrote:
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:
I'm not convinced TimeUnit::toDuration(long amount) has enough value.
We don't have a similar method on ChronoUnit
Duration.of(amount, timeUnit.toChronoUnit()) seems sufficient. Maybe
document this in the convert(Duration) method?
Stephen
On 31 May 2018 at 01:19, Martin Buchholz wrote:
>
Hi Jan,
Works as expected with jjs now.
Thanks,
Hannes
> Am 30.05.2018 um 17:06 schrieb Jan Lahoda :
>
> 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:
>
In j.u.concurrent the APIs bottom out in something that just takes a long
nanos, like LockSupport.parkNanos, so there's no advantage to converting to
TimeUnit-based durations greater than 292 years. And returning multiple
values in Java remains clumsy.
On Wed, May 30, 2018 at 11:06 PM, Peter
Just thinking loud...
On 05/30/18 19:36, Martin Buchholz 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
19 matches
Mail list logo
