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.

[mbien]

.. and will still help with migrating things away from things like class-holder idiom now.

This is the reason why I try to add this in the first place. Maybe I am missing something, but why would this be more difficult to achieve as internal utility? Module adds itself on the friends list and uses it.

I really don't like the idea of adding public API while knowing that they will be deprecated in a few years - technically they would be deprecated the moment LazyConstant is finalized since client code should always use the JDK API instead if possible - given that platform apps are not bound to the same min requirements as NB is.

Thought about what else the module could offer at some point:

Both List.ofLazy and Map.ofLazy should be doable with fallbacks I believe. I think those factory methods are interesting from a technical perspective but far more niche than LazyConstant itself. (but if we find a usecase -> I could probably add it)

[neilcsmith-net]

This is the reason why I try to add this in the first place. Maybe I am missing something, but why would this be more difficult to achieve as internal utility? Module adds itself on the friends list and uses it.

Well, you've already added one extra unnecessary step! 😉

Basically, I disagree with the use of friend modules to hide APIs all over the code base. The friend feature should be used to provide a tunnel between interrelated modules that have a need to enable differently. Other than that it's almost always been a mistake.

Yes, we might deprecate this in 4 years. It won't be less than 4. And it might be that we have a reason to keep it as a wrapper even then.

I'm not going to block this, but I think the fallback module aspect is just unnecessary extra complexity for a simple, useful feature.

[mbien]

ok. not convinced. Will keep it internal/non-permanent like originally intended to not repeat mistakes like WeakSet and others. Based on usage we can reevaluate it at a later point and move the code to openide.util - although I can't come up with a reason why we would do that still.