On Mon, 22 Feb 2021 21:57:00 GMT, Paul Sandoz wrote:
> Add missing classpath exception paragraph
Marked as reviewed by mchung (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2678
On Tue, 16 Feb 2021 22:27:12 GMT, Mandy Chung wrote:
> Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
> to use ForceGC from test library which has additional instrumentation to
> diagnose problem. In addition, this will get the fix for JDK-8258007.
Update test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java to
use ForceGC from test library which has additional instrumentation to diagnose
problem. In addition, this will get the fix for JDK-8258007.
-
Commit messages:
- fix copyright header update
- update c
On Fri, 12 Feb 2021 02:10:02 GMT, Coleen Phillimore wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Consolidate verifyClassname and verifyFixClassname
>
> This more limited cleanup looks good.
This patch changes
On Thu, 4 Feb 2021 16:14:57 GMT, Claes Redestad wrote:
>> This patch resolves a potential memory leak in
>> Java_java_lang_ClassLoader_defineClass0
>>
>> I've not figured a good way to write a regression test. A crude way to
>> manually verify the leak and the fix is provided by the added micr
On Wed, 3 Feb 2021 19:42:16 GMT, Johannes Kuhn
wrote:
>> `MethodHandle -> Method.invoke -> MethodHandles.lookup() ` is a corner case
>> that can be fixed easily using the class data approach. See the new commit.
>
> The security issue I mentioned was in an other branch, method-invoke.
>
> I
On Wed, 3 Feb 2021 12:21:30 GMT, Claes Redestad wrote:
> This patch moves some sanity checking done in ClassLoader.java to the
> corresponding endpoints in native or VM code.
I'm unsure the benefit of moving the check done by `checkName` to the VM but
`preDefineClass` still calls `checkName`.
On Wed, 3 Feb 2021 17:35:30 GMT, Johannes Kuhn
wrote:
>> Last night, I had a second thought that the fix for these two JBS issues
>> does not need the class data. It's more for a future use. I plan to revise
>> it and drop class data in this fix anyway.
>
> You are right, got it confused wit
ensures that
> no new non-static non-final caller-sensitive method will be added to the JDK.
> I extend this test to catch that non-static non-final caller-sensitive method
> cannot have the alternate implementation taking the additional caller class
> parameter.
>
> This fix for J
On Wed, 3 Feb 2021 12:08:58 GMT, Claes Redestad wrote:
> This moves the tracing methods added to GenerateJLIClassesHelper in
> JDK-8252725 to MethodHandleStatics, which avoids loading at runtime some code
> meant for jlink.
Marked as reviewed by mchung (Reviewer).
src/java.base/share/classes/
On Wed, 3 Feb 2021 17:20:40 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1205:
>>
>>> 1203: Class invokerClass = new Lookup(targetClass)
>>> 1204: .makeHiddenClassDefiner(name,
On Wed, 3 Feb 2021 10:52:41 GMT, Johannes Kuhn
wrote:
>> JDK-8013527: calling MethodHandles.lookup on itself leads to errors
>> JDK-8257874: MethodHandle injected invoker doesn't have necessary private
>> access
>>
>> Johannes Kuhn is also a contributor to this patch.
>>
>> A caller-sensitive
JDK-8013527: calling MethodHandles.lookup on itself leads to errors
JDK-8257874: MethodHandle injected invoker doesn't have necessary private access
Johannes Kuhn is also a contributor to this patch.
A caller-sensitive method can behave differently depending on the identity
of its immediate calle
Hi Johannes,
I reconsidered the solution I implemented for JDK-8013527 that I
mentioned [1]. I finally had the time to get back to this. I see the
merit of your idea to bind directly to an alternate implementation of
MethodHandles::lookup taking an additional caller class parameter (but
no
On Thu, 28 Jan 2021 00:34:08 GMT, Brent Christian wrote:
>> Mahendra Chhipa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implemented the review comments.
>
> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 158:
On Mon, 1 Feb 2021 21:54:50 GMT, Mandy Chung wrote:
>> Mahendra Chhipa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implemented the review comments.
>
> Marked as reviewed by mchung (Reviewer).
I thin
On Mon, 1 Feb 2021 21:46:00 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Implemented the review comments.
Marked as reviewed by mchung
On Mon, 1 Feb 2021 20:27:00 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Implemented the review comments.
Thanks for the update. This
Hi Johannes,
I believe you are aware of the prototype I'm working on:
https://github.com/mlchung/jdk/tree/method-invoke
My prototype so far replaces method and fields but not constructors
yet. You are welcome to contribute.
My main motivation of doing this is to get rid of the old clunk
On Tue, 26 Jan 2021 22:30:03 GMT, Mandy Chung wrote:
>> To avoid the Checkstyle warnings, I added them.
>
> Is it from your IDE configurations? You can turn off Checkstyle warnings.
> This just adds noise.
I also assume some of the formatting changes are changed by your IDE
s
On Mon, 25 Jan 2021 19:33:08 GMT, Mahendra Chhipa
wrote:
>> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 103:
>>
>>> 101: createAndWriteEnclosingClasses(enclosingPath, pkg2File,
>>> "pkg1.pkg2");
>>> 102:
>>> 103: String javacPath = JDKToolFinder.get
On Mon, 25 Jan 2021 20:51:06 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Implemented the review comments.
test/jdk/java/lang/Class/for
On Fri, 22 Jan 2021 16:52:02 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> NonJavaName Tests updated
> Used newInstance() method to cre
ntally with one additional
> commit since the last revision:
>
> Implement suggestions by Mandy Chung.
Looks good. What tests have you ran?
-
Marked as reviewed by mchung (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2171
On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn
wrote:
> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
> Added test case that exercises all cases.
>
> This is a behavioral change, from throwing an unspecified exception to
> throwing an IllegalArgumentException, as specif
On Wed, 20 Jan 2021 18:47:18 GMT, Claes Redestad wrote:
>> Change `MethodHandles.byteArrayViewVarHandle` to throw
>> `ArrayIndexOutOfBoundsException` rather than the more generic
>> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
>> risk for subtle behavioral mismatc
On Tue, 19 Jan 2021 20:59:24 GMT, Claes Redestad wrote:
> I agree the change is allowable within the current spec. The behavior change
> is observable, though, and however unlikely there might be code that relies
> on exact class of the exception being thrown.
> So while perhaps not strictly ne
On 1/19/21 12:33 PM, Claes Redestad wrote:
On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung wrote:
The change to AIOOBE is reasonable. Have you considered making this just as an
implementation change and leave the spec as is?
What would be the benefits? AFAICT the CSR is still needed since
On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote:
> Change `MethodHandles.byteArrayViewVarHandle` to throw
> `ArrayIndexOutOfBoundsException` rather than the more generic
> `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the
> risk for subtle behavioral mismatch wh
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote:
>> Please review this change which fixes the type of the private
>> Reference.discovered field. It was Reference, but that's wrong because
>> it can be any Reference object.
>>
>> I've changed it to Reference and let that flow through, updati
ls%3Acomment-tabpanel#comment-13611844
On 09-Dec-20 21:09, Johannes Kuhn wrote:
On 09-Dec-20 19:44, Mandy Chung wrote:
On 12/8/20 6:02 PM, Johannes Kuhn wrote:
There are a lot of things to consider when trying to fix JDK-8013527.
Exactly in particular security implication! What is clear
On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote:
>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one
On Fri, 18 Dec 2020 23:37:11 GMT, Brent Christian wrote:
>> This change adds some extra test output for NativeLibraryTest, primarily via
>> an update to the ForceGC utility class.
>>
>> It was observed that there was nothing preventing the Cleaner from cleaning
>> the short-lived Object that F
On Fri, 18 Dec 2020 22:33:11 GMT, Brent Christian wrote:
> This change adds some extra test output for NativeLibraryTest, primarily via
> an update to the ForceGC utility class.
>
> It was observed that there was nothing preventing the Cleaner from cleaning
> the short-lived Object that ForceG
Hi Johannes,
I'm glad to see this prototype. Converting dynamic proxy to hidden
classes has a few challenges as JDK-8242888 describes.
1) the serialization specification w.r.t. dynamic proxies
We need to look into the implication to the specification and whether
the default serialization me
I think https://bugs.openjdk.java.net/browse/JDK-8199149 is the relevant
RFE.
Mandy
On 12/12/20 8:07 AM, Remi Forax wrote:
A student of mine send me a code that can be reduced to this code
---
import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;
public class ThereIsAB
On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote:
> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
> classes with RecordComponents attributes.
>
> See the discussion at
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-Decem
, returns NULL. This does not check if it's a
> record class or not. So it may return non-null on a non-record class if it
> has `Record` attribute. So `JVM_GetRecordComponents` returns the content of
> the classfile.
>
> tier1-tier3 and jck-runtime:vm and jck-runtime
, returns NULL. This does not check if it's a
> record class or not. So it may return non-null on a non-record class if it
> has `Record` attribute. So `JVM_GetRecordComponents` returns the content of
> the classfile.
>
> tier1-tier3 and jck-runtime:vm and jck-runtime
On Thu, 10 Dec 2020 22:59:16 GMT, Mandy Chung wrote:
>> Hi Remi,
>>
>>> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i
>>> prefer VM to be oblivious about java.lang.Record.
>>> And in the future, the real fix is to change t
On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote:
> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
> classes with `RecordComponents` attributes. That introduces a regression in
> `InstanceKlass::is_record` that returns true on a non-record class
This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
classes with RecordComponents attributes.
See the discussion at
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html
That fixes trusting final fields of records to align with the JLS defi
On Thu, 10 Dec 2020 22:56:34 GMT, Mandy Chung wrote:
>> Marked as reviewed by chegar (Reviewer).
>
> Hi Remi,
>
>> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i
>> prefer VM to be oblivious about java.lang.Record.
>> And in the
On Thu, 10 Dec 2020 14:13:27 GMT, Chris Hegarty wrote:
>> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
>> classes with `RecordComponents` attributes. That introduces a regression in
>> `InstanceKlass::is_record` that returns true on a non-record class which has
On 12/8/20 6:02 PM, Johannes Kuhn wrote:
There are a lot of things to consider when trying to fix JDK-8013527.
Exactly in particular security implication! What is clear is that the
expected lookup class should not be the injected class. The key
message here is that we can't fix JDK-8257
On Tue, 8 Dec 2020 02:36:01 GMT, Mandy Chung wrote:
> `Reference::isEnqueued` method was never implemented as it was initially
> specified since 1.2. The specification says that it tests if this reference
> object has been enqueued, but the long-standing behavior is to tes
On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote:
> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
> classes with Record attributes. That introduces a regression in
> `InstanceKlass::is_record` that returns true on a non-record class
On 12/8/20 5:07 AM, Johannes Kuhn wrote:
On 08-Dec-20 5:40, Mandy Chung wrote:
Thanks David. I was about to create one.
This is indeed a gap in injecting this trampoline class for
supporting @CallerSensitive methods. The InjectedInvoker ensures
that the InjectedInvoker class has the
This is a follow-up on JDK-8255342 that removes non-specified JVM checks on
classes with Record attributes. That introduces a regression in
`InstanceKlass::is_record` that returns true on a non-record class which has
`RecordComponents` attribute present. This causes unexpected semantics in
`
eued`. Also the spec is updated
> to match the long-standing behavior.
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386
Mandy Chung has updated the pull request incrementally with one additional
commit since the last revision:
improve the deprecation message
On Tue, 8 Dec 2020 19:35:39 GMT, Alan Bateman wrote:
>> Mandy Chung has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four addi
eued`. Also the spec is updated
> to match the long-standing behavior.
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8189386
Mandy Chung has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy wrote:
>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains 12 addi
On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote:
>> Please review this fix for JDK-8256867. This change no longer throws a
>> ClassFormatError exception when loading a class whose PermittedSubclasses
>> attribute is empty (contains no classes). Instead, the class is treated as
>> a seal
On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung wrote:
>> @wangweij Moving build tools is a related, but separate, question, which is
>> addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>>
>> I send out a review earlier this year (see
>> https://m
On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie wrote:
>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into
>> java.base as well?
>>
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is
>
On Tue, 8 Dec 2020 17:38:12 GMT, Chris Hegarty wrote:
>> src/java.base/share/classes/java/lang/Class.java line 4399:
>>
>>> 4397: * that is {@link #isSealed()} returns {@code false}, then this
>>> method returns {@code null}.
>>> 4398: * Conversely, if {@link #isSealed()} returns {@co
On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote:
> Please review this change that eliminates the use of Reference.isEnqueued by
> tests. There were three tests using it:
>
> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java
> jd
On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel wrote:
>> Please review this fix for JDK-8256867. This change no longer throws a
>> ClassFormatError exception when loading a class whose PermittedSubclasses
>> attribute is empty (contains no classes). Instead, the class is treated as
>> a seal
On Tue, 8 Dec 2020 05:01:08 GMT, Kim Barrett wrote:
>> `Reference::isEnqueued` method was never implemented as it was initially
>> specified since 1.2. The specification says that it tests if this reference
>> object has been enqueued, but the long-standing behavior is to test if this
>> refer
Thanks David. I was about to create one.
This is indeed a gap in injecting this trampoline class for supporting
@CallerSensitive methods. The InjectedInvoker ensures that the
InjectedInvoker class has the same class loader as the lookup class.
W.r.t. your patch, it seems okay but I have to
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> I have reviewed all lines in the patch file with or near
`Reference::isEnqueued` method was never implemented as it was initially
specified since 1.2. The specification says that it tests if this reference
object has been enqueued, but the long-standing behavior is to test if this
reference object is in its associated queue, only reflecting the state
On Mon, 7 Dec 2020 21:29:23 GMT, Lois Foltan wrote:
>> Please review this fix for JDK-8256867. This change no longer throws a
>> ClassFormatError exception when loading a class whose PermittedSubclasses
>> attribute is empty (contains no classes). Instead, the class is treated as
>> a sealed
On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote:
> Please review this fix for JDK-8256867. This change no longer throws a
> ClassFormatError exception when loading a class whose PermittedSubclasses
> attribute is empty (contains no classes). Instead, the class is treated as a
> sealed c
On Mon, 7 Dec 2020 23:52:29 GMT, Brent Christian wrote:
>> Please review this fix for the intermittently-failing
>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java.
>>
>> The change replaces System.gc()+sleep() with the more robust gcAwait()
>> mechanic used elsewhere in the test ba
On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote:
> Please review this fix for JDK-8256867. This change no longer throws a
> ClassFormatError exception when loading a class whose PermittedSubclasses
> attribute is empty (contains no classes). Instead, the class is treated as a
> sealed c
On Mon, 7 Dec 2020 21:30:18 GMT, Lois Foltan wrote:
>> Please review this fix for JDK-8256867. This change no longer throws a
>> ClassFormatError exception when loading a class whose PermittedSubclasses
>> attribute is empty (contains no classes). Instead, the class is treated as
>> a sealed
On Mon, 7 Dec 2020 19:30:28 GMT, Brent Christian wrote:
>> Please review this fix for the intermittently-failing
>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java.
>>
>> The change replaces System.gc()+sleep() with the more robust gcAwait()
>> mechanic used elsewhere in the test ba
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote:
> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
>
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class"
On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote:
> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
> avoid keeping a referent strongly reachable that could cause unnecessary
> delay in collecting such object. I only made change in some but not all
n `Reference::refersTo`.
> The remaining uses are left for the component owners to convert at
> appropriate time.
Mandy Chung has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 15 commits:
- revise matchsKey to check equality i
On Fri, 4 Dec 2020 20:14:13 GMT, Peter Levart wrote:
>> Good point on checking k != null. A cleaner check:
>>
>> // then check for equality if the referent is not cleared
>> Object k = e.get();
>> return k != null || key.equals(k);
>
> You meant: `return k != null && key.
On Fri, 4 Dec 2020 19:47:17 GMT, Peter Levart wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>> clas
On Fri, 4 Dec 2020 20:05:23 GMT, Kevin Rushforth wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>> c
On Fri, 4 Dec 2020 18:12:36 GMT, Kim Barrett wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>> class
On Fri, 4 Dec 2020 18:23:55 GMT, Brent Christian wrote:
> Please review this fix for the intermittently-failing
> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java.
>
> The change replaces System.gc()+sleep() with the more robust gcAwait()
> mechanic used elsewhere in the test base, [
On Fri, 4 Dec 2020 09:19:23 GMT, Aleksey Shipilev wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>>
On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda wrote:
>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>>
>> From the original PR:
>>
>>> Please review the code for the second iteration of sealed classes. In this
>>> iteration we are:
>>>
>>> * Enhancing narrowing refe
This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
avoid keeping a referent strongly reachable that could cause unnecessary delay
in collecting such object. I only made change in some but not all classes in
core libraries when working with Kim on `Reference::refersTo
On Thu, 3 Dec 2020 19:10:46 GMT, Mandy Chung wrote:
> VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build
> and slow mac os machines. I can't reproduce this locally. It fails on jdk
> 16 internal testing on a few builds. I propose to increase the time
VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build and
slow mac os machines. I can't reproduce this locally. It fails on jdk 16
internal testing on a few builds. I propose to increase the timeout and see if
that is adequate or not. We will re-examine this test if the
On Wed, 2 Dec 2020 14:40:15 GMT, Jan Lahoda wrote:
>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>>
>> From the original PR:
>>
>>> Please review the code for the second iteration of sealed classes. In this
>>> iteration we are:
>>>
>>> * Enhancing narrowing refe
On Thu, 3 Dec 2020 09:58:16 GMT, Alan Bateman wrote:
>> The attribute_length of known Module attributes in the module-info.class
>> is currently ignored. It should be checked and the class rejected if the
>> attribute length doesn't exactly match the length of the info in the
>> attribute.
On Thu, 3 Dec 2020 16:07:28 GMT, Lois Foltan wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Improving Class.getPermittedSubclasses to filter out permitted classes
>> that are not a subtype of the current class, and
On Tue, 24 Nov 2020 10:58:43 GMT, Alan Bateman wrote:
> The attribute_length of known Module attributes in the module-info.class
> is currently ignored. It should be checked and the class rejected if the
> attribute length doesn't exactly match the length of the info in the
> attribute.
>
On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda wrote:
> Additional changes may be needed to Class.permittedSubclasses() and/or
> Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed
> to treat classes with empty PermittedSubclasses attributes as sealed classes
> that canno
On Wed, 2 Dec 2020 01:12:17 GMT, Calvin Cheung wrote:
>> Please review this change which includes:
>>
>> - If the `jdk.internal.lambda.disableEagerInitialization`property is
>> enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive
>> lambda proxy classes or to find them fr
On Tue, 1 Dec 2020 23:16:13 GMT, Calvin Cheung wrote:
>> Please review this change which includes:
>>
>> - If the `jdk.internal.lambda.disableEagerInitialization`property is
>> enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive
>> lambda proxy classes or to find them fr
On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda wrote:
> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>
> From the original PR:
>
>> Please review the code for the second iteration of sealed classes. In this
>> iteration we are:
>>
>> * Enhancing narrowing reference c
On Tue, 1 Dec 2020 16:49:03 GMT, Jan Lahoda wrote:
>> So it could also return a class listed in `PermittedSubclasses` attribute
>> but not a subclass of this sealed class, right?
>>
>> The specification of `Class::getPermittedSubclasses` says:
>>
>>> Returns an array containing {@code Class} o
On Tue, 1 Dec 2020 21:58:16 GMT, Calvin Cheung wrote:
>> Please review this change which includes:
>>
>> - If the `jdk.internal.lambda.disableEagerInitialization`property is
>> enabled, the `InnerClassLambdaMetafactory` will not involve CDS to archive
>> lambda proxy classes or to find them fr
On Tue, 1 Dec 2020 20:13:14 GMT, Chris Hegarty wrote:
>> Update Class::isRecord to only return true for classes that are final.
>>
>> The removal of non-specified JVM checks on classes with a Record Attribute
>> (see JDK-8255342), has resulted in more types of loadable classes that may
>> cont
On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote:
> Please review this change which includes:
>
> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled,
> the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda
> proxy classes or to find them from an
On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote:
> Update Class::isRecord to only return true for classes that are final.
>
> The removal of non-specified JVM checks on classes with a Record Attribute
> (see JDK-8255342), has resulted in more types of loadable classes that may
> contain a
On Tue, 1 Dec 2020 19:34:11 GMT, Chris Hegarty wrote:
> Update Class::isRecord to only return true for classes that are final.
>
> The removal of non-specified JVM checks on classes with a Record Attribute
> (see JDK-8255342), has resulted in more types of loadable classes that may
> contain a
On Tue, 22 Sep 2020 22:38:04 GMT, Mandy Chung wrote:
> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
>
> The implementation looks up a method handle for `invokespecial` instruction
> as if calle
is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
>
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
>
> [1]
&
On Thu, 26 Nov 2020 09:38:15 GMT, Alan Bateman wrote:
>> This is a corner case that arises when creating a Configuration for a child
>> module layer. If an explicit module in the child configuration reads an
>> automatic module in a parent configuration then it should read all automatic
>> mod
On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda wrote:
>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>>
>> From the original PR:
>>
>>> Please review the code for the second iteration of sealed classes. In this
>>> iteration we are:
>>>
>>> * Enhancing narrowing ref
501 - 600 of 3335 matches
Mail list logo
