r.java:136)
at java.base/java.lang.Thread.run(Thread.java:832)
/Claes
On 2020-05-14 22:39, Mandy Chung wrote:
Hi Claes,
Is the bootstrapping issue contributed by
Class::getDeclaredConstructors call in
InnerClassLambdaMetafactory::buildCallSite?
I wonder how much performance gain compared to usi
On 5/14/20 1:52 PM, Chris Hegarty wrote:
Hi Mandy,
On 14 May 2020, at 21:12, Mandy Chung wrote:
MethodHandles::privateLookupIn should prepare for being called during early
startup when the module of java.base classes are not yet assigned. This bug is
uncovered by panama prototype
Hi Claes,
Is the bootstrapping issue contributed by Class::getDeclaredConstructors
call in InnerClassLambdaMetafactory::buildCallSite?
I wonder how much performance gain compared to using
Lookup::findConstructor for non-capturing lambda case. If LMF uses
Lookup::findConstructor, it does
MethodHandles::privateLookupIn should prepare for being called during
early startup when the module of java.base classes are not yet
assigned. This bug is uncovered by panama prototype converting NIO to
use memory access API.
The fix is very simple and move the call to Module::isNamed only
This looks okay to me.
Mandy
On 5/6/20 6:01 PM, Yumin Qi wrote:
Hi,
Please review the fix for
bug: https://bugs.openjdk.java.net/browse/JDK-8244495
webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/
Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java
failed
On 5/6/20 12:50 PM, Claes Redestad wrote:
On 2020-05-06 16:59, Claes Redestad wrote:
-XX:TieredStopAtLevel=1:
Benchmark Mode Cnt Score Error Units
15-b19 Capture0.lambda_01 avgt 5 6.312 ± 0.919 ns/op
15-b20 Capture0.lambda_01 avgt 5 105.761 ± 7.575
On 5/5/20 3:12 PM, Claes Redestad wrote:
Hi,
in the current implementation MethodHandle.viewAsType eagerly rebinds
when creating a view of a method type as an alternative type:
MethodHandle viewAsType(MethodType newType, boolean strict) {
...
MethodHandle mh = rebind();
a bootstrap argument (classDataType) and to have a
code more straightforward.
Rémi
*De: *"mandy chung"
*À: *"Remi Forax" , "Jorn Vernee"
*Cc: *"Maurizio Cimadamore&
On 4/29/20 2:30 PM, fo...@univ-mlv.fr wrote:
I think the problem with perf might be caused by the fact that while the
array is now a constant, the elements are not (the array is mutable
after all). For fields you can fix this by using @Stable, but not for CP
entries :)
I think you're right,
On 4/29/20 2:07 AM, Simone Bordet wrote:
Did you get any exception in 14? Is it from findVirtual or from in?
From findVirtual():
Exception in thread "main" java.lang.IllegalAccessException: no such
method: org.module1.MyEndPoint.onMessage(MyString)void/invokeVirtual
at
diff --git
a/src/java.base/share/classes/java/lang/invoke/package-info.java
b/src/java.base/share/classes/java/lang/invoke/package-info.java
--- a/src/java.base/share/classes/java/lang/invoke/package-info.java
+++ b/src/java.base/share/classes/java/lang/invoke/package-info.java
@@ -31,7 +31,7
On 4/28/20 12:58 AM, fo...@univ-mlv.fr wrote:
I don't think you need to store all the values into static fields, you
can directly do a ldc + aaload with the right index right where you need it,
I think this is what you are thinking as reported in JDK-8243492:
Hi Simone,
On 4/28/20 5:42 AM, Simone Bordet wrote:
Hi,
in Jetty 10, we use method handles in the WebSocket implementation.
We need to scan WebSocket EndPoint application classes (MyEndPoint)
for annotated methods whose signature may vary and may take
application classes, for example
On 4/27/20 2:42 PM, Remi Forax wrote:
Hi Maurizio, Mandy,
In
https://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev/src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java.udiff.html,
using a condy inside a static init make me sad,
using a late loading constant
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shared app/platform class originated from the module
Pushed: https://hg.openjdk.java.net/jdk/jdk/rev/3a3c806aff1f
Mandy
On 4/24/20 9:17 AM, Mandy Chung wrote:
Yes any change requires a JBS issue.
I can sponsor this trivial fix.
Mandy
On 4/24/20 5:15 AM, Raffaello Giulietti wrote:
Not sure if this requires an entry in the JBS...
Greetings
Yes any change requires a JBS issue.
I can sponsor this trivial fix.
Mandy
On 4/24/20 5:15 AM, Raffaello Giulietti wrote:
Not sure if this requires an entry in the JBS...
Greetings
Raffaello
diff -r 70c2239696ae
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
---
On 4/18/20 12:47 AM, Chris Plummer wrote:
It's a link to
https://download.java.net/java/early_access/jdk15/docs/specs/jni/types.html#type-signatures.
This is how the current JVM TI spec defines.
Since it looks like this reference was present before your changes, I
guess it's ok to leave
On 4/17/20 3:51 PM, Chris Plummer wrote:
Hi Mandy,
Thanks for updating the svc specs. Some comments below:
In the JDWP spec update, you changed "JNI signature" to "type
signature" in one place, but left it as "JNI signature" everywhere
else. Should they all be changed?
JDWP signature
On 4/16/20 11:42 AM, serguei.spit...@oracle.com wrote:
Hi Mandy,
I have a couple of minor comments on the Serviceability spec update.
Svc spec change webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-svc-spec-changes/
thanks
Mandy
[1]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007155.html
Paul.
On Apr 11, 2020, at 8:13 PM, Mandy Chung wrote:
Please review the delta
This looks okay to me.
Can you add the bug ID next to @ignore that will make it easier to find
the JBS issue? These test bugs are filed with P4 but I think they
should be fixed in 15.
Mandy
On 4/15/20 8:56 AM, sundararajan.athijegannat...@oracle.com wrote:
Please review.
Nashorn script
a proxy class
3. include Serguei's patch to fix JDK-8242166: regression in JDI
ClassUnload events
4. drop the uniqueness guarantee of the suffix of the hidden class's name
On 3/31/20 8:01 PM, Mandy Chung wrote:
Thanks to the review feedbacks.
Updated webrev:
http://cr.openjdk.java.net/~mchung/v
I agree with Gil on this point. `PhantomReference::get` always returns
null. The intent behavior of `ref.refersTo(obj)` is the same as
`ref.get() == obj`. Gil's proposed option to have `refersTo(obj)` to
return true only if obj is null is a reasonable one.
If `PhantomReference::get`
On 4/6/20 9:56 AM, serguei.spit...@oracle.com wrote:
The suggested fix is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/valhalla-jdi-regression-8242166.1/
This patch looks okay. I'll include in my local patch.
On 4/6/20 11:00 AM, Chris Plummer wrote:
I think that's fine but I don't
Hi Peter,
On 4/4/20 3:58 AM, Peter Levart wrote:
Here I think, you are not quite right. First I need to clarify that we
are talking about the case where the method reference in above example
is not converted to lambda by javac, so the proxy class needs to
invoke the superclass method
On 4/4/20 9:16 AM, Peter Levart wrote:
Hi Mandy,
Just another observation of the code in InnerClassLambdaMetafactory...
For the useImplMethodHandle case you generate the protectedImplMethod
static field to hold the MH and a static setter method:
mv =
Hi Peter,
I added a JBS comment [1] to describe this special case trying to put
the story together (let me know if it needs more explanation). More
comment inline below.
On 4/3/20 4:40 AM, Peter Levart wrote:
Ok, I think I found one such use-case. In the following example:
package test;
On 4/2/20 1:07 AM, Chris Hegarty wrote:
On 1 Apr 2020, at 19:43, Mandy Chung wrote:
..
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8238195/webrev.00/
LGTM. Trivially, you could update the copyright year range on the test.
Updated.
thanks
Mandy
Hi David,
Thank you for checking thoroughly. I now grep on src/hotspot and clean
all of them.
Updated delta webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.04-delta/
On 4/1/20 11:21 PM, David Holmes wrote:
Hi Mandy,
On 2/04/2020 3:17 pm, Mandy Chung
f so report that as part of the message.
if (fd.is_private()) {
print_nest_host_error_on(, ref_klass, sel_klass, THREAD);
Mandy
On 4/1/20 9:52 PM, David Holmes wrote:
Hi Mandy,
On 1/04/2020 1:01 pm, Mandy Chung wrote:
Thanks to the review feedbacks.
Updated webrev:
http://cr.openjdk.j
IMHO the debugger should do a better job for us rather than we change
the code to work for the debugger.
Mandy
On 3/31/20 12:02 AM, Vipin Mv1 wrote:
Hi All,
Please find the below changes for the issue
https://bugs.openjdk.java.net/browse/JDK-8015413
diff -r 53568400fec3
The spec of `Lookup::defineClass` specifies to throw linkage error
including `VerifyError` and JDK-8238358 fixes the implementation to
match the spec [1].
This patch updates the spec to make it clear as proposed in the
CSR:https://bugs.openjdk.java.net/browse/JDK-8240338. Also add a new
On 4/1/20 7:26 AM, Alan Bateman wrote:
Maybe I missed it going by, but why is the isHidden check in the field
offset methods on sun.misc.Unsafe rather than the internal Unsafe?
The reflection and VarHandle implementation uses
jdk.internal.misc.Unsafe to do field access (both read and
().
So what do you think of this version:
http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/
<http://cr.openjdk.java.net/~clanger/webrevs/8241947.1/> ?
Thanks
Christoph
*From:* Mandy Chung
*Sent:* Dienstag, 31. März 2020 19:34
*To:* Langer, Christoph ;
core-libs-dev@openjdk.java.ne
opyright headers
9. Fix @modules in tests
Most of the changes above have also been reviewed as separate patches.
Thanks
Mandy
On 3/26/20 4:57 PM, Mandy Chung wrote:
Please review the implementation of JEP 371: Hidden Classes. The main
changes are in core-libs and hotspot runtime area. Small cha
Thanks Joe for the quick review.
Mandy
On 3/31/20 4:22 PM, Joe Darcy wrote:
Looks fine Mandy; thanks for doing this cleanup,
-Joe
On 3/31/2020 4:15 PM, Mandy Chung wrote:
This patch cleans up the javadoc in java.lang.Class and replaces
"this object" and "th
This patch cleans up the javadoc in java.lang.Class and replaces "this
object" and "this class object" with "this {@code Class} object"
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8241964/webrev.00/
thanks
Mandy
`, it could be a
class or interface.
Although isHiddenClass seems clearer, I'm okay to rename it to `isHidden`.
Mandy
On 3/31/20 11:06 AM, Mandy Chung wrote:
This patch addresses Joe's feedback on the CSR [1]:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03-delta-jdarcy
the new inline @jvms tag.
Thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8238359
On 3/26/20 4:57 PM, Mandy Chung wrote:
Please review the implementation of JEP 371: Hidden Classes. The main
changes are in core-libs and hotspot runtime area. Small changes are
made in javac, VM
On 3/31/20 7:56 AM, Langer, Christoph wrote:
Hi,
please review a small fix that updates two comments.
The first one, in make/autoconf/spec.gmk.in, is probably quite old. It talks about handling of a property
"vm.vendor" in VersionProps.java.template. However, there is no property
This is the patch to keep the JDK 14 behavior if target release to 14
(thanks to Jan for helping making change in javac to get the tests working)
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/
Mandy
On 3/27/20 9:29 AM, Mandy Chung wrote:
Hi Jan
need tests for these cases. I think these are all
things that can be addressed later.
Good catch. I have created a subtask under JDK-8230502:
https://bugs.openjdk.java.net/browse/JDK-8230502
I still need to look over the JVMTI tests.
Thanks
Mandy
thanks,
Chris
On 3/26/20 4:57 PM, Mandy Chung wro
On 3/27/20 4:01 PM, David Holmes wrote:
Hi Mandy,
On 28/03/2020 8:29 am, Mandy Chung wrote:
Hi Vicente,
hasNestmateAccess is about VM supports static nestmates on JDK
release >= 11.
However this is about javac --release 14 and the compiled classes may
run on JDK 14 that lam
rget is ready for nestmates or
not. I think that you can follow a similar approach here.
Thanks,
Vicente
[1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
On 3/27/20 12:29 PM, Mandy Chung wrote:
Hi Jan,
Good point. The javac change only applies to JDK 15 and later and
the lambd
the
sentence you commented on:
On 3/27/20 1:18 PM, Mandy Chung wrote:
MethodHandles.java
—
1786 * (Given the {@code Lookup} object returned this
method, its lookup class
1787 * is a {@code Class} object for which {@link
Class#getName()} returns a string
1788
On 3/27/20 11:59 AM, Paul Sandoz wrote:
Hi Mandy,
Very thorough, bravo!
Thanks.
Minor suggestions below.
Paul.
MethodHandleNatives.java
—
142
143 /**
144 * Flags for Lookup.ClassOptions
145 */
146 static final int
147
,
Regarding the javac changes - should those be switched on/off
depending the Target? Or, if one compiles with e.g. --release 14, will
the newly generated output still work on JDK 14?
Jan
On 27. 03. 20 0:57, Mandy Chung wrote:
Please review the implementation of JEP 371: Hidden Classes. The main
On 3/27/20 5:00 AM, Remi Forax wrote:
Hi Mandy,
in ReflectionFactory, why in the case of a constructor the check to the
anonymous class is removed ?
Good catch. Fixed
in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
can be promoted on top of clinit, because i ask
Please review the implementation of JEP 371: Hidden Classes. The main
changes are in core-libs and hotspot runtime area. Small changes are
made in javac, VM compiler (intrinsification of Class::isHiddenClass),
JFR, JDI, and jcmd. CSR [1]has been reviewed and is in the finalized
state (see
Hi Magnus,
Modularizing the build tools is a good move. This patch suggests to
place the build tools under
src/$MODULE/share/tools/$PACKAGE/*.java
I think the modular source location of the build tools needs more
discussion, including jigsaw-dev for this discussion.
The JDK source
On 3/20/20 6:51 AM, Alan Bateman wrote:
On 20/03/2020 03:43, Mandy Chung wrote:
Alan, Maurizio,
New webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.02/
newJavaNativeInterfaceLibraries creates a NativeLIbraries for
loading JNI native libraries.
- native
Chung wrote:
On 3/18/20 12:13 PM, Maurizio Cimadamore wrote:
On 18/03/2020 18:40, Mandy Chung wrote:
On 3/18/20 11:16 AM, Maurizio Cimadamore wrote:
So, maybe I'm saying something naive, but isn't the difference
between the two mechanisms mostly there to distinguish between JNI
libraries
On 3/18/20 12:13 PM, Maurizio Cimadamore wrote:
On 18/03/2020 18:40, Mandy Chung wrote:
On 3/18/20 11:16 AM, Maurizio Cimadamore wrote:
So, maybe I'm saying something naive, but isn't the difference
between the two mechanisms mostly there to distinguish between JNI
libraries and non-JNI
newNonJavaNativeLIbraries be slightly clearer?
Mandy
Maurizio
On 18/03/2020 16:32, Mandy Chung wrote:
On 3/18/20 8:59 AM, Alan Bateman wrote:
On 17/03/2020 23:09, Mandy Chung wrote:
I have similar comment to myself and didn't come up good static
factory method names. I give it a try again
On 3/18/20 8:59 AM, Alan Bateman wrote:
On 17/03/2020 23:09, Mandy Chung wrote:
I have similar comment to myself and didn't come up good static
factory method names. I give it a try again: what about
newNativeLibraries and newNativeLibrariesWithNoAutoUnload?
Would
Hi Alan,
Thanks for the comment. See my comments inlined below.
Here is the updated webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.01
On 3/16/20 3:47 AM, Alan Bateman wrote:
The difference between the 2 constructors might not be obvious at the
use sites. I'm just
://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
Thanks
Mandy
[1]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006889.html
[2]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-March/006911.html
On 3/9/20 2:00 PM, Mandy Chung
Webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.00/
This is a follow-up task for Panama to allow explicit unloading of
native library after JDK-8228336. `NativeLibraries` associated with a
class loader has the capability to auto unload native libraries when the
class
This change looks okay.
Mandy
On 3/12/20 1:50 PM, Jonathan Gibbons wrote:
Please review a simple fix regarding the non-standard use of some CSS
in some doc comments.
From the JBS Description:
Recently, for the display of javadoc block tags, javadoc changed from
using an inconsistent set of
On 3/11/20 10:25 AM, Daniel Fuchs wrote:
Hi Mandy,
On 11/03/2020 16:10, Alan Bateman wrote:
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 this helper method in sun.security.action package.
On 3/11/20 12:21 AM, Yangfei (Felix) wrote:
-Original Message-
From: Alan Bateman [mailto:alan.bate...@oracle.com]
Sent: Wednesday, March 11, 2020 3:03 PM
To: Yangfei (Felix) ; core-libs-dev@openjdk.java.net
Subject: Re: RFR(S): 8240734: ModuleHashes attribute not reproducible
between
Hi Chris,
Below is the revised patch per your suggestion. I made some minor fixes
in the method name shown in the "Access modes" section as well.
Mandy
diff --git
a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
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
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
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
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|,
On 3/8/20 11:27 AM, Henry Jen wrote:
Thanks for the review, I updated the webrev[1] with simplified test and ensure
other cases in boundary won’t be causing trouble by only take meaningful tokens.
This fix is more defensive and allow anchor to be ignored when it’s meaningless.
[1]
On 2/18/20 4:50 AM, Severin Gehwolf wrote:
Hi Mandy,
Thanks again for the review!
Updated webrev:
incremental (only review changes):
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/11/incremental/webrev/
full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/11/webrev/
Hi Severin,
On 2/11/20 10:04 AM, Severin Gehwolf wrote:
Updated webrev:
Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/10/webrev/
incremental:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/10/incremental/webrev/
Thanks for updating this. This patch looks okay in
That's great. Thanks.
Mandy
On 2/12/20 11:52 AM, Jonathan Gibbons wrote:
Mandy,
The desire to "highlight" parts of example code has made it onto the
wishlist for a possible new `{@example}` tag for do comments.
-- Jon
On 2/12/20 11:50 AM, Mandy Chung wrote:
On 2/12/20 11:44
On 2/12/20 11:44 AM, Roger Riggs wrote:
Hi Mandy,
I considered breaking it up but none of the other examples have that
kind of markup and it make the source much less easy to maintain.
I'll keep it as is.
Okay with me.
Mandy
Thanks, Roger
On 2/12/20 2:40 PM, Mandy Chung wrote
On 2/12/20 10:52 AM, Roger Riggs wrote:
Please review a trivial doc fix to remove html markup that should not
be inside {@code}.
And a couple of spacing and punctuation fixes.
diff --git
a/src/java.base/share/classes/java/util/stream/package-info.java
.
More below.
On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote:
Hi Severin,
Thanks for the update.
On 1/21/20 11:30 AM, Severin Gehwolf wrote:
Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/09/webrev/
incremental:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/09
Thanks for the quick review, Roger.
Mandy
On 2/4/20 2:01 PM, Roger Riggs wrote:
Looks fine
On 2/4/20 4:48 PM, Mandy Chung wrote:
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
http
ProxyGenerator_v49 was the old proxy generator that has been replaced
with ASM in JDK 14 [1]. This patch removes this old version.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8230047/webrev.00/
thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8207814
On 2/2/20 7:46 PM, li.ji...@oracle.com wrote:
Hi,
Please review the update for L10n resource files in JDK 14 msg drop
20. In this fix, we cover l10n resource files for the MSI installer of
jpackage and the latest update from jdeps and jshell.
On 1/29/20 8:32 AM, Maurizio Cimadamore wrote:
On 28/01/2020 23:31, David Holmes wrote:
I tested again with jdk_core and hotspot_all_no_apps with no new
failures.
Would you or Maurizio mind sponsoring this for me if your testing is
OK?
Sorry, as the bulk of this change is core-libs code
On 1/27/20 6:31 AM, Remi Forax wrote:
I'm a bit curious about this:
To invoke private nestmate instance methods from code in the hidden class, use
invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
that uses invokespecial to invoke a private nestmate instance
On 1/24/20 9:15 PM, Bernd Eckenfels wrote:
Hello,
I wonder will this (weak class) be useful for reflective method
accessors and even be able to reduce/remove the need of
jdk.internal.reflect.DelegatingClassLoaders? If so, that would be a good
example to mention in the JEP (it only
it.
Thank you.
On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote:
MetricsCgroupV1 is linux-only. It will fail the compilation when
building on non-linux.
I don't think so. MetricsCgroupV1 is a new interface in shared code
just like Metrics itself:
src/java.base/share/classes/jdk/internal
Hi Severin,
Thanks for the update.
On 1/21/20 11:30 AM, Severin Gehwolf wrote:
Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/09/webrev/
incremental:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/09/incremental/webrev/
I have answered my own question. Most of
On 1/20/20 2:16 PM, Claes Redestad wrote:
Ok, new version here:
http://cr.openjdk.java.net/~redestad/8236075/open.02/
+1
Mnady
On 1/20/20 12:46 PM, Alan Bateman wrote:
On 20/01/2020 15:54, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other
Hi Claes,
On 1/20/20 7:54 AM, Claes Redestad wrote:
Hi,
some minor cleanups and enhancements in and around java.lang.ClassLoader
which add up to a small startup improvement:
- Remove use of Vector/Hashtable from ClassLoader, along with a few
other improvements/modernizations.
- Refactor
This looks fine to me.
Mandy
On 1/17/20 10:25 AM, Roger Riggs wrote:
Please review this fix to correctly allow null for a custom socket
factory in TCPEndpoint.
issue: https://bugs.openjdk.java.net/browse/JDK-8237368
webrev: http://cr.openjdk.java.net/~rriggs/webrev-proxy-8237368/
Thanks,
On 1/17/20 5:31 AM, Severin Gehwolf wrote:
If I understand you correctly, then we'd have to change how
-XshowSettings:system works currently with it. Not all metrics as
currently printed via LauncherHelper.java are supported in both worlds
(cgroup v1 & v2). It would make handling of cgroup
Hi Bob, Severin,
On 1/9/20 11:51 AM, Severin Gehwolf wrote:
Thanks for the review! Should all be fixed now. Updated webrev:
incremental:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/07/incremental/webrev/
full:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/07/webrev/
Looks okay. I wonder how the word "source" got creeped in :-)
Mandy
On 1/14/20 5:51 PM, Brian Burkhalter wrote:
Oops: correction.
--- a/test/jdk/java/io/Reader/TransferTo.java
+++ b/test/jdk/java/io/Reader/TransferTo.java
@@ -6,15 +6,15 @@
* under the terms of the GNU General Public
+1
Mandy
On 1/14/20 5:49 PM, Brian Burkhalter wrote:
Please review this trivial fix
--- a/test/jdk/java/io/Reader/TransferTo.java
+++ b/test/jdk/java/io/Reader/TransferTo.java
@@ -14,7 +14,7 @@
*
* You should have received a copy of the GNU General Public License version
* 2 along
Pushed.
See https://bugs.openjdk.java.net/browse/JDK-8236945
Mandy
On 1/7/20 9:32 AM, Christoph Dreis wrote:
Hi,
I just noticed that a duplicated "the" slipped into the docs of Lookup.in().
The change seems to have been introduced in
https://bugs.openjdk.java.net/browse/JDK-8226916.
In
+1
Mandy
On 1/9/20 11:22 AM, Joe Darcy wrote:
Hello,
As noted by Werner [1], one of the discussions of the kinds of types
in java.lang.annotation was not updated for records. I checked
java.lang.annotation, java.lang.reflect, and java.lang.Class and found
another location to update:
Hi Christoph,
I'll sponsor this typo fix.
Mandy
On 1/7/20 9:32 AM, Christoph Dreis wrote:
Hi,
I just noticed that a duplicated "the" slipped into the docs of Lookup.in().
The change seems to have been introduced in
https://bugs.openjdk.java.net/browse/JDK-8226916.
In case this is
/workshop-discuss/2019-August/78.html
On 11/8/19 5:49 AM, Adam Farley8 wrote:
Hi Mandy,
Sorry for the delay in responding.
Mandy Chung wrote on 29/10/2019 19:30:55:
> From: Mandy Chung
> To: Adam Farley8
> Cc: core-libs-dev
> Date: 29/10/2019 19:31
> Subject: [EXTERNA
Looks okay.
Mandy
On 12/16/19 1:00 AM, Sureshkumar Mahaliswamy wrote:
Gentle Remainder .
Kindly review , this is just a small patch.
Thanks,
Suresh.
From: Sureshkumar Mahaliswamy
Sent: Wednesday, November 27, 2019 1:16 PM
To: core-libs-dev@openjdk.java.net
Subject:
On 12/9/19 12:17 PM, Jonathan Gibbons wrote:
I note that javac now uses the same definition of tryResolveFile in
its handling of Class-Path manifest entries, and so the behavior for
the compiler and runtime should now be aligned.
Yay!
This patch looks good to me.
Mandy
-- Jon
On
definitions; I
replaced this with a static import.
To make sure a class isn't instantiated, I usually have it throw
AssertionError or some exception, although as you say that isn't
strictly necessary in all cases.
Thanks,
-Joe
On 12/9/2019 10:27 AM, Mandy Chung wrote:
It seems a bit overly
61) ;-)
Thanks all for catching this,
-Joe
On 12/9/2019 9:29 AM, Mandy Chung wrote:
Good catch! Daniel also pointed that out. I overlooked it. It
needs to add back a private no-arg constructor.
Mandy
On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote:
If you remove the deprecated const
to make the deprecated
constructor private and throwing an exception?
Em seg., 9 de dez. de 2019 às 14:13, Mandy Chung
mailto:mandy.ch...@oracle.com>> escreveu:
Looks good.
Mandy
On 12/8/19 10:58 AM, Joe Darcy wrote:
> Hello,
>
> Please review this small API
801 - 900 of 3165 matches
Mail list logo
