On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request wit
On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request wit
On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request wit
On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request wit
On Mon, 10 Feb 2025 13:23:49 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request wit
On Tue, 4 Feb 2025 16:56:53 GMT, Coleen Phillimore wrote:
>> Aside from JVMTI (CFLH for example), is there anything left in the VM that
>> needs this? The last param to JVM_DefineClassWithSource has the location
>> from the code source if available.
>
> The VM doesn't need this but it carries i
On Mon, 10 Feb 2025 10:09:59 GMT, David Holmes wrote:
>> Because the field is final, it has to be initialized in the constructor in
>> Java code. My initial patch for modifiers chose to initialize to zero but
>> that's not quite correct. The constructor cannot be called nor can it be
>> made
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request with a new target base due to a
merge or a rebase. The pull request n
On Thu, 6 Feb 2025 12:12:59 GMT, Coleen Phillimore wrote:
>> I am still missing what can actually set a PD here, sorry. ??
>
> Because the field is final, it has to be initialized in the constructor in
> Java code. My initial patch for modifiers chose to initialize to zero but
> that's not qui
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
On Thu, 6 Feb 2025 14:33:24 GMT, Alan Bateman wrote:
>> Coleen Phillimore has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Update
>> test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
>>
>>Co-authored-by: D
On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incr
On Thu, 6 Feb 2025 07:29:26 GMT, David Holmes wrote:
>> @DanHeidinga suggested this for my other PR as a convention that's used for
>> the j.l.Class constructor.
>
> I am still missing what can actually set a PD here, sorry. ??
Because the field is final, it has to be initialized in the constru
On Wed, 5 Feb 2025 17:41:22 GMT, Coleen Phillimore wrote:
>> src/java.base/share/classes/java/lang/Class.java line 239:
>>
>>> 237: * generated.
>>> 238: */
>>> 239: private Class(ClassLoader loader, Class arrayComponentType,
>>> ProtectionDomain pd) {
>>
>> If this constructor i
On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incr
On Wed, 5 Feb 2025 17:57:29 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incr
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request incrementally with three
additional commits since the last revision:
On Wed, 5 Feb 2025 05:35:58 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix test that knows which fields are hidden from reflection in jvmci.
>
> src/java.base/share/classes/java/lang/Cla
On Mon, 3 Feb 2025 16:11:06 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incr
On Tue, 4 Feb 2025 16:37:10 GMT, Alan Bateman wrote:
>> One of the reasons I wanted to move this out of Hotspot as a native call is
>> that it might make further work with ProtectionDomain easier to do all in
>> Java, except there's still a bit of coupling in the JVM with the name of the
>> cl
On Tue, 4 Feb 2025 14:59:46 GMT, Coleen Phillimore wrote:
>> There may need to be some follow-on cleanup, e.g. I'm wondering if
>> Lookup.cachedProtectionDomain is needed now.
>
> One of the reasons I wanted to move this out of Hotspot as a native call is
> that it might make further work with
On Tue, 4 Feb 2025 14:06:07 GMT, Alan Bateman wrote:
>> Thanks for looking at this. I didn't want to change this with this change.
>
> There may need to be some follow-on cleanup, e.g. I'm wondering if
> Lookup.cachedProtectionDomain is needed now.
One of the reasons I wanted to move this out
On Fri, 31 Jan 2025 17:16:11 GMT, Coleen Phillimore wrote:
>> src/java.base/share/classes/java/lang/System.java line 2150:
>>
>>> 2148: }
>>> 2149:
>>> 2150: public ProtectionDomain protectionDomain(Class c) {
>>
>> This accessor has become pointless since the functinoa
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
On Mon, 3 Feb 2025 14:31:28 GMT, Coleen Phillimore wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request with a new target base due to a
merge or a rebase. The incremental we
On Fri, 31 Jan 2025 17:22:37 GMT, Aleksey Shipilev wrote:
> I am thinking if anything new happens if we can reflect the field,
> `setAccessible(true)` it, and overwrite it. I guess the normal protection
> rules disallow the `setAccessible` part, but it does not hurt to think and
> confirm this
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Coleen Phillimore has updated the pull request incrementally with one
additional commit since the last revision:
On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote:
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
I was thinking of what happens if you use setAccessible(
On Fri, 31 Jan 2025 17:14:39 GMT, Coleen Phillimore wrote:
> One thing to think about: does this mean `protectionDomain` is now
> discoverable by reflection? Should it be? Should it be filtered?
Class::getProtectionDomain is a public API so anyone looking for it doesn't
need reflection, but ma
On Fri, 31 Jan 2025 17:17:04 GMT, Alan Bateman wrote:
> > One thing to think about: does this mean `protectionDomain` is now
> > discoverable by reflection? Should it be? Should it be filtered?
>
> Class::getProtectionDomain is a public API so anyone looking for it doesn't
> need reflection, b
On Fri, 31 Jan 2025 16:51:07 GMT, Chen Liang wrote:
>> This change removes the native call and injected field for ProtectionDomain
>> in the java.lang.Class instance, and moves the field to be declared in Java.
>> Tested with tier1-4.
>
> src/java.base/share/classes/java/lang/System.java line 21
On Fri, 31 Jan 2025 17:06:13 GMT, Aleksey Shipilev wrote:
> One thing to think about: does this mean protectionDomain is now discoverable
> by reflection? Should it be? Should it be filtered?
We hid it in the past so it wouldn't be discoverable, but with the removal of
the security manager, th
On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote:
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Reflection filtering was mostly a legacy measure to avoi
On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote:
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
One thing to think about: does this mean `protectionDoma
On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote:
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
Marked as reviewed by liach (Reviewer).
src/java.base/s
This change removes the native call and injected field for ProtectionDomain in
the java.lang.Class instance, and moves the field to be declared in Java.
Tested with tier1-4.
-
Commit messages:
- Fix the test.
- 8349145: Make Class.getProtectionDomain() non-native
Changes: https://
39 matches
Mail list logo
