On Mon, 6 Feb 2023 14:25:54 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line
>> 1371:
>>
>>> 1369: }
>>> 1370:
>>> 1371: default CodeBuilder tableswitch(Label defaultTarget,
>>> List cases) {
>>
>> `switch` seems the one instruction
On Mon, 6 Feb 2023 13:50:07 GMT, Adam Sotona wrote:
>> Actually, we also have a ClassfileVersion class, so that could be a better
>> place for version numbers?
>
> There were several iterations of "where to store numeric constants".
> It is hard to find them when spread across many classes and
On Mon, 6 Feb 2023 14:13:36 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:
>>
>>> 38: * to the end of the buffer, as well as to create constant pool entries.
>>> 39: */
>>> 40: public sealed interface BufWriter
>>
>> What is the
On Thu, 9 Feb 2023 12:45:27 GMT, Maurizio Cimadamore
wrote:
>> During the fix I found the definition that `ThrowableSig` (as a super-set of
>> `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for
>> processing.
>> For example when `MethodSignature` is serialized
>>
On Tue, 7 Feb 2023 11:48:52 GMT, Maurizio Cimadamore
wrote:
>> Yes, performance is the main reason.
>> I'll note to do a fresh differential performance benchmarks with a HashMap.
>
> thanks
I tried HashMap with String keys and it cause performance regressions, however
with Utf8Entry
On Wed, 8 Feb 2023 13:44:13 GMT, Adam Sotona wrote:
>> OK, I see your point now, I'll fix it.
>> Thanks
>
> During the fix I found the definition that `ThrowableSig` (as a super-set of
> `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for
> processing.
> For example
On Wed, 8 Feb 2023 12:19:35 GMT, Adam Sotona wrote:
>>> `Signature.ThrowableSig` is a `Signature` and it is a common super of
>>> `ClassTypeSig` and `TypeVarSig`.
>>
>> I really don't follow here. ThrowableSig is a piece of a method signature,
>> which starts with "^" and is followed by
On Wed, 8 Feb 2023 11:07:08 GMT, Maurizio Cimadamore
wrote:
>> `TypeParam` is not a signature, because it simply is not a signature.
>> Per spec:
>>
>> TypeParameter:
>> Identifier ClassBound {InterfaceBound}
>
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of
>>
On Wed, 8 Feb 2023 07:24:05 GMT, Adam Sotona wrote:
>> **Specification:**
>>
>> MethodSignature:
>> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
>>
>> Result:
>> JavaTypeSignature
>> VoidDescriptor
>>
>> ThrowsSignature:
>> ^ ClassTypeSignature
>> ^
On Fri, 3 Feb 2023 18:33:46 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Tue, 7 Feb 2023 11:53:46 GMT, Maurizio Cimadamore
wrote:
>> `BootstrapMethodEntry` is not a constant pool entry, but
>> `BootstrapMethodsAttribute` entry.
>> It might be rather moved under `attribute` package and renamed to
>> `BootstrapMethodInfo` to follow the same pattern as other
On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona wrote:
>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses,
>>> `MethodSignature` and `ClassSignature` are designed according to [JVMS
>>> 4.7.9.1
>>>
On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona wrote:
>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses,
>>> `MethodSignature` and `ClassSignature` are designed according to [JVMS
>>> 4.7.9.1
>>>
On Tue, 7 Feb 2023 15:47:25 GMT, Maurizio Cimadamore
wrote:
>> Class `Signature` (aka `JavaTypeSignature`), all subclasses,
>> `MethodSignature` and `ClassSignature` are designed according to [JVMS
>> 4.7.9.1
>>
On Tue, 7 Feb 2023 14:51:06 GMT, Adam Sotona wrote:
> Class `Signature` (aka `JavaTypeSignature`), all subclasses,
> `MethodSignature` and `ClassSignature` are designed according to [JVMS
> 4.7.9.1
> Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
On Tue, 7 Feb 2023 12:10:43 GMT, Maurizio Cimadamore
wrote:
>> The confusion come from simplified name. Signature probably should be called
>> JavaTypeSignature according to the spec. ClassSignature and MethodSignature
>> could not extend it, as it would not respect the reality. Each of them
On Tue, 7 Feb 2023 14:14:50 GMT, Maurizio Cimadamore
wrote:
>> The relation is that each `Attribute` is applicable in N
>> `AttributedElements` and not vice versa.
>> For example `ClassModel::attributedElementKind` returns `CLASS` and for
>> example
>>
On Tue, 7 Feb 2023 12:59:32 GMT, Adam Sotona wrote:
>> Still, there seems to be a modelling issue here. The property of "where
>> could this attribute go" is a property of the attribute. Of course, for
>> usability reason, an AttributedElement might expose a predicate saying "I
>> only accept
On Tue, 7 Feb 2023 12:34:50 GMT, Maurizio Cimadamore
wrote:
>> `AttributedElement::attributedElementKind` identifies the one kind of the
>> attributes holder.
>> The "places where an attribute can appear" is available through
>> `AttributeMapper::whereApplicable` and matched against
>>
On Tue, 7 Feb 2023 12:14:40 GMT, Maurizio Cimadamore
wrote:
>> On the contrary, it has been deduplicated. Opcode is referencing numeric
>> constants stored in Classfile.
>
> sure, but my question is - once you have a nice enum that is 1-1 with the
> opcodes - why would a client want to use
On Tue, 7 Feb 2023 12:23:05 GMT, Adam Sotona wrote:
>> Uhm - I can't see these usages... something seems to be off with my IDE
>> configuration. I did a grep and I now saw the uses. That said, having the
>> Kind/Location inside AttributedElement still looks weird to me. The "places
>> where
On Tue, 7 Feb 2023 11:48:28 GMT, Maurizio Cimadamore
wrote:
>> There are at least 72 usages of AttributedElement.Kind across the Classfile
>> API.
>> Do you suggest to rename it to something else (for example Location)?
>
> Uhm - I can't see these usages... something seems to be off with my
On Mon, 6 Feb 2023 14:35:43 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:
>>
>>> 37: */
>>> 38: public enum Opcode {
>>> 39: NOP(Classfile.NOP, 1, Kind.NOP),
>>
>> This also duplicates the constants in classfile...
>
> On the contrary,
On Mon, 6 Feb 2023 14:32:12 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line
>> 34:
>>
>>> 32: * Models the generic signature of a class file, as defined by JVMS
>>> 4.7.9.
>>> 33: */
>>> 34: public sealed interface ClassSignature
>>
>>
On Mon, 6 Feb 2023 14:09:08 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java
>> line 41:
>>
>>> 39: * part of the constant pool.
>>> 40: */
>>> 41: public sealed interface BootstrapMethodEntry
>>
>> Usages of this seem all to fall into
On Mon, 6 Feb 2023 13:55:59 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java
>> line 94:
>>
>>> 92: * are permitted.
>>> 93: */
>>> 94: enum Kind {
>>
>> Not sure how to interpret this. This seems to refer to an attribute -
On Mon, 6 Feb 2023 12:41:44 GMT, Adam Sotona wrote:
>> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line
>> 75:
>>
>>> 73: * The kind of target on which the annotation appears.
>>> 74: */
>>> 75: public enum TargetType {
>>
>> My IDE says this enum is
On Fri, 3 Feb 2023 18:25:17 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 18:37:43 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 18:11:41 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:59:53 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:58:04 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:56:45 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:52:49 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 18:07:27 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
>>
>>> 344: public static final int MAGIC_NUMBER = 0xCAFEBABE;
>>> 345:
>>> 346: public static final int NOP = 0;
>>
>> Not sure how
On Fri, 3 Feb 2023 17:43:22 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:37:55 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:32:37 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:20:19 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:23:51 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 17:22:32 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
On Fri, 3 Feb 2023 14:31:24 GMT, Adam Sotona wrote:
>> This is root pull request with Classfile API implementation, tests and
>> benchmarks initial drop into JDK.
>>
>> Following pull requests consolidating JDK class files parsing, generating,
>> and transforming
>>
On Fri, 3 Feb 2023 17:46:32 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Classfile API moved under jdk.internal.classfile package
>
>
> This is root pull request with Classfile API implementation, tests and
> benchmarks initial drop into JDK.
>
> Following pull requests consolidating JDK class files parsing, generating,
> and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957))
> will chain to this one.
44 matches
Mail list logo
