aalmiray
commented
6 years ago We've discussed this issue a few weeks ago at an EG meeting. Updating 382's API to be friendlier to 377's needs is not the way to go, that is, updating the Converter API to be able to manage arbitrary source type conversions, not just java.lang.String.
Instead 377 will keep it's configuration API (at the time it behaves as a super set of 382's) but the spec will mention that 382 may be used, in which case sensible defaults should be provided by implementors in order to fulfill the contract of the full 377 Configuration API.
Thus, this issue can be closed as there are no further changes required in 382.
JSR-377 (https://github.com/jsr377/jsr377-api), the Desktop/Embedded Application Framework JSR, has as goal to standardize how applications can be built that target desktop, mobile, and embedded environments. As part of these standardization effort JSR-377 has identified the configuration space as one of its key areas. Looking at the current state of JSR-382 there are some concerns on the viability of consuming 382 as is from 377's POV. Allow me to explain, 382 exposes a
javax.config.Configtype that's the source of key/values pertaining to configuration properties. Instances ofConfigcan be queried programmatically, given a key you may get a value, simple pull model (1). There's also a push model via annotations (ConfigProperty) that complement dependency injection (2). Finally, there are times where the value obtained is not of the appropriate type, thus type conversion (3) must occur.From 377's POV, (1) provides the minimum definition for querying key/values. Additional behavior can be built on top of
javax.config.Configsuch asjavax.application.configuration.Configuration(see https://github.com/jsr377/jsr377-api/blob/master/jsr377-api/src/main/java/javax/application/configuration/Configuration.java). Thus point (1) is covered.Point (2) defines
javax.config.inject.ConfigPropertyas a Qualifier for injection. This annotation defines enough behavior to be usable by 377 given certain defaults. 377 defines its own annotation,javax.application.configuration.Configured, (see https://github.com/jsr377/jsr377-api/blob/master/jsr377-api/src/main/java/javax/application/configuration/Configured.java) with additional properties that come in handy given the uses cases we've seen so far. Now, 377 could use both annotations assuming that if 382's is used then you get default, well-defined behavior for those "missing" properties that 377's annotation provides. Thus point (2) is also covered.So far, not changes to 382 are required for 377 to work with it. However it's point (3) that brings concerns to us as for natural reasons to 382 the Converter API expects the source type to be a String, whereas in 377 we reuse the Converter API to be able to transform resource values (such as Images, Icons, Colors, Gradients, etc). The sources of these resources may be textual sources (properties, XML, JSON, YAML) where the source type is a String, but they could also be programmatic sources such as Java resource bundles, Groovy scripts, Kotlin scripts, where the source type may already by of the expected type, or it could be some other type (not a String) that can be transformed into a target. Take for example an Insets instance, the source could be Insets, a number, a list of 4 numbers, a Map with (top,bottom,left,right) coordinates, some other thing.
The risk for 377 for adopting 382 as it currently stands, is that 377 would have to define its own Converter API to make resources work. I'd like to start a discussion on the Converter API to figure out what can be done to have this two JSRs cooperating with one another.