Thanks Martin!
On 8/9/18 5:42 PM, Martin Buchholz wrote:
On Thu, Aug 9, 2018 at 5:27 PM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
I did not use the intrinsified variants of numberOfLeadingZeros in
the benchmark.
Oops! Should have looked more closely!
Did you know
Hi Igor,
Looks fine
Roger
On 8/10/18 4:22 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
2 lines changed: 0 ins; 0 del; 2 mod;
Hi all,
could you please review this one-line patch for the error reported by
error-prone?
JBS:
http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
> 4 lines changed: 1 ins; 0 del; 3 mod;
Hi all,
could you please review this small fix for the error detected in
jdk.internal.ed by error-prone?
webrev: http://cr.openjdk.java.net/~iignatyev//8209386/webrev.00/index.html
JBS:
Trying to write a quick agent for the JVM. The jvmti.h file is found quickly
but I do not know what to link it with. Can you guys help?
Thanks.
Max r.
http://cr.openjdk.java.net/~iignatyev//8209382/webrev.00/index.html
> 2 lines changed: 0 ins; 0 del; 2 mod;
Hi all,
could you please review this one-line patch for the error reported by
error-prone?
JBS: https://bugs.openjdk.java.net/browse/JDK-8209382
webrev:
retargeted bug to java.util:i18n, the right mailing list seems to be
i18n-dev.
On Fri, Aug 10, 2018 at 8:42 AM, Adam Farley8
wrote:
> Hi All,
>
> This bug could be fixed by comparing the Class Loader with a blank
> static volatile Object (defined outside the method scope) at the
> end of the
Hi Roger,
Thanks for the explanation; I'll adjust the proposed java.io.Serial spec
and serialization-related check accordingly.
Cheers,
-Joe
On 8/10/2018 11:02 AM, Roger Riggs wrote:
Hi Joe,
serialVersionUID is used to confirm the identity of a class so it is
applicable to classes
Hi Joe,
serialVersionUID is used to confirm the identity of a class so it is
applicable to classes
implementing Externalizable as well as Serializable. (And also
serialization of a class itself).
Thanks, Roger
On 8/10/18 1:39 PM, joe darcy wrote:
Hi Roger,
Returning to this topic, I'll
Hi Chris,
There seems to be a lot of repetition in tests that could be combined.
For example, the RecursiveDefault, RecursiveTrue, and RecursiveFalse
tests should be a
single test that is invoked 3 times, (multiple @run lines) with an
argument to say which case to test.
There would be fewer
Hi Roger,
Returning to this topic, I'll add a clause in the spec for
serialPersistentFields and Externalizable and corresponding code in the
checker. Should there be a similar check for serialVersionUID in an
Externalizable class? It wasn't clear to me from reading the specs and
there are
Hi Claes,
The updated Integer.java looks good. The test also looks good to me. I'd
suggest adding some checks in CheckIntegerCacheApp test for the cached
Integers using WhiteBox API, WhiteBox.isShared(object) to make sure that
they are archived. Checking all cached Integers is probably too
I'd venture to suggest File is more widely used because it was around
from the beginning, whereas Path is significantly more recent.
Once you know to look on the Files API, using Path is generally easy
and way preferable.
-- Jon
On 08/10/2018 08:23 AM, Stephen Colebourne wrote:
From what I
On Fri, Aug 10, 2018, 09:25 Stephen Colebourne wrote:
> From what I can see, File is more widely used than Path. Thats partly
> because using Path is non-obvious - it doesn't have any methods for
> doing anything.
>
> I've suggested before that a default method could be added, so you get
>
>
-- Bump --
Hi Folks,
> Zhengyu Gu wrote on 06/06/2018 01:58:18:
> From: Zhengyu Gu
> To: "Thomas Stüfe" , Adam Farley8
>
> Cc: "hotspot-...@openjdk.java.net developers" d...@openjdk.java.net>, core-libs-dev
> Date: 06/06/2018 01:58
> Subject: Re: RFR Bug-pending: Enable Hotspot to Track
On 8/10/18 8:44 AM, Claes Redestad wrote:
On 2018-08-10 16:10, Ioi Lam wrote:
I've verified all cases I can think of manually, but would like to defer the
creation of a sanity test to a follow-up RFE to allow time to think through and
discussing how to best go about that (do we need to
Hi All,
This bug could be fixed by comparing the Class Loader with a blank
static volatile Object (defined outside the method scope) at the
end of the getBundleImpl class.
E.g.
-
+1322
/**
* volatile reference object to guard the ClassLoader
I need more time to finish my review but here are some initial comments:
- java.security
1079 # jarpath - enables more detailed information in the IOExceptions
thrown
Use "jarPath" to be consistent with "hostInfo".
1080 #by java.util.jar.Attributes and java.util.jar.Manifest
On 2018-08-10 16:10, Ioi Lam wrote:
I've verified all cases I can think of manually, but would like to defer the
creation of a sanity test to a follow-up RFE to allow time to think through and
discussing how to best go about that (do we need to verify in depth, can we
reuse some existing test
>From what I can see, File is more widely used than Path. Thats partly
because using Path is non-obvious - it doesn't have any methods for
doing anything.
I've suggested before that a default method could be added, so you get
path.operations().isReadable()
path.operations().readAllBytes()
On 8/10/18 6:32 AM, Claes Redestad wrote:
On 2018-08-09 18:28, Claes Redestad wrote:
On 2018-08-09 17:41, Peter Levart wrote:
There's danger when you overwrite a non-null @Stable field with
another value that this new value will not be seen. Or is
code an exception where @Stable is
> On Aug 10, 2018, at 6:32 AM, Claes Redestad wrote:
>
>
>> On 2018-08-09 18:28, Claes Redestad wrote:
>>
>>
>>> On 2018-08-09 17:41, Peter Levart wrote:
>>>
>>> There's danger when you overwrite a non-null @Stable field with another
>>> value that this new value will not be seen. Or is
On 2018-08-09 18:28, Claes Redestad wrote:
On 2018-08-09 17:41, Peter Levart wrote:
There's danger when you overwrite a non-null @Stable field with
another value that this new value will not be seen. Or is
code an exception where @Stable is not honored yet...
Typically IntegerCache::
Hi Brian,
Among the files you suggest to fix, only the following ones are still
using 'readdir64' for other systems than AIX:
http://cr.openjdk.java.net/~bpb/8207744/webrev.03/src/java.base/unix/native/libjava/UnixFileSystem_md.c.frames.html
Minor revision to address testbase javadoc, initContext() expansion, @Override
line and imports place, new webrev as below, thanks
http://cr.openjdk.java.net/~xyin/8200151/webrev.02/
Regards,
Chris
> On 30 Jul 2018, at 5:08 PM, Chris Yin wrote:
>
> Thank you, Vyom
>
> Regards,
> Chris
>
>>
Sorry... another minor revision to handle @Override line and imports place, new
webrev as below, thanks
http://cr.openjdk.java.net/~xyin/8208542/webrev.02/
Regards,
Chris
> On 8 Aug 2018, at 2:51 PM, Chris Yin wrote:
>
> Minor revision to address javadoc, initContext() expansion, vararg etc.
Hello,
in sun.nio.fs.WindowsDirectoryStream I see that the code which iterates the
Directory goes to some length to retain the file attributes returned from that
function (by attaching them to a WindowsPathWithAttributes (aka
BasicFileAttributesHolder).
And indeed I can see that class in my
26 matches
Mail list logo
