On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen wrote:
> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
> primitive arrays by combining values into larger stores.
>
> This PR rewrites the code of appendNull and append(boolean) methods so that
> these two methods
On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen wrote:
> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
> primitive arrays by combining values into larger stores.
>
> This PR rewrites the code of appendNull and append(boolean) methods so that
> these two methods
On Mon, 10 Jun 2024 04:08:41 GMT, Chen Liang wrote:
>> Please review this patch that fixes a critical issue that breaks some Proxy
>> usages.
>>
>> CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible
>> package-private types per
meter classes. This case isn't covered by existing tests, so a new test
> has been added.
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Obtain classloader in security manager friendly code path
-
Changes:
- all: https
On Mon, 10 Jun 2024 02:12:11 GMT, Glavo wrote:
> Things have changed since https://github.com/openjdk/jdk/pull/14636 was
> closed, so let me reopen it.
>
> https://github.com/openjdk/jdk/pull/15386 confirmed that `VarHandle` in BALE
> caused a startup regression. In order to not have any more
Please review this patch that fixes a critical issue that breaks some Proxy
usages.
CONSTANT_Class and CONSTANT_MethodType must fail resolution for inaccessible
package-private types per JVMS 5.4.3.1 and 5.4.3.5, yet such types can appear
in method descriptors in the same class. The proposed
On Sun, 9 Jun 2024 22:45:26 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has
On Sat, 8 Jun 2024 23:30:38 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has
On Sat, 8 Jun 2024 15:51:13 GMT, Brett Okken wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add comments
>
> src/java.base/share/classes/jdk/internal/util/HexDigits.java line 117:
>
>> 115:
>> 116: /**
>>
On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has
On Sat, 8 Jun 2024 06:40:39 GMT, Shaojin Wen wrote:
>> After PR #16245, C2 optimizes stores into primitive arrays by combining
>> values into larger stores. In the UUID.toString method,
>> ByteArrayLittleEndian can be removed, making the code more elegant and
>> faster.
>
> Shaojin Wen has
On Sat, 8 Jun 2024 12:25:54 GMT, Sunmisc Unsafe wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add comments
>
> As far as I know, ByteArrayLittleEndian uses the VarHandle mechanism, which
> more efficiently
On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad wrote:
>> This PR refactors type matching in BootstrapMethodInvoker and adds a few
>> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
>> in particular the ProxyGenerator condys generated for e.g. annotation
>>
On Thu, 6 Jun 2024 18:35:01 GMT, Chen Liang wrote:
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> ut
On Sat, 8 Jun 2024 00:19:55 GMT, Shaojin Wen wrote:
> After PR #16245, C2 optimizes stores into primitive arrays by combining
> values into larger stores. In the UUID.toString method,
> ByteArrayLittleEndian can be removed, making the code more elegant and faster.
I think you mean bug ID
On Fri, 7 Jun 2024 22:16:36 GMT, Joe Darcy wrote:
>> Use the value tag to make the javadoc for various format-related constants
>> more informative to readers. Currently the information is available by
>> following the "Constant Field Values" link.
>>
>> I'll reflow the paragraphs before a
On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
On Fri, 7 Jun 2024 21:05:33 GMT, Joe Darcy wrote:
> Use the value tag to make the javadoc for various format-related constants
> more informative to readers. Currently the information is available by
> following the "Constant Field Values" link.
>
> I'll reflow the paragraphs before a push.
On Fri, 7 Jun 2024 18:47:53 GMT, Claes Redestad wrote:
>> Note that [`ConstantBootstraps::primitiveClass(Lookup, String, Class)`]
>> has a static return type of `Class<?>`, so the following is also needed:
>>
>> /**
>> * Exact type used of the {@link
On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> utility method for the ease of future maintenance.
Ch
On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad wrote:
> This PR refactors type matching in BootstrapMethodInvoker and adds a few
> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
> in particular the ProxyGenerator condys generated for e.g. annotation proxies
>
On Fri, 7 Jun 2024 12:38:24 GMT, Claes Redestad wrote:
>> Trivially move a few private static finals to their respective source type
>> to avoid eagerly loading a few small classes.
>
> Claes Redestad has updated the pull request incrementally with two additional
> commits since the last
On Fri, 7 Jun 2024 12:47:39 GMT, Erik Joelsson wrote:
>> test/jdk/java/rmi/reliability/benchmark/bench/Makefile line 50:
>>
>>> 48: clean:
>>> 49: rm -f *.class .classes
>>> 50:
>>
>> Hmm, shouldn't this newline at EOF be kept? Asking @ all the people who've
>> reviewed this so far,
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> utility method for the ease of future maintenance.
Ch
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> utility method for the ease of future maintenance.
Ch
On Fri, 7 Jun 2024 08:21:58 GMT, Claes Redestad wrote:
> Trivially move a few private static finals to their respective source type to
> avoid eagerly loading a few small classes.
Remember to update the copyright year.
-
Marked as reviewed by liach (Author).
PR Review:
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last
On Thu, 6 Jun 2024 19:30:21 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> mt -> md (desc)
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.ja
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> utility method for the ease of future maintenance.
Ch
On Thu, 6 Jun 2024 19:09:36 GMT, Claes Redestad wrote:
> There are some pre-existing places where we call
> `ReferenceClassDescImpl.ofValidated` directly that could probably be switched
> over to `ConstantUtils.classDesc` for slightly nicer code. Or - if it matters
> - add a
On Thu, 6 Jun 2024 19:01:02 GMT, Claes Redestad wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> mt -> md (desc)
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecia
> In java.base, especially in bytecode generators, we have many different
> methods converting known valid Class and MethodType into ClassDesc and
> MethodTypeDesc. These conversions should be consolidated into the same
> utility method for the ease of future maintenance.
Ch
On Thu, 6 Jun 2024 18:56:51 GMT, Claes Redestad wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
>> utility
from CF objects, to reduce compatibility risks.
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 16 commits:
- Merge branch 'master' of https://github.com/openjdk/jdk into
feature/new-generic-info
- Remove redundant try-
In java.base, especially in bytecode generators, we have many different methods
converting known valid Class and MethodType into ClassDesc and MethodTypeDesc.
These conversions should be consolidated into the same utility method for the
ease of future maintenance.
-
Commit
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Changes requested by liach (Author).
test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>
On Thu, 6 Jun 2024 06:41:48 GMT, ExE Boss wrote:
>> Sean Gwizdak 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
>> commits
tional
> commit since the last revision:
>
> Update test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java
>
> Co-authored-by: Chen Liang
Marked as reviewed by liach (Author).
-
PR Review: https://git.openjdk.org/jdk/pull/19410#pullrequestreview-2099091898
On Wed, 5 Jun 2024 12:00:25 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
@altrisi As trivial and low-effort as this seems, this is actually fixing some
technical debt for legacy
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Fri, 17 May 2024 12:01:23 GMT, Chen Liang wrote:
> Core reflection's generic signature parsing uses an ancient library with
> outdated visitor pattern on a tree model and contains unnecessary
> boilerplates. This is a duplication of ClassFile API's signature model. We
> shou
On Sat, 18 May 2024 05:24:16 GMT, ExE Boss wrote:
>> Core reflection's generic signature parsing uses an ancient library with
>> outdated visitor pattern on a tree model and contains unnecessary
>> boilerplates. This is a duplication of ClassFile API's signature model. We
>> should just move
Core reflection's generic signature parsing uses an ancient library with
outdated visitor pattern on a tree model and contains unnecessary boilerplates.
This is a duplication of ClassFile API's signature model. We should just move
to ClassFile API, which is more throughoutly tested as well.
To
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak wrote:
> Improve the speed of Method.hashCode by caching the hashcode on first use.
> I've seen an application where Method.hashCode is a hot path, and this is a
> fairly simple speedup. The memory overhead is low.
>
> This addresses issue
>
On Wed, 29 May 2024 15:03:15 GMT, Sean Gwizdak wrote:
>> src/java.base/share/classes/java/lang/reflect/Method.java line 99:
>>
>>> 97: private Method root;
>>> 98: // Hash code of this object
>>> 99: private int hash;
>>
>> We can declare this field
On Fri, 31 May 2024 16:18:01 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>> parameters,
>
>
>
> -Zhengyu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Zhengyu Gu
> *Date: *Wednesday, May 29, 2024 at 8:28 PM
> *To: *Chen Liang
> *Cc: *core-libs-dev@openjdk.org
> *Subject: *Re: Question on Lambda function
>
> Hi
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
Marked as reviewed by liach (Author).
-
PR Review:
On Thu, 30 May 2024 19:44:29 GMT, David M. Lloyd wrote:
>> Chen Liang 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 10 addi
On Wed, 22 May 2024 14:33:31 GMT, Aleksey Shipilev wrote:
>> Why can't you do something like this:
>>
>> return cloneArray ? ReflectionFactory.copyClasses(interfaces) : interfaces;
>>
>>
>> Alternatively, your proposal is a good one too; we can rename this
>> `getInterfaces(boolean)` to
On Wed, 22 May 2024 09:39:50 GMT, Aleksey Shipilev wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>>
On Wed, 22 May 2024 12:58:40 GMT, jengebr wrote:
>> Can't this be used by class cloning interfaces too?
>
> @liach I see such an opportunity in `Proxy.getProxyConstructor`, is that what
> you have in mind?
No, I mean here:
On Wed, 22 May 2024 14:24:40 GMT, jengebr wrote:
>> No, I mean here:
>> https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Class.java#L1329
>>
>> (That's also why I suggest putting the utiltiy method in ReflectionFactory
>>
On Tue, 21 May 2024 14:07:29 GMT, jengebr wrote:
> Any suggestions?
I would recommend a new method `copyClasses`/`copyTypes` in
`jdk.internal.reflect.ReflectionFactory`, as it already has related
`copyConstructor` and `getExecutableSharedParameterTypes` methods.
Also, can you rename your
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and
On Thu, 30 May 2024 16:44:21 GMT, Joe Darcy wrote:
>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update symbol files for JDK 23 build 25.
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
Marked as reviewed by liach (Author).
Indeed,
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
Should we extract them to private static utility
On Tue, 21 May 2024 14:33:54 GMT, Chen Liang wrote:
> I propose to add type-checked ConstantPool.entryByIndex and
> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
> ConstantPoolException instead of ClassCastException on type mismatch, which
> can happen
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base
ed Lambda classes) here to stay, we must come up with a coding
> guideline to avoid excessive creation of Lambda classes, any pointers or
> suggestions would be greatly appreciated.
>
>
>
> Best,
>
>
>
> -Zhengyu
>
>
>
> *From: *Chen Liang
> *Date: *Wednesd
view from @asotona. Thanks!
>
> Proposal on mailing list:
> https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brou
/openjdk/jdk/pull/12493 and
https://bugs.openjdk.org/browse/JDK-8302154. You are recommended to create
your own facility to create hidden classes in Java 17 instead of continue
to use LambdaMetafactory explicitly in code.
Regards,
Chen Liang
On Wed, May 29, 2024 at 12:53 PM Zhengyu Gu
wrote:
> He
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
view from @asotona. Thanks!
>
> Proposal on mailing list:
> https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Remove redundant import
---
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
view from @asotona. Thanks!
>
> Proposal on mailing list:
> https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brou
On Fri, 24 May 2024 16:41:33 GMT, Adam Sotona wrote:
>> j.l.classfile.ClassReader instance is exposed in the Class-File API through
>> j.l.classfile.AttributeMapper::readAttribute method only.
>> ClassReader only purpose is to serve as a tool for reading content of a
>> custom attribute in a
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made
On Tue, 28 May 2024 22:20:39 GMT, Pavel Rappo wrote:
>> I believe, it should be `1`. Hear me out. In this method, the `length` is
>> scaled down, whereas in `StringUTF16` it is not. In this method, it's
>> `length`, in `StringUTF16` it's `((byte[]) value).length`.
>
> In fact, if I change it
On Tue, 28 May 2024 14:56:35 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>>
On Tue, 28 May 2024 11:55:30 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Mon, 27 May 2024 16:08:04 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 822:
>>
>>> 820:.iconst_0() // false
>>> 821:.aload(0)// classLoader
>>> 822:.invokestatic(CD_Class, "forName",
>>>
On Thu, 7 Mar 2024 05:33:16 GMT, Lei Zhu wrote:
>> When the specified key did not associated with a value, should check the
>> `key` and `value` type.
>
> Lei Zhu has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Use testNG builtin
On Mon, 27 May 2024 11:47:15 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Mon, 27 May 2024 07:24:47 GMT, Per Minborg wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 1323:
>
>> 1321:
On Mon, 27 May 2024 00:03:41 GMT, ExE Boss wrote:
>> Please review this change that convert dynamic proxies implementations to
>> hidden classes, intended to target JDK 24.
>>
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind
>>
On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations
e (TCS)
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> --
> *From:* Chen Liang
> *Sent:* Wednesday, May 22, 2024 9:37:16 PM
> *To:* Aman Sharma
> *Cc:* core-libs-dev@openjdk.org; leyden-...@openjdk.org
> *Subject:* Re: Determi
view from @asotona. Thanks!
>
> Proposal on mailing list:
> https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brou
On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
> Please review this change that convert dynamic proxies implementations to
> hidden classes, intended to target JDK 24.
>
> Summary:
> 1. Adds new implementation while preserving the old implem
On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
> Please review this change that convert dynamic proxies implementations to
> hidden classes, intended to target JDK 24.
>
> Summary:
> 1. Adds new implementation while preserving the old implem
advantage justifies the migration to
hidden classes.
Chen
On Thu, May 23, 2024 at 6:43 AM Remi Forax wrote:
> - Original Message -
> > From: "Chen Liang"
> > To: "core-libs-dev" , "hotspot-dev" <
> hotspot-...@openjdk.org>, kulla-...@o
On Thu, 23 May 2024 03:28:30 GMT, Chen Liang wrote:
> Please review this change that convert dynamic proxies implementations to
> hidden classes, intended to target JDK 24.
>
> Summary:
> 1. Adds new implementation while preserving the old implem
Please review this change that convert dynamic proxies implementations to
hidden classes, intended to target JDK 24.
Summary:
1. Adds new implementation while preserving the old implementation behind
`-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
2.
On Thu, 23 May 2024 00:58:14 GMT, Joe Darcy wrote:
> As a general comment, please update all the links to "mandated" so that the
> text "implicitly declared" get linked to the MANDATED enum constant.
Should we update the API specification for `Parameter::isImplicit`, which
checks the
;
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <http
view from @asotona. Thanks!
>
> Proposal on mailing list:
> https://mail.openjdk.org/pipermail/classfile-api-dev/2024-May/000512.html
Chen Liang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brou
Hi Lorris,
This mailing list is for Java's core libraries' development. Your issue is
a support request and is not related to Java's core libraries in any way,
thus I recommend you look for tech support or create/find an issue at
bugs.java.com.
Regards, Chen
On Wed, May 22, 2024 at 7:16 AM
gt;> leyden-...@openjdk.org
> >> *Subject:* Re: Deterministic naming of subclasses of
> >> `java/lang/reflect/Proxy`
> >>
> >> Hi Aman,
> >> For `-verbose:class`, it's a JVM argument instead of a program
> argument;
> >> so when you run
I propose to add type-checked ConstantPool.entryByIndex and
ClassReader.readEntryOrNull taking an extra Class parameter, which throws
ConstantPoolException instead of ClassCastException on type mismatch, which can
happen to malformed ClassFiles.
Requesting a review from @asotona. Thanks!
1 - 100 of 1002 matches
Mail list logo
