As a rule, I don't recommend putting the ORM code directly in the web interface (
Struts service) code. It's usually much cleaner to keep the persistency code isolated from the UI and business code. Besides, that code example can leak resources. One of the reasons why I prefer Spring for my persistency.
However, the real problem here is that you're not doing the query the way you think you are.
Standard approach would be like this:
Which would result in a list of all the user details.
When you only want selected columns, your code would work, subject to the observations I just made, but what the method is actually returning is a collection of Array objects, where each element of the collection is a 2-element Array of type Object, and the elements are a[0] = firstname, and a[1] = lastname. It's an Array of Object, because you can retrieve non-String columns this way as well, and Object is the lowest-common-denominator class.
There's a name for this kind of query in JPA, although I'd have to go back and look it up. It's not actually as useful or as as it looks, however, unless resources are tight. And the fact that the returned data is not strongly typed can lead to problems detectable only at runtime.