On 2/7/20 12:11 AM, Seán Coffey wrote:
On 6 February 2020 21:13:52 GMT, Peter Levart <peter.lev...@gmail.com> wrote:
On 2/6/20 6:54 PM, Seán Coffey wrote:
the current proposal is still:
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
But wasn't this one already better:
https://cr.openjdk.java.net/~coffeys/webrev.8223260.v3/webrev/
D'oh! You're right Peter. v3 is my preference (and most up to date) at the
moment. I'll look at Alan's comment in the morning. I could create a custom
exception if the current UndeclaredThrowableException is not a good use.
Well, theoretically, some implementation of InitialContextFactory could,
in its constructor, use a not well-behaved dynamic Proxy which could
throw UndeclaredThrowableException with NoInitialContextException as a
cause and such exception would get unwrapped later in
NamingManager.getInitialContext() where it would mistakenly be
identified as an exception constructed in NamingManager.getFactory
method. Using your own sub-type of RuntimeException for tunneling the
NoInitialContextException through the functional interface (lambda)
would eliminate even this remote possibility. Perhaps a pubic but
confined com.sun.naming.internal.RuntimeNamingException (modeled after
RuntimeIOException) would be a good name and could be re-used for
possible similar needs in the future. A private static nested class in
NamingManager could do it too.
Regards, Peter
Regards,
Sean.
Or do you prefer the v2 so that spec change and behavior change would
be
synchronized?
Regards, Peter
I'd like to make the specification change in a follow on bug ID (if
that works for people)
Regards,
Sean.
On 06/02/20 17:49, Alan Bateman wrote:
On 06/02/2020 15:32, Seán Coffey wrote:
InitialContextFactory itself is an extremely simple interface with
one method. I've browsed some code bases and could only find a
small
number of such Factories implementations with simple logic to
return
a Context. Applications will most likely delegate to the same
Factory over and over also (albeit, it's all controlled by
HashTable
parameters). The new caching logic should help memory pressure here
and not hinder it. I'm not seeing a major concern with current
solution as a result.
Okay, although I could imagine a non-JDK InitialContextFactory
implementation keeping a graph of objects alive. I saw your mail
about separating the clarification in the APIs docs so does it mean
the proposal on the table is the last webrev or is there a new
version?
-Alan
