Hi David,
On 3/9/20 7:41 PM, David Holmes wrote:
That's a core-libs decision but I'm not sure that's a namespace we
want to increase usage of.
I'm open to other suggestion. This helper method avoids the call to
doPrivileged when security manager is enabled and I think it's okay to
add
Hello,
I wonder why there are two times the same logic in internal public static
methods. Maybe that could be consolidated as well?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Yangfei (Felix)
Gesendet: Tuesday, March 10, 2020
Hi,
We found module-info.class in java.base.jmod is not always consistent across
different builds.
The ModuleHashes attribute in this module-info.class is not reproducible
between builds.
Patch fixes the issue by using TreeMap instead of HashMap when computing
ModuleHashes.
Bug:
)
- create_unc_path() @ java_md.c (for Windows)
- Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp
This change passed tests on submit repo
(mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139).
Thanks,
Yasumasa
[1]
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020
Hi Mandy,
On 10/03/2020 9:33 am, Mandy Chung wrote:
This patch refactors the native library loading implementation out of
ClassLoader and move them to jdk.internal.loader package. This
introduces a new NativeLibraries abstraction which loads and registers
the loaded native libraries.
:
- ZFILE_Open() @ zip_util.c
- JDK_Canonicalize() @ canonicalize_md.c (for Windows)
- create_unc_path() @ java_md.c (for Windows)
- Platform::MultibyteStringToWideString() @ WindowsPlatform.cpp
This change passed tests on submit repo
(mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139).
Thanks
Thanks Mandy,
this refactoring would indeed enable Panama library loading to get rid
of classloader-related restriction which are JNI-based and have little
to do with the way Panama does things. I'm looking forward to be able to
use something like this from my side of the fence :-)
Cheers
This patch refactors the native library loading implementation out of
ClassLoader and move them to jdk.internal.loader package. This
introduces a new NativeLibraries abstraction which loads and registers
the loaded native libraries. Previously it was maintained in a
nativeLibrary map in each
Please review the CSR proposed for JEP 371 Hidden Classes [1].
CSR:
https://bugs.openjdk.java.net/browse/JDK-8238359
javadoc/specdiff:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
JVMS
+1
On 3/9/20 12:05 PM, Joe Wang wrote:
The changes look good to me.
Best,
Joe
On 3/9/20 1:44 AM, Stephen Colebourne wrote:
Fine by me, but I'm not an OpenJDK Reviewer
Stephen
On Mon, 9 Mar 2020 at 03:05, wrote:
Thanks, Stephen.
Updated the webrev for those two suggestions:
On 3/9/20 10:45 AM, Chris Hegarty wrote:
Sure, I guess it somewhat depends on how you see 8240242 [1] turning
out. 8240242 clearly describes a similar(ish) issue where dropping
PUBLIC, when it is not currently held, has no effect, i.e. it does not
result in “no access” - this is either a bug
Looks good to me. Thanks for the update.
Naoto
On 3/9/20 10:37 AM, Ichiroh Takiguchi wrote:
Hello Naoto.
I appreciate your comments.
I modified TestMS950.java testcase.
I think it's easy to read.
Could you review the fix again ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8232161
Mandy,
> On 9 Mar 2020, at 16:37, Mandy Chung wrote:
>
> I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread
> should be discussed.
>
> The spec says:
>
> "When dropping PACKAGE then the resulting lookup will not have PACKAGE or
> PRIVATE access. When dropping
Hello Naoto.
I appreciate your comments.
I modified TestMS950.java testcase.
I think it's easy to read.
Could you review the fix again ?
Bug:https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.03/
Thanks,
Ichiroh Takiguchi
On
This change passed tests on submit repo
(mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139).
Thanks,
Yasumasa
[1]
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html
I have bcc'ed jdk-dev and add core-libs-dev mailing list where this
thread should be discussed.
The spec says:
"When dropping|PACKAGE|then the resulting lookup will not
have|PACKAGE|or|PRIVATE|access.When dropping|MODULE|then the resulting
lookup will not have|MODULE|,|PACKAGE|,
The changes look good to me.
Best,
Joe
On 3/9/20 1:44 AM, Stephen Colebourne wrote:
Fine by me, but I'm not an OpenJDK Reviewer
Stephen
On Mon, 9 Mar 2020 at 03:05, wrote:
Thanks, Stephen.
Updated the webrev for those two suggestions:
http://cr.openjdk.java.net/~naoto/8239836/webrev.04/
Hi,
Updating the spec to match the implementation is a good idea.
Whether adding a new method is worthwhile depends on whether *any*
non-conforming
UUID has been actually been seen. Humans don't type UUID's so if there
are non-conforming
ones out there, they have been generated by some
::MultibyteStringToWideString() @ WindowsPlatform.cpp
This change passed tests on submit repo
(mach5-one-ysuenaga-JDK-8240725-20200309-0811-9304139).
Thanks,
Yasumasa
[1]
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html
Fine by me, but I'm not an OpenJDK Reviewer
Stephen
On Mon, 9 Mar 2020 at 03:05, wrote:
>
> Thanks, Stephen.
>
> Updated the webrev for those two suggestions:
>
> http://cr.openjdk.java.net/~naoto/8239836/webrev.04/
>
> Naoto
>
> On 3/8/20 4:22 PM, Stephen Colebourne wrote:
> >
20 matches
Mail list logo
