the "java:comp/env" part comes into play for certain J2EE components that have their own naming environment. It allows the code to refer to a JNDI object, but have the actual object looked up to be defined declaratively (via the web or EJB deployment descriptor files).
For example, an out-of-the-box J2EE component would need to use the "java:comp/env" stuff since source code isn't distributed along with the purchase. There are other reasons of course. The EJB spec recommends that all JNDI lookups have ejb-refs, or local-ejb-refs as the case may be.
If the client isn't an EJB client, using java:comp/env doesn't make any sense, as far as I know, unless you have some sort of custom context factory doing some cool stuff for you.