-1

This page https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7 says

For all attributes, the attribute_name_index must be a valid unsigned 16-bit index into the constant pool of the class.

However, I'm wondering if that this field represents its own kind directly is better than the current specs.

(e.g) If the attribute_name_index == 0x01, then the attribute kind is to be fixed as StackMapTable without referencing Constant Pools.

What are the merits for current specs?

knium_
  • 93
  • 6
  • The spec is the spec. Asking why it is the way it is, or why it isn't the way you think it should be, is basically futile. – user207421 Jan 07 '20 at 03:54
  • I can't help noticing that the Great Pyramid was made of stone and took 50 years to build. Wouldn't it have been better if they used steel? :-) – Stephen C Jan 07 '20 at 04:02

2 Answers2

0

Java attributes can have almost any string as a name. It's an extensible system. The JVM specification defines several dozen standard attributes, but users can define their own custom attributes as well (this ability is notably used by Scala to implement Scala specific runtime functionality).

Antimony
  • 37,781
  • 10
  • 100
  • 107
0

Why is the attribute_name_index in JVM Classfile an index?

Because that is what they specified. For better or worse.

Note that the original class file format was defined in the early 1990s, well before Java was called Java; see Why do Java class file versions start from 45?.

What are the merits for current specs?

  • It is extensible.

  • It is compact; e.g. the constant pool entry for one name can be referenced in multiple places in a class file.

  • It is consistent.

  • It is specified, and the spec is widely adopted / implemented.

But the this is all moot ... unless you intend to implement a new classfile format of your own.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216