Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 18:55 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Shared libraries by paulj
Parent article: APT Rust requirement raises questions

> Java elides the parameterised type information from the binary ABI I thought.

It doesn't. And the type information is available throught reflection. It simply ignores it during the bytecode interpretation (or JIT-compilation).

to post comments

Shared libraries

Posted Nov 26, 2025 10:44 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

Interesting... Hadn't considered reflection. But that's not part of the binary ABI as such, but the bolt-on reflection API. It's the equivalent of additional debug symbols - useful for introspection, but not used for link-time validation. What you say confirms my understanding, the runtime byte-code linking process does not take parameterised types into account.

Shared libraries

Posted Nov 26, 2025 13:33 UTC (Wed) by khim (subscriber, #9252) [Link]

It's implementation detail. Developers don't care about whether something is “proper” part of the ABI or not “proper” part of the ABI. They can and use foreign types with generics and this just works.

Rust may do the same if it would impose that foreign types can only be used with the dynamic dispatch.

Shared libraries

Posted Nov 26, 2025 18:19 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Interesting... Hadn't considered reflection. But that's not part of the binary ABI as such, but the bolt-on reflection API. It's the equivalent of additional debug symbols - useful for introspection, but not used for link-time validation.

Technically, there is no "linking" in Java. All the code is dynamically loaded at runtime (through ClassLoaders). You can do additional validation during loading and/or rewrite ("instrument") the bytecode entirely.

Type information available through reflection was used to implement reified generics by some languages targeting the JVM. Kotlin is one of them, for example. So in practice, the type erasure on the bytecode level is mostly an implementation detail.

Shared libraries

Posted Nov 27, 2025 16:54 UTC (Thu) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Oh no. I've gotten bit by type erasure (of generics) more times then I can remember.

You can definitely have code that does:

for( var a: someCollection<SomeTypeA> )

And it ends up with someCollection<SomeTypeB> at runtime, and you're stuck debugging the damnedest runtime error, once you do something with it in the for loop..

I had this happen on a nested, templated collection.

Granted, the thing that usually triggers this is the odd corner case of deserializing data back into Java.

Unfortunately, this odd corner is something that happens all over the place when you're working with a system that contains HTTP services, which, if you work with Java, is what you're usually paid to do, nowadays.

And, since you always need some sort of deserializer for JSON (or, if you're particularly unlucky, XML) in your HTTP service, oh, what the heck, we'll use it for config files as well, for any data we read in, for..

And Boom.

When working with Java on a daily basis, type erasure is anything but an implementation detail.

It's is a very real pain point (granted it was done by smart people with sound reasoning and good intentions [1], but you know what they say about good intentions...)

There are other cases I've ran into at odd times, but I have trouble recalling the specifics, because the serde issue happens often enough that it looms large in the memory.

[1] https://openjdk.org/projects/valhalla/design-notes/in-def...

Shared libraries

Posted Nov 28, 2025 5:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Oh yes. Back when I was writing tons of Java, I had my own deserializer for my homegrown RPC protocol that made sure that types of collections match.

I also distinctly remember collection wrappers that enforced the correct types using reflection. Maybe in apache-commons?