Should loading a configuration POJO be specified to have singleton semantics?

[ljnelson]

(On the call today, we talked about MVP scope. The second item is related to loading and is what I'm asking about here.)

Given the following loading pseudocode sketch:

// Obviously sketchy provisional pseudocode
MyConfigObject c = SomeConfigLoaderThing.load(...some kind of addressing...);

…what must (or must not) be true of the return value semantics when load(...some kind of addressing...) is called twice or more with the same addressing information?

(Ignore any exceptional behavior for the moment.)

Please choose from the following mutually exclusive options:

1. The same object reference is returned in both cases, and it cannot be null.
2. The same object reference is returned in both cases, and might be null to indicate the absence of a configuration object.
3. The same object reference is returned in both cases, and might be null to indicate a valid configuration object consisting of simply the value null (i.e. not absence; just another value).
4. It is possible that two different cs are returned, but neither can be null.
5. It is possible that two different cs are returned, and either can be null to indicate absence.
6. It is possible that two different cs are returned, and either can be null to indicate a valid configuration object consisting of simply the value null (i.e. not absence; just another value).
7. The return value is unspecified and we intend to keep it unspecified in the future.
8. The return value is unspecified for now but we might want to allow (4), (5) or (6) in the future so consider this as the API is designed.

This is a "scratch" discussion, i.e. not an official vote or poll or anything. Normally I'd use a mailing list for these kinds of questions but the mailing list seems to have fallen out of favor.

This discussion is loosely related to #109 but please keep discussions on target.

[ljnelson]

I choose (8) because it allows flexibility down the road. My second choice would be to go "hard" in the other direction and choose (1). See #109 for more implications of (1). (4).

[dmlloyd]

I strongly choose (1), with some comments.

Regarding options (2) and (5), even it is the case that there is no configuration file, semantically returning null is not helpful because you'd still have a configuration which comprises default and/or empty values. I think it's best to avoid null in this specific API for this reason and for other ergonomic reasons which also apply to (3) and (6) (I expect the ergonomics issue to come up in future discussions). If on the other hand the given addressing information does not correspond to a configuration that the container has tried to parse for the application (which is not quite the same thing as "missing"), or is for some other reason not valid, the appropriate response would be to throw an exception to the user.

My second comment is around the use of the word "same" or perhaps the definition of the term "addressing information". An application container may host multiple applications within the same JVM, each with its own configuration. The application from which the method call is made should be a factor in determining which configuration object is returned even for the same input addressing information. Therefore I would consider the calling application to be an expressly implicit part of the addressing information. (The term "application" is more or less normative in the context of Jakarta EE by the way.)

Lastly, regarding flexibility (without saying the "m********y" word) I think that such flexibility can definitely be implementation-defined without too much difficulty. In the future if we ever pursue that path, we can introduce a separate API and ensure that it is clear that this method always returns the initial or starting configuration.

[ljnelson]

Regarding the addressing information: yes, component and application coordinates will necessarily be a big thing. Some will be explicitly supplied by the user (type jumps immediately to mind) and others, as you say, will be implicit.

I personally agree that null as a semantically rich value where "big" (e.g. structured, with fields, object graphs, etc.) POJOs are concerned makes no sense.

Therefore in my view also (2), (3), (5) and (6) are out.

(It is at least conceivable that if (big if! not proposing this!) we were to allow loading of "small" POJOs (like String) in the future null might be a semantically rich value, and not just an absence marker, in which case (3) and (6) might creep back into the picture.)

[m0mus]

I agree with @dmlloyd that we should avoid using null. I don't see a use case when different objects are returned, so I am leaning to choose (1), @ljnelson can you reveal this use case?

[ljnelson]

Consider certificate reloading, a real customer-driven use case implemented in Helidon. I'm sure there are others.

Consider a configuration object like this:

public interface MyConfigObject {
  public Certificate getCertificateForSomeReason();
}

And consider it being loaded like this:

MyConfigObject c1 = SomeConfigLoaderThing.load(...some kind of addressing...);

#109 tells us that the following two printlns (1 and 2) MUST print the same thing:

System.out.println(System.identityHashCode(c1.getCertificateForSomeReason())); // 1
System.out.println(System.identityHashCode(c1.getCertificateForSomeReason())); // 2

Let's pretend the certificate on disk changes. (Obviously if we did println again we would still get the old value, per #109.)

But now let's call load again:

MyConfigObject c2 = SomeConfigLoaderThing.load(...some kind of addressing...);

Option (1) tells us that c2 must be the same object reference as c1 (i.e. c1 == c2). So when we System.out.println() again:

System.out.println(System.identityHashCode(c2.getCertificateForSomeReason())); // 3
System.out.println(System.identityHashCode(c2.getCertificateForSomeReason())); // 4

…option (1) also tells us that the output of println 1, println 2, println 3 and println 4 MUST be the same.

Maybe instead we want println 1 and println 2 to be the same (per #109), and println 3 and println 4 to be the same (also per #109), and no further restriction on whether the first two printlns are the same as the second two printlns. This is option (4).

[m0mus]

It's a mutability use case. We agreed that we won't support mutability.

[ljnelson]

So you feel that because of #109 we should design this method so that it can never return something different in the future, even though #109 is focused on immediate needs, not long-term needs?

Or: in your view, therefore, option (1) is the only possible option, I guess?

Bear in mind if we specify that the return value must be a non-null singleton, then I'm not sure that can be relaxed later without violating backwards compatibility constraints.
I guess that seems waaaaaay overly harsh to me, which is why I'd prefer (8).

[m0mus]

Yes, you are right, (8) is more flexible option and a better choice for now.

[radcortez]

Option 1 or 8.