Process for adding default method to javax.naming.Context?
Alan.Bateman at oracle.com
Sat Aug 21 16:48:51 UTC 2021
On 20/08/2021 17:03, Laird Nelson wrote:
> On Fri, Aug 20, 2021 at 3:13 AM Alan Bateman <Alan.Bateman at oracle.com
> <mailto:Alan.Bateman at 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
> 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.
More information about the core-libs-dev