| Re: [ee4j-pmc] Jakarta EE principles |
Hi all,
I was chatting with David B. and Ivar at DevNexus about some Jakarta EE
principles and API guidelines that we might agree upon in order to
direct the future of EE where we want it. I thought of things we liked
in Java EE, in a nutshell "what made Java EE great".
I was told that the PMC list is the right place to start. Is there a
place where it made sense to work on something already? Maybe GitHub and
a place where people could send their ideas and PRs to.
However, allow me to start with a list that I have brainstormed on my
flight to Moscow:
*Interoperability of specifications*
- honor existing specifications under Jakarta EE, don't reinvent already
existent things, e.g. CDI's dependency injection
- if possible, leverage the power of CDI
- concrete: provide CDI producers and if neccessary typesafe qualifiers
for types that need to be created, example: UriInfo, possible future
example: ClientBuilder
- concrete: require that if runtime supports both specification _A_ and
_B_, _A_ + _B_ have to collaborate with eachother, example: JAX-RS with
BV, JAXB, or JSON-B
*Declarative approach*
- leverage Inversion of control, dependency injection
- good API examples are JAX-RS, JSON-B, or CDI
*Convention over configuration*
- minimize required configuration
- convention should work for the majority of the use cases
out-of-the-box, with zero configuration, example: no XML files required
anymore
- flexibility, but convention over configuration, especially for most
used cases
- "make the easy simple and the difficult possible"
*Business logic first ("put first things first")*
- technology can be "removed" easily, just a couple of annotations on
plain business logic Java code
- it's good to "be boring"
- lean integration into your code, don't design for reusability, design
for removal
- don't get in the way of the business logic
- the implementations are required to take as much heavy lifting off the
shoulders of developers as possible, examples: threading, transactions,
IoC, request handling
*Deployment strategies*
- leverage separation of concerns: separating the business logic from
the implementations
- enable thin deployment artifacts: simplification and faster delivery
(incl. builds, publication & deployments), also plays well with
container technologies (COW file systems)
- deployment artifacts ideally only comprise the sole business logic,
runtime implementations and potential third-party libraries are
delivered in a lower "layer"
examples: application container with added libraries, or Docker
container with lower container layer containing required the dependencies
- make it possible to slim down the runtime, but not a requirement.
focus on business logic and developer productivity first, tuning the
runtimes second
Both of these categories and each lists are hardly exhaustive. Feedback,
changes, criticism of any kind are more than welcome. I'm more than
happy to contribute this to a place in the Jakarta EE universe.
Cheers from Moscow (on the way to the JBreak conference),
Sebastian
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-pmc