On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart wrote:
>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since
> the entire handle method is `static synchronized` and it is the only method
> that modifies the `h
On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd wrote:
>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not
>> `handlers.replace(...)`? And yes, I think what you suggest will help remove
>> the synchronized block here.
>
> Oops, yes you are correct!
Hi,
I think the synchron
On Wed, 25 May 2022 15:54:04 GMT, Maxim Kartashev
wrote:
>> `CgroupV1Subsystem.getInstance(...)` also claims that it never returns
>> `null`, but has a code-path that actually returns `null` (when there is no
>> active controller). Is this a possible outcome?
>
> @plevart Are you asking about
On Wed, 25 May 2022 14:39:42 GMT, Peter Levart wrote:
>> Following the logic from the comment directly above the changed line, since
>> it doesn't matter which controller we pick, pick any available controller
>> instead of the one called "memory" spec
On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev
wrote:
> Following the logic from the comment directly above the changed line, since
> it doesn't matter which controller we pick, pick any available controller
> instead of the one called "memory" specifically. This way we are guarded
> again
er vs. Consumer). No conflicts
should be expected.
Regards, Peter
On Sun, 22 May 2022 16:54:25 GMT, Peter Levart wrote:
> My humble opinion: if java.compiler needs jdk.zipfs for full functionality
Sorry, I wrongly assumed it was `java.compiler` (the library module), but this
is about `jdk.compiler` (the tool)... Nevertheless, the same question appl
On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona wrote:
>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its
>> dependencies
>> fails to run java source launcher correctly (for example when --source N is
>> specified).
>> Failing source launche
On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote:
>> Improving the exception messages for out-of-supported-range array types.
>>
>> I'll update copyrights before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respo
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>> dist
On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy wrote:
> > The mapping from Location to AccessFlag(s) could be implemented event
> > without using a Map. You just have to be careful not to use EnumSet for
> > that (i.e. before AccessFlag enum constants are fully initialized) - an
> > ArrayList is b
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>> dist
On Mon, 28 Feb 2022 18:20:13 GMT, ExE Boss wrote:
>> It does because of the AccessFlags.MODULE constant.
>
>> It does because of the AccessFlags.MODULE constant.
>
> But that’s exactly what the unqualified `MODULE` identifier refers to, and
> there’s no other bare `MODULE` identifier in scope t
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>> dist
On Mon, 17 Jan 2022 08:28:35 GMT, Erik Gahlin wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405:
>>
>>> 403: Object res = m.invoke(a, new Object[0]);
>>> 404: if (res instanceof Annotation[]) {
>>> 405:
t; - Include the stable annotation
>> - Merge branch 'master' into 8261407-reflectionfactory
>> - ... and 3 more:
>> https://git.openjdk.java.net/jdk/compare/73eb6e94...e97ea278
>
> peter and mandy, would you mind review again today?
Latest version looks good to me, @liach. Thanks for doing this.
Regards, Peter
-
PR: https://git.openjdk.java.net/jdk/pull/6889
On Fri, 11 Feb 2022 21:44:04 GMT, Mandy Chung wrote:
> Note that the object methods of this Config record are called via indy which
> is
> available to use after initPhase1. We can workaround that limitation by
> implementing the object methods.
"Note that the object methods of this Config r
On Fri, 11 Feb 2022 13:42:01 GMT, liach wrote:
>> ...having suggested that rearrangement, perhaps the right way to do it is to
>> enable some VM.isXXX queries themselves to be constant-foldable so that
>> other callers too may benefit. Like this:
>> https://github.com/plevart/jdk/commit/e918ccc
On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote:
>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
>> by design, duplicate initialization of ReflectionFactory should be safe as
>> it performs side-effect-free property read actions, and the suggesting of
>> making the
On Fri, 11 Feb 2022 08:05:30 GMT, Peter Levart wrote:
>> liach has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Make config a pojo, move loading code into config class
>
> src/java.base/shar
On Thu, 10 Feb 2022 22:53:56 GMT, liach wrote:
>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
>> by design, duplicate initialization of ReflectionFactory should be safe as
>> it performs side-effect-free property read actions, and the suggesting of
>> making the
>> - Merge branch '8261407-reflectionfactory'
>> - Just use volatile directly to ensure read order
>> - 8261407: ReflectionFactory.checkInitted() is not thread-safe
>
> Updated per suggestion of peter and mandy. Requesting another round of review.
Hi @liach ,
On Sat, 22 Jan 2022 00:00:18 GMT, liach wrote:
>> liach 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 additional commits since
>> the las
On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote:
> Note this matches other places we do the weak-reference loops, for example in
> `MethodType`:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401
This one does
On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev wrote:
> > So, this patch is fine for making ClassCache more robust as a re-usable
> > component inside JDK (checking for non-null return of computeValue). The
> > 2nd change, that apparently shields against unbounded accumulation of
> > garba
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
e
> - Remove unused EntryFuture inner class from ObjectSteamClass
> - Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into
> JDK-8277072
> - Use ClassValue to solve JDK-8277072
> - Use ForceGC instead of System.gc()
> - Convert test to testng
> - Fix
On Mon, 6 Dec 2021 12:12:44 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get recl
On Thu, 2 Dec 2021 16:22:02 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get recl
On Thu, 2 Dec 2021 14:24:06 GMT, Roman Kennke wrote:
>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 2133:
>>
>>> 2131: if (oldReflector != null) {
>>> 2132: reflector = oldReflector;
>>> 2133: }
>>
>> Map.computeIfAbsent(key, () -> new
tier2
>> - [x] tier3
>> - [ ] tier4
>
> Roman Kennke 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 six additional
&
tier2
>> - [x] tier3
>> - [ ] tier4
>
> Roman Kennke 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 six additional
&
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
On Mon, 29 Nov 2021 13:47:19 GMT, Roman Kennke wrote:
> I don't quite understand this: If the Class object is still reachable by the
> app,
1. a weak reference would not get cleared and
2. the Class's ClassLoader would not get unloaded.
...but the ObjectStreamClass instance could still get GC-
On Mon, 15 Nov 2021 19:10:17 GMT, Roman Kennke wrote:
> > If the intent of this change is to alter the lifetimes of the objects in
> > question in a meaningful way, I recommend a CSR for the behavioral
> > compatibility impact.
>
> It would be hard for application code to observe this change:
On Thu, 18 Nov 2021 14:53:38 GMT, Peter Levart wrote:
>> I think @shipilev asks a good question. This could be done completely in the
>> VM without the changes to j.l.ref.Finalizer. The CLI option is for
>> experimenting, at least in the short term, and should be
On Thu, 18 Nov 2021 08:39:52 GMT, Alan Bateman wrote:
>> Yeah, "flag" is `Holder.ENABLED` here. I mean, are Java methods
>> `registerFinalizer` and `runFinalization` called only by VM? If so, can VM
>> check the whole thing on VM side, without going to Java and asking back from
>> there?
>
> I
nates but
before `applyAndDispose` terminates
`with(constructor).apply(consumptorAndDestructor)` - construction, consumption
with arranged resource disposal by arranging to call the passed-in `Runnable`
instance in the `consumptorAndDestructor` function itself.
Both styles are demonstrated above.
Here's the `Try` helper:
https://gist.github.com/plevart/c26e9908573d4a28c709b7218b001ea8
Regards, Peter
-
PR: https://git.openjdk.java.net/jdk/pull/5796
es are demonstrated above.
Here's the `Try` helper:
https://gist.github.com/plevart/c26e9908573d4a28c709b7218b001ea8
Regards, Peter
On Thu, 14 Oct 2021 16:05:19 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java
>> line 86:
>>
>>> 84: }
>>> 85:
>>> 86: private static final int PARAM_COUNT_MASK = 0x00FF;
>>
>> Is this packing logic required? I get it that it
On Tue, 12 Oct 2021 17:42:01 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix left-over assignment
>
> src/java.base/shar
On Fri, 8 Oct 2021 23:31:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis
wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashing function than
On Sat, 25 Sep 2021 10:15:11 GMT, Peter Levart wrote:
> This patch improves reflective access speed as shown by the included
> benchmarks:
>
> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>
> ... and is also a prerequisi
On Mon, 4 Oct 2021 15:49:43 GMT, Peter Levart wrote:
>> This patch improves reflective access speed as shown by the included
>> benchmarks:
>>
>> https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
>>
>> ... an
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Add Constructor benchmarks
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5694/files
- new: https://git
On Sat, 2 Oct 2021 15:31:35 GMT, Peter Levart wrote:
> > I'm fine with going back to the previous iteration. I'd add `@Stable` to
> > the same fields in `Constructor`, too, though.
>
> Good catch. I'll add @stable to select Constructor fields. They are import
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
More @stable fields in Constructor/Field to align them with Method fields
-
Changes:
- all: https://git.openjdk.j
t; with Method Handle) perform better in some circumstances.
Peter Levart has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR.
-
Changes:
- all: https://git.open
On Tue, 28 Sep 2021 22:41:23 GMT, Claes Redestad wrote:
> I'm fine with going back to the previous iteration. I'd add `@Stable` to the
> same fields in `Constructor`, too, though.
Good catch. I'll add @stable to select Constructor fields. They are important
for optimizing `Const` use cases. I'
On Tue, 28 Sep 2021 09:50:45 GMT, Claes Redestad wrote:
> Does `Reflection::new_method/...` (which are natively implemented
> constructors) need any special treatment for them to follow the same
> semantics as a Java-based constructor w.r.t. final field writes? Or could
> they be rewritten to
On Mon, 27 Sep 2021 19:59:00 GMT, Mandy Chung wrote:
> A stray thought is why not most fields in `Field`/`Method`/`Constructor` are
> `final`, as my IDE suggests. I can't find any hotspot code that injects
> values to these fields. Experimentally changing most fields in `Field` to
> final seem
t; with Method Handle) perform better in some circumstances.
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Make Method/Constructor/Field instance fields initialized in the constructors
final
-
Changes:
- all: https://git
On Mon, 27 Sep 2021 17:31:50 GMT, Mandy Chung wrote:
> Looks good to me. Very nice performance improvement.
>
> One minor comment: I think the change in `UnsafeFieldAccessorImpl.java` and
> `UnsafeStaticFieldAccessorImpl.java` isn't necessary since they're final
> fields. It can be reverted.
This patch improves reflective access speed as shown by the included benchmarks:
https://jmh.morethan.io/?gists=902f4b43519c4f96c7abcd14cdc2d27d,ac490481e3001c710d75d6071c10b23a
... and is also a prerequisite to make JEP 416 (Reimplement Core Reflection
with Method Handle) perform better in some
On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad wrote:
> > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for
> > each instance of Method/Field does not help at all.
>
> The added indirection in the "Poly" test might cause the code to fall off the
> inlining cliff, so tha
tant case. I think we should search in this direction... to
make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in
non-constant case. If Unsafe can be better, why not MethodHandles?
>
> On balance I think removing class-spinning might mean a better overall story
> w.r.
benchmark that measures the impact on a real-world use case - the
Jackson (de)serialization:
https://gist.github.com/plevart/3cdc7c366d03822c915a7b3ccd579421
Visualized comparisons:
jdk18+9 vs. mandy:
https://jmh.morethan.io/?gists=f81f8e67ec74c3a5c8110a60ddbf38d7,e41df75
"Const" and "Poly" are the use cases that matter and "Var"
is really very minor case. Unfortunately the "Poly" case for fields has
regression comparing to Unsafe accessors in all our patches. The least
regression (35%) has peter+vh2mh which also has th
you had exactly the same thoughts as me! So this improves the "Var" case
for fields. I also ran tests on my PC with your vh-mh patch on top and here are
visualized results (combined with previous results):
jdk18+9 vs. mandy:
https://jmh.morethan.io/?gists=7b2399cea71d12dfd3434701ddeed02
ocusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request incrementally with one additional
> commit since the last revision:
>
> minor cleanup and more test case.
Ok, here
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
ccessor vs.
overrideFieldAccessor in order for JIT to propagate @Stable-ness down the chain.
I then ran the following JMH benchmarks (not included in my variant of patch
yet) on jdk16, mandy's variant and peter's variant:
https://gist.github.com/plevart/b9c62c8cac9784e2c6d
On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung wrote:
>> This reimplements core reflection with method handles.
>>
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation
>> uses `MethodHandle`. For `Field` accessor, the new implementation uses
>> `VarHandle`.For the
`MethodHandle.asType()` conversion can't populate the higher level
>> cache.
>>
>> The fix is based on [the
>> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
>> made by Peter Levart @plevart back in 2015.
>>
&g
`MethodHandle.asType()` conversion can't populate the higher level
>> cache.
>>
>> The fix is based on [the
>> work](http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodHandle.asTypeCacheLeak/)
>> made by Peter Levart @plevart back in 2015.
>>
&g
other code is
structured. Any change to the structure of that code can brake that logic. I
liked the solution used in previous iterations where an exception handler was
inserted in the MH chain immediately after the DMH which wrapped any Throwable
into InvocationTargetException. So any naked exceptions thrown from MH chain
could be contributed to argument processing. Why did you choose another route?
Regards, Peter
-
PR: https://git.openjdk.java.net/jdk/pull/5027
On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart wrote:
>> src/java.base/share/classes/java/lang/Runtime.java line 662:
>>
>>> 660: * or that any particular number of {@link java.lang.ref.Reference
>>> Reference}
>>> 661: * object
On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. refer
am offering it
> in this pull request without any changes to the JVM behavior.
To share the information... I contacted one of the original authors of Java
annotations, but he doesn't remember anything about the option. Here's the
conversation...
On Thu, Jun 3, 2021 at 1
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
> in
not consistent with tar will make it a strange
hybrid. Trying to find common ground with other JDK tools will make it
less flexible.
Regards, Peter
On 29/06/2021 09:05, Peter Levart wrote:
Hi,
On 29/03/2021 12:46, Jaikiran Pai wrote:
Given the support of -C/-dir is new and -P is
1.txt ./subdir1 -C ../dir2 ./file2.txt
./subdir2
So here's a hint about the behavior of multiple -C options: if the
option is -C, it should follow tar -C behavior.
Regards, Peter
Thanks Seán,
A good explanation. :)
Solaris was a very good platform for exposing and debugging race
conditions, of course we have very good static analysis now.
Regards,
Peter.
On 23/06/2021 5:10 pm, Seán Coffey wrote:
Thank for the feedback Peter. Comments inline.
On 22/06/2021 22:40
expand the SocketPermission to the local subnet, and
it would shrink the size of the generated policy file by eliminating
other SocketPermission grants to IP addresses on the subnet.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly complex in mind, could you give
some practical exampl
On 15/06/2021 10:35, Rafael Winterhalter wrote:
Hi Peter,
thanks for the suggestion. Byte Buddy still baselines to Java 5,
unfortunately method handles are not an option at this point. I am
looking into writing a Byte Buddy build plugin that discovers calls to
PrivilegedAction.run and wraps
ntly using AccessControler.doPrivileged would have to 1st migrate
to using such utility wrapper so you would have to provide an
independent module containing it. But it is a possible solution in the
long run when AccessControler API is removed from JDK.
Regards, Peter
On 15/06/2021 2:23 am, David Lloyd wrote:
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing
personally I wouldn't remove these
classes, but it's not my choice.
--
Regards,
Peter.
VM's with unmaintained OS's.
Peter.
On 14/06/2021 6:37 pm, Alan Bateman wrote:
On 14/06/2021 08:35, Peter Firmstone wrote:
I wouldn't want to see SecurityManager and Policy be neutralized,
it's better to remove it and fail early so people update their
software, there
MBEAN-TRUST"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. Granted to users, so that it can
only be performed after authentication.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
t
need permission implementations to remain compatible.
Whatever happens with JAAS will need to be backported, so we can support
all versions.
Regards,
Peter.
On 14/06/2021 3:54 pm, Alan Bateman wrote:
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the firs
On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote:
>> Standardizes and better specifies the errors thrown by LambdaMetafactory,
>> including for inputs that would not be generated by javac.
>>
>> Does some renaming of core parameters/fields to better reflect their purpose.
>>
>> In the implemen
that?
Peter
> > contains the content of `RuntimeVisibleAnnotations` only). Again, such
> > annotation was RUNTIME retention when its use was compiled into a class,
> > but at runtime such annotation may be updated to have CLASS or even SOURCE
> > retention. Such annotation use is
y useful (a user is using it to solve the problem).
Deprecating it and later removing it would leave such user(s) without a means
to solve such problem(s). So I'm at least for leaving it alone at this point.
Regards, Peter
-
PR: https://git.openjdk.java.net/jdk/pull/4280
On Wed, 2 Jun 2021 22:47:13 GMT, David Holmes wrote:
> On 3/06/2021 2:54 am, Joe Darcy wrote:
>
> > If the reflection runtime doesn't implement the semantics of
> > -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that
> > option now.
>
> I have to agree with Joe now. I mistake
n the first place. So in that sense there is no bug,
> but the code could do with some additional comments.
The problem is that it sometimes skips RUNTIME annotations too. I consider this
a bug.
>
> Cheers,
> David
Regard, Peter
-
PR: https://git.openjdk.java.net/jdk/pull/4280
oesn't mean it won't be needed in
the future. Jaroslav gave a perfect example of the case where it is needed now.
Removing this option means that migrating an annotation from CLASS retention to
RUNTIME becomes almost impossible thing in the real world where no single
per
On Wed, 2 Jun 2021 13:24:10 GMT, David Holmes wrote:
> Sorry now I see what happens. We aren't combining two arrays of
> annotations we're concatenating two streams of byes, each of which
> represents a set of annotations, starting with the length.
>
> The code that receives this on the JDK side
On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach
wrote:
> There doesn't seem to be much support for the complete changes in #4245. To
> get at least something useful from that endeavor I have extracted the test
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it
> in
On Wed, 2 Jun 2021 05:59:05 GMT, David Holmes wrote:
> Sorry Jaroslav but I don't really see this test as a basic functional
> test of the PreserveAllAnnotations flag. There is no need for any
> dynamic retention mode switch. All you need as I've said previously is a
> class with all the CLASS re
On Wed, 2 Jun 2021 12:33:37 GMT, Peter Levart wrote:
> I suggest the following patch for the bug in AnnotationParser:
>
An alternative would be to change the `ClassFileParser::assemble_annotations`
in the VM to no be so "dumb", but to construct correct concatenation.
1 - 100 of 2379 matches
Mail list logo
