End position storage in javac

[Jonathan Gibbons]

On Wed, Nov 26, 2025, at 12:46 PM, Archie Cobbs wrote:
> Rhetorical question: if space really is so precious, then why not get rid of all the "Tag" fields and just use instanceof instead?
> 
> I'm assuming the original rationale for "Tag" fields was because instanceof was too slow? If so, is that still true? 

IIRC, while performance was an issue at one point in the past, it was not the reason to avoid instanceof.

The performance issue was that field/member access was seen to be faster than virtual method calls, and thus justified the field.

instanceof was deemed to be less reliable than tag usage. Not unreliable in the determini*s*tic sense, but because there were some design choices in javac and other similar tools where "poor use of interface inheritance" could mean that instanceof would return the wrong answer compared to examining the tag in some way. I remember fixing those issues in javac.

Also remember that in the original design, up through JDK 5, javac was "just" a closed batch mode compiler. java files in, class files out; that was it. That definitely affected design choices back then. It was only as we started opening up javac as a software component in JDK 6 onwards that some of those design choices (like end positions) became less than ideal, and were worked around to some degree, 

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20251201/0974b303/attachment.htm>