On 20/08/2021 17:03, Laird Nelson wrote:
On Fri, Aug 20, 2021 at 3:13 AM Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>> wrote:
I think you are asking for an overload that specifies a class
literal as
a type token to avoid an explicit cast at the use-sites.
Yes, that's right.
Is this to
improve usages within Helidon or are there enterprise libs that
expose
JNDI Context objects that would be used by a wider set of users?
Nothing so concrete. I've worked with Java-now-Jakarta EE for many
years and periodically like many like-minded users get frustrated with
the amount of explicit casting required when looking something up from
a Context.
Also anecdotally: when you bring up JNDI in conversation, you get
responses along the lines of "but it's so old and clunky", and when
you push a little bit to find out what people are really objecting to,
the "old" and "clunky" bits turn out to be related to various methods
returning Object. (Well, that and Hashtable, but that's obviously not
repairable.) Supposedly "modern" lookup-oriented APIs in other
libraries (offhand thinking hazily of CDI, various configuration
libraries, etc.) often have a variant of the kind of enhancement I'm
proposing and are then suddenly perceived as more sleek and fleet of
foot than this one. This kind of overload enhancement just seemed like
a low-effort way to drastically improve the perceived relevance of
what is a pretty powerful API under the hood.
JNDI dates from 1997 and came into the JDK in Java SE 1.3. There have
been very few API changes since then. There hasn't been any significant
interest (to my knowledge anyway) in re-investing and modernizing the
API. No objection to adding an overload with a type token but it's only
a very small improvement. I suspect it would take a much bigger effort
to shake off the old/clunky perception. A starting point for most people
using this API will be creating an InitialContext and adding a new
constructor that takes a Map with the environment would at least avoid
some of the usages of Hashtable.
-Alan.
