Provide access to LazyConstant via internal fallback module

[mbien]

• introduces "JDK Fallbacks" friend module for internal use only
• module delegates to JDK implementations if available and uses fallbacks if not
• the accessors are meant to be temporary friend API with expiration date, only to bridge the gap between lower and upper runtime requirements

namespace and module location can probably be improved. It would be also good to find some usage candidates and add a reference commit before merge.

draft for feedback

[neilcsmith-net]

I'm a fan of the various forms of Lazy and glad to see an efficient form potentially making it in to the JDK. I'm unsure this is the right way to support its use in NetBeans. What else do you envisage this module possibly being used for too?

My inclination would be towards putting this in openide.util. We're at least 4 years from being able to adopt solely use of the JDK API, and we could deprecate our own version at that point. Migrating the various existing things (like use of class-holder idiom) to a central API could help with updating to direct use of the JDK variant at a later date.

[mbien]

What else do you envisage this module possibly being used for too?

there is a good chance that this module won't grow because this trick does only work if the surface of the covered API is tiny and the fallback is simple enough. We could rename it and make it less generic - I wasn't sure either. Maybe something else will show up?

My inclination would be towards putting this in openide.util. We're at least 4 years from being able to adopt solely use of the JDK API

The general idea is to remove the indirection (in this case the module) once no longer needed and replace usage with the JDK api (would be very simple search/replace). I am not sure if it is possible to export a single package only for friends while having also normal public API (openide.util) - thats why I put it into a separate module instead of an existing one.

potentially making it in to the JDK

JDK itself uses the feature already for quite a while in form of the @Stable annotation. The fact that its API isn't finalized is another reason of keeping it internal since it would give us more options to course correct.

I don't think that everything we use should also be public. org.openide.util.WeakSet should have been internal use only too IMO. It is always difficult to remove public API.

[neilcsmith-net]

I am not sure if it is possible to export a single package only for friends while having also normal public API (openide.util)

No, but the point was I'm in favour of making this public API. It can be deprecated if/when it can be replaced, and will still help with migrating things away from things like class-holder idiom now.