Re: RFR: 8329099: Undocumented exception thrown by Instruction factory methods accepting Opcode [v4]

2024-04-09 Thread Brian Goetz
On Tue, 9 Apr 2024 09:32:38 GMT, Adam Sotona wrote: >> `IllegalArgumentException` thrown by some static factory methods of the >> following `java.lang.classfile.instruction` interfaces are not documented: >> >> - `ArrayLoadInstruction` >> - `ArrayStoreInstruction` >> - `BranchInstruction` >> -

Re: RFR: 8325371: Missing ClassFile.Option in package summary

2024-04-09 Thread Brian Goetz
On Wed, 3 Apr 2024 08:48:43 GMT, Adam Sotona wrote: > Some of the Class-File API options were not mentioned in the package summary > and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong. > This patch fixes the javadoc. > > Please review. > > Thank you, > Adam Marked as

Re: RFR: 8329955: Class-File API ClassPrinter does not print bootstrap methods arguments

2024-04-09 Thread Brian Goetz
On Tue, 9 Apr 2024 13:39:47 GMT, Adam Sotona wrote: > Class-File API `ClassPrinter` prints many useful info about bootstrap methods > and invoke dynamic instructions, however bootstrap methods arguments are > missing. > This patch fixes bootstrap methods and invoke dynamic instructions

Re: RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface

2024-02-05 Thread Brian Goetz
On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote: > `java.lang.classfile.CodeBuilder` contains more than 230 API methods. > Existing ClassFile API use cases proved the concept one big CodeBuilder is > comfortable. However there are some redundancies, glitches in the naming > conventions,

Re: RFR: 8320971: Use BufferedInputStream.buf directly when param of implTransferTo() is trusted [v15]

2023-12-16 Thread Brian Goetz
On Sat, 16 Dec 2023 15:40:50 GMT, Vladimir Sitnikov wrote: >> @vlsi This is a very interesting solution 朗, but it opens a number of >> questions! 樂 As a start, here are mine: >> * You propose a new public method (`OutputStream.write(ByteBuffer)`) as part >> of your solution. We need to

Re: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview)

2023-11-08 Thread Brian Goetz
On Wed, 1 Nov 2023 15:39:11 GMT, Brian Goetz wrote: >> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: >> >>> 221: previousStage.linkedOrConsumed = true; >>> 222: >>> 223: previousPreviousStage.nextStag

Re: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview)

2023-11-08 Thread Brian Goetz
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote: > This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) src/java.base/share/classes/java/util/stream/Gatherer.java line 44: > 42: * > 43: * Examples of gathering operations include, but is not limited to: > 44: * grouping

Re: RFR: JDK-8319123 : Implementation of JEP-461: Stream Gatherers (Preview)

2023-11-08 Thread Brian Goetz
On Tue, 31 Oct 2023 13:17:51 GMT, Viktor Klang wrote: >> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461) > > src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223: > >> 221: previousStage.linkedOrConsumed = true; >> 222: >> 223:

Re: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API [v13]

2023-09-14 Thread Brian Goetz
On Fri, 8 Sep 2023 10:15:26 GMT, Adam Sotona wrote: >> javap uses proprietary com.sun.tools.classfile library to parse class files. >> >> This patch converts javap to use Classfile API. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with

Re: RFR: 8315541: Classfile API TypeAnnotation.TargetInfo factory methods accept null labels

2023-09-14 Thread Brian Goetz
On Tue, 5 Sep 2023 10:59:09 GMT, Adam Sotona wrote: > This patch performs null checks in to refuse null labels in > TypeAnnotation.TargetInfo implementations. > > Please review. > > Thanks, > Adam Marked as reviewed by briangoetz (Reviewer). - PR Review:

Re: RFR: 8313452: Improve Classfile API attributes handling safety [v3]

2023-09-14 Thread Brian Goetz
On Wed, 6 Sep 2023 15:03:24 GMT, Adam Sotona wrote: >> This PR improved Classfile API attributes handling safety by introduction of >> attribute stability indicator >> and by extension of UnknownAttributesOption to more general >> AttributesProcessingOption. > > Adam Sotona has updated the

Re: RFR: 8313258: RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound error

2023-09-14 Thread Brian Goetz
On Thu, 31 Aug 2023 11:09:05 GMT, Adam Sotona wrote: > Classfile API suppose to throw IllegalArgumentException in situations where > bytecode offset is out of allowed range. Such situation includes invalid > offset parsed from a TypeAnnotation as well as from other CodeAttribute > attributes.

Re: RFR: 8315678: Classfile API ConstantPool::entryCount and ConstantPool::entryByIndex methods are confusing [v3]

2023-09-14 Thread Brian Goetz
On Fri, 8 Sep 2023 10:27:28 GMT, Adam Sotona wrote: >> Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex` >> methods are confusing and unsafe to use without knowledge of constant pool >> specification. >> This patch renames `ConstantPool::entryCount` to

Re: RFR: 8312491: Update Classfile API snippets and examples

2023-07-27 Thread Brian Goetz
On Fri, 21 Jul 2023 09:37:10 GMT, Adam Sotona wrote: > 8312491: Update Classfile API snippets and examples src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1239: > 1237: return ldc(BytecodeHelpers.constantEntry(constantPool(), > value)); > 1238: } > 1239:

Re: RFR: 8311085: Remove implementation detail writeTo from LocalVariable(Type) [v3]

2023-06-30 Thread Brian Goetz
On Fri, 30 Jun 2023 00:51:42 GMT, Chen Liang wrote: >> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which >> should be implementation details. >> >> See >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html >> for context. >> >> This patch

Re: RFR: 8311085: Remove implementation detail writeTo from LocalVariable(Type)

2023-06-29 Thread Brian Goetz
It is irritating that one is a type descriptor and one is a signature, but we can launder that by observing that both are Utf8Entry. On 6/29/2023 9:53 AM, Chen Liang wrote: On Thu, 29 Jun 2023 13:41:17 GMT, Brian Goetz wrote: `LocalVariable` and `LocalVariableType` includes `writeTo

Re: RFR: 8311085: Remove implementation detail writeTo from LocalVariable(Type)

2023-06-29 Thread Brian Goetz
On Thu, 29 Jun 2023 09:59:08 GMT, Chen Liang wrote: > `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which > should be implementation details. > > See > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html > for context. > > This patch moves the

Re: RFR: 8311084: Add typeSymbol() API for applicable constant pool entries

2023-06-29 Thread Brian Goetz
On Thu, 29 Jun 2023 09:59:30 GMT, Chen Liang wrote: > 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, > FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a > typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or >

Re: RFR: 8311084: Add typeSymbol() API for applicable constant pool entries

2023-06-29 Thread Brian Goetz
On Thu, 29 Jun 2023 13:23:51 GMT, Brian Goetz wrote: >> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, >> FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a >> typeSymbol() API to return the nominal/symbolic des

Re: java.util.stream.Stream: API for user-extensible intermediate operations

2023-06-29 Thread Brian Goetz
Please be mindful of the request Viktor made: for feedback on the approach and the API concepts.  It should be pretty clear that low-level details like "unsupportedCombiner" are many levels down below "approach and concepts".  (And, you know the rule: when you bikeshed on a low-level detail

Re: java.util.stream.Stream: API for user-extensible intermediate operations

2023-06-28 Thread Brian Goetz
Thanks for these comments.  To respond indirectly to your point about parallelization, many of the challenges arise from a tradeoff made in designing Spliterator, that arises from the desire to be able to extract parallelism not only from the really easy case (arrays), but also more complex

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v11]

2023-06-09 Thread Brian Goetz
On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona wrote: >> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v11]

2023-06-09 Thread Brian Goetz
Observation: It's dramatic how injecting a tiny amount of shared mutable state ripples throughout the design. After thinking about this some more, I think the main problem is that we are still trying to have the cache be transparent, which means that Classfile is taking on all the complexity

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v9]

2023-06-08 Thread Brian Goetz
I still don't understand this point.  Why are separate tests sharing a context at all? On 6/8/2023 9:26 AM, Adam Sotona wrote: Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare. I can fix our Corpus tests and hope the race condition won't raise

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v10]

2023-06-08 Thread Brian Goetz
On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona wrote: >> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v10]

2023-06-08 Thread Brian Goetz
On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona wrote: >> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v8]

2023-06-08 Thread Brian Goetz
On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona wrote: >> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected

Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v5]

2023-06-05 Thread Brian Goetz
On Mon, 5 Jun 2023 14:42:32 GMT, Adam Sotona wrote: >> Classfile context object and multi-state options have been discussed at >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html >> This patch implements the proposed changes in Classfile API and fixes all >> affected

Re: RFR: 8308842: Consolidate exceptions thrown from Class-File API [v3]

2023-06-05 Thread Brian Goetz
On Mon, 5 Jun 2023 14:38:47 GMT, Adam Sotona wrote: >> Class-File API actually throws wide variety of exceptions based on the >> actual situation. Complete error handling code must cover >> `IndexOutOfBoundsException`, `IllegalStateException` and >> `IllegalArgumentException`. >> >> Based

Re: RFR: 8306697: Add method to obtain String for CONSTANT_Class_info in ClassDesc [v2]

2023-04-27 Thread Brian Goetz
On Sat, 22 Apr 2023 18:40:45 GMT, Chen Liang wrote: >> Add a method `internalName` to `ClassDesc`, and unifies handling of string >> representation of a class constant in CONSTANT_Class_info via >> `ofInternalName` and `internalName` APIs, documented in `ClassDesc` itself. >> In particular,

Re: RFR: 8304846: Provide a shared utility to dump generated classes defined via Lookup API

2023-03-26 Thread Brian Goetz
Since LMF goes through Lookup::defineHiddenClass, does this mean that they will be potentially dumped twice, once through Lookup, and once through LMF? Now that there is a shared implementation, perhaps we should migrate use in LMF to something more like

Re: RFR: 8304161: Add TypeKind.from to derive from TypeDescriptor.OfField

2023-03-15 Thread Brian Goetz
On Tue, 14 Mar 2023 17:12:50 GMT, Chen Liang wrote: > Such an API allows creating TypeKind from both Class and ClassDesc than > having to call descriptorString() explicitly at every use site. > > See > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000240.html > for context.

Re: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes [v2]

2023-03-09 Thread Brian Goetz
src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 390: 388: uniqueList.add(ex); 389: } 390: return uniqueList.stream().map(ex -> ClassDesc.ofDescriptor(ex.descriptorString())).toList(); It would be useful to add a helper method to convert

Re: JEP-198 - Lets start talking about JSON

2023-02-28 Thread Brian Goetz
As you can probably imagine, I've been thinking about these topics for quite a while, ever since we started working on records and pattern matching.  It sounds like a lot of your thoughts have followed a similar arc to ours. I'll share with you some of our thoughts, but I can't be engaging in

Re: RFR: 8292914: Drop the counter from lambda class names [v8]

2023-02-23 Thread Brian Goetz
On Fri, 17 Feb 2023 19:37:59 GMT, David M. Lloyd wrote: >> The class generated for lambda proxies is now defined as a hidden class. >> This means that the counter, which was used to ensure a unique class name >> and avoid clashes, is now redundant. In addition to performing redundant >> work,

Re: RFR: 8292914: Drop the counter from lambda class names [v8]

2023-02-22 Thread Brian Goetz
On Tue, 21 Feb 2023 19:08:30 GMT, Joe Darcy wrote: >> David M. Lloyd has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Many tests have patterns for lambda class names; update them >> - Update comments and javadoc showin the old pattern

Re: RFR: 8292914: Drop the counter from lambda class names [v6]

2023-02-18 Thread Brian Goetz
On Fri, 17 Feb 2023 02:11:10 GMT, Mandy Chung wrote: >> David M. Lloyd has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use a unique index for the dumped lambda class instead of a time stamp > > `this_class` in the classbyte is shown in

Re: RFR: 8292914: Drop the counter from lambda class names [v7]

2023-02-17 Thread Brian Goetz
On Fri, 17 Feb 2023 17:02:56 GMT, David M. Lloyd wrote: >> The class generated for lambda proxies is now defined as a hidden class. >> This means that the counter, which was used to ensure a unique class name >> and avoid clashes, is now redundant. In addition to performing redundant >> work,

Re: RFR: 8292914: Drop the counter from lambda class names

2023-02-15 Thread Brian Goetz
On Wed, 15 Feb 2023 20:46:47 GMT, David M. Lloyd wrote: >> The class generated for lambda proxies is now defined as a hidden class. >> This means that the counter, which was used to ensure a unique class name >> and avoid clashes, is now redundant. In addition to performing redundant >> work,

Re: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v7]

2023-02-15 Thread Brian Goetz
On Mon, 21 Nov 2022 16:46:43 GMT, Strahinja Stanojevic wrote: >> This PR introduces an option to output stable names for the lambda classes >> in the JDK. A stable name consists of two parts: The first part is the >> predefined value `$$Lambda$` appended to the lambda capturing class, and the

Re: RFR: 8292914: Drop the counter from lambda class names

2023-02-15 Thread Brian Goetz
On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd wrote: > The class generated for lambda proxies is now defined as a hidden class. This > means that the counter, which was used to ensure a unique class name and > avoid clashes, is now redundant. In addition to performing redundant work, >

Re: Inconsistencies in the return value (type) of string functions toLower() and toUpper().

2022-06-20 Thread Brian Goetz
What you are suggesting is what we call "specifying the implementation", which is generally not a very good idea. The specification for these methods says "returns a String following properties>".  That's a good specification!  It says what you can expect from the result.  It says nothing