Config Object - Class vs Interface

[radcortez]

The current discussion aims to detail and document the decision-making of the Config Object design.

State of the Art

Some of the most popular frameworks already provide such capability in one way or another:

• Spring Type Safe Configuration
• Dropwizard POJO
• Micronaut Configuration Bean
• DeltaSpike Interface Based Configuration
• LightBend Config Bean

The observed trends were the following:

• Most seem to favor a class based approach.
• Most seem to favor a prefix or namespace to define the starting configuration path
• Most seem to favor a convention to construct the remaining configuration path based on the complex type member name
  (with a way to override it)
• Automatically convert the configuration entry value to fit the complex type member
• Support container types (Collections, Maps)
• Support nested complex types

Class vs Interface

How should a complex object type be represented as a class or an interface? Or maybe both?

Using a class has some downsides:

• Requires an all args constructor or setters to populate fields (or Java Beans property descriptors)
• Possible IllegalAccess errors if private fields are supported (without setters)
• Heavy use of reflection to build the instance
• Additional rules to handle initialized fields
• Additional rules to handle primitive types (they already have a default value)

Using an interface removes most of these downsides, adding some of their own:

• Needs to be backed by a Proxy or some other means to provide an implementation
• Harder to use standalone

Some Jakarta EE specifications (JPA, JSONB) use POJOs to bind data. While similar, it is not intended for the
end-user to modify the configuration representation directly. The Config instance will handle any change
(even with mutability support), so a POJO is not required to support the configuration needs fully.

In this case, an Interface to represent configuration complex types seems to be a better option.

Records

The specification targets Java 11 language level. For this reason, Java 14 Records do not belong to the specification.
Implementations are free to support Java Records at their consideration.

[ljnelson]

A quick question: since this specification will be at the earliest going into Jakarta EE 11, which is quite a ways off, must we target Java 11? I don't want to have the whole discussion here, just looking for a reference somewhere that says "yes, it's Java 11 for the next revision" or something.

[radcortez]

I think that discussions for Jakarta.next are taking place now. I have no idea which java version will be used.

The Java 11 version reference was because initially, we were targeting Jakarta 10 / Java 11. The goal of this discussion here was to document the Class vs Interface discussion (so we can point here when someone brings that up again :)). Initially, we had this content in a spec appendix section, but we decided it didn't make sense to have it here and just keep it here as a discussion.

[ljnelson]

Got it; thanks

[ljnelson]

Related question: may a "config object" be of any type? Or must it extend or implement a special supertype?

[radcortez]

Yes, any. No need to implement/extend something.

[ljnelson]

Great; what I was hoping you would say. Thanks.