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...
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?ApplicationPhasemust be managed by the Application (and not the runtime it runs on) ?ShutdownHandlercan be simplified into one single functional method.ConfigurationandContext? The APIs are mostly duplicates of each other, so thinking on it's commons is useful here.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 theintnumber insteads of over-enbgineer features.EventHandlerwhy reinventing the wheel by adding a priority field instead of using @priority annotations?EventFilterwhy not returningbooleaninstead ofBoolean. Null is not a valid result for a filter IMO.MessageSourcewhy throwing aMessageNotFoundException? What additional information I get instead of simply returningnull? Throwing an exception also makes working withResourceBundlesometimes a pain, so the design flaws should not be repeated here...