How to prevent runtime type erasure using GenericEntity in Jakarta REST in Jakarta EE 10

Jakarta EE

Java generics is a great feature that allows you to have compile time checks for generics. However, due to historical reasons of backward compatibility, type information for generics is erased at runtime. A lot of the time this shouldn’t be of much concern. But there are a few cases where type information is needed at runtime for some kind of decision. 

One such situation is in Jakarta REST when the jakarta.ws.rs.core.Response object is used to return a generic collection of a specific type. For example the code below shows the creation and return of a Response object that has a list of HelloEntity as the return payload to the client. 

List<HelloEntity> helloEntities = greetingService.loadSampleEntities();
return Response.ok(helloEntities).build();

The problem with the above is that type erasure removes the type from the list such that at runtime the passed list becomes List<?> instead of the specific Java type HelloEntity passed at compile time. For a lot of cases this may not be of concern. But if you have a complex or very custom case where the generic information is needed at runtime to fetch the exact  jakarta.ws.rs.ext.MessageBodyWriter, then this could be a very big problem. 

To get around this problem, the Jakarta API has the jakarta.ws.rs.core.GenericEntity<T> wrapper for wrapping generic types, as shown in the code snippet below.



List<HelloEntity> helloEntities = greetingService.loadSampleEntities();
GenericEntity<List<HelloEntity>> entity = new GenericEntity<>(helloEntities) {};
return Response.ok(entity).build();

The original HelloEntity list is wrapped in a GenericEntity created as an anonymous class. This new object is then passed as the entity of the returned Response object. With this construct, the typed information of the original helloEntities list is not lost and can be retrieved at runtime. So next time you need to maintain generic information at runtime in Jakarta REST, give GenericEntity a look.

Found this useful? Try more of ourJakarta EEcontent:

Comments (0)

Post a comment

Your email address will not be published. Required fields are marked *

Payara needs the contact information you provide to us to contact you about our products and services. You may unsubscribe from these communications at any time. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, please review our Legal & Privacy Policy.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts

SpringBoot Actuator Health for Microprofile Developers 7 minutes
Cloud & Microservices

Spring Boot Actuator Health for MicroProfile Developers

If you worked with MicroProfile Health, you already understand the value of exposing application health information through standardized endpoints. […]

Webinar banner for “High-Frequency Trading on Jakarta EE: GC Stress Testing with Azul C4 and Payara Micro,” March 25, 2026, 2 PM GMT. Features Azul and Payara Micro logos and speaker photos of Luqman Saeed, Jakarta EE Specialist, and Simon Ritter, Deputy CTO and Java Champion. 1 minute
Cloud & Microservices

High-Frequency Trading on Jakarta EE: Join Our Upcoming Live Webinar

Modern high-frequency trading (HFT) platforms operate under extreme performance constraints, processing tens of thousands of messages per second while […]

Illustration promoting the Payara Platform Community Survey, featuring bold text on a blue background alongside a clipboard with a checklist, star ratings, and check marks, with coral and fish graphics in an underwater theme. 1 minute
Community

Help Shape the Future of Payara Platform Community – Take Our 2026 Survey

Earlier this week, we’ve launched the 2026 Payara Platform Community Survey and we’d love to hear from you. If […]