Discuss the API basic design as a whole

[atsticks]

I see numerous flaws in the API as given. Before proceeding a structured discussion should be done in the EG about which parts make sense. For a JSR the overall scope as of now is incredibly big and I as of now don't see any advantages to proceed. I am sure I am not the only want willing to join a structured discussion. If I missed anything let me know.

Some examples:

• Application: do we really need methods to model the app lifecycle? Cant we do more simple by defining callbacks for related lifecycle steps?
• Why the ApplicationPhase must be managed by the Application (and not the runtime it runs on) ?
• ShutdownHandler can be simplified into one single functional method.
• What is the difference between Configuration and Context? The APIs are mostly duplicates of each other, so thinking on it's commons is useful here.
• What exactly happens, when a shutdown is stopped? Is this feature usable at all? In what scenarios?
  Cant it be resolved differently?
• ExitState: when I have an exit state, there is not reason not to exit, so the whole construct can be removed and replaced with the int number insteads of over-enbgineer features.
• Looking at the features of the discussed configuration JSR the packages configuration, context and converters can be completely ommitted with the configuration API. Hierarchical composition of contexts can be achieved with the Configuration API's builder patterns, converters and key/value APIs come OOTB box.
• EventHandler why reinventing the wheel by adding a priority field instead of using @priority annotations?
• EventFilter why not returning boolean instead of Boolean. Null is not a valid result for a filter IMO.
• MessageSource why throwing a MessageNotFoundException ? What additional information I get instead of simply returning null ? Throwing an exception also makes working with ResourceBundle sometimes a pain, so the design flaws should not be repeated here...

[aalmiray]

Hi @atsticks, the API you see today is a snapshot based on the discussions we've had in the past 3 years. Most of these discussions have been recorded at the mailing list (http://jsr377-api.40747.n7.nabble.com/). We also have another communication channel at https://gitter.im/jsr377/jsr377-api although it has not been used so far.

Threaded discussions work IMHO better on the mailing list rather than on GitHub issues, which is why I suggest to to move the discussion there. I'll post two follow up messages at the ML, the first addressing the points you raised; the second explaining the overall structure and design of the API, as a refresher to everyone and starting point of further refinents/additions/removals, etc.

[keilw]

@aalmiray @atsticks / all,
Maybe we could do a Hangout or at least Gitter Chat session about some of these things.

I met other members of the EG between Sofia (Java2Days) and Düsseldorf (JCON) some of whom also expressed a few concerns about architectural or similar aspects of the JSR and its appeal to possible users from the industry. We should try to sort most of them out. Martijn also voiced his concern, see https://jcp.org/aboutJava/communityprocess/ec-public/materials/2017-09-28/JCP-EC-Meeting-Minutes-September2017.html that there seems to be some reluctance by the industry so far.

[aalmiray]

First message posted at http://jsr377-api.40747.n7.nabble.com/Points-raised-by-PR-16-td283.html

[aalmiray]

@keilw will setup a doodle for deciding date/time for a Hangout next week

[aalmiray]

Doodle is up at https://doodle.com/poll/vhe3i387cq7mnpeu