Re: Thoughts on future of the Java ecosystem

[Andreas Huber <a....@corax.at>]

Hi Dan,

hope everything is fine on your end!

4 months have passed and I'd like to refresh this vision.

== Currently we have following containers, that we could/should support:

1) Servlet Container (Tomcat, Jetty, ...)

2) CDI 1.2, JAX-RS 2.0
* Eclipse MicroProfile 1.1+
* Java EE 7 (glassfish 4, payara 4, wildfly 10, ...) supports domain
code to be compiled with Java up to 8

3) CDI 2.0, JAX-RS 2.1
* Eclipse MicroProfile 2.0+
* Java EE 8 (glassfish 5, payara 5, wildfly 11, ...) supports domain
code to be compiled with Java up to 9 (still work in progress)

Our goal could be to transition 'isis-core' to these standards:
* Servlet API 3.0
* CDI 1.2
* JAX-RS 2.0

If we want to keep pure Servlet Containers (Tomcat, Jetty, ... that lack
CDI and JAX-RS) in the picture, developers have to package these
standard-technologies with their web-app's WAR file or setup their
container with shared libraries. (See proposal below ...)

== What to expect from this transition:

1) Servlet API 3.0

Remove deployment descriptor (web.xml) from web-apps. Allows for
'auto-magical' plugging-in of Servlets and Filters as deployed.
Reduces maintenance cost on both sides, Isis committers and Isis 'users'.

2) CDI

Provides an eventbus (we could make CDI's eventbus the default for Isis)
Provides class/bean discovery (I believe could be utilized as
replacement for reflections.org, if we want to drop guava dependency
entirely)
Provides dependency injection (we don't necessarily require to use it
immediately, as Isis' own implementation can peacefully coexist)

3) JAX-RS

Allows removal of jboss-resteasy.

== How to get there? Proposal:

We modularize 'isis-core' even further, introducing new modules:

1) 'runtime-eventbus-axon' to contain axon's eventbus, auto-magically
enabled if one deploys this with the web-app (ultimately not required on
JEE)

2) 'runtime-eventbus-guava' to contain guava's eventbus, auto-magically
enabled if one deploys this with the web-app (ultimately not required on
JEE)

3) 'runtime-jaxrs-resteasy' to contain resteasy, auto-magically enabled
if one deploys this with the web-app (ultimately not required on JEE)

4) 'runtime-cdi' to contain CDI, auto-magically enabled if one deploys
this with the web-app (never required on JEE)

As this is just a proposal, naming may change and we need a
proof-of-concept. But I'd like us to go in this direction.

Cheers, Andi


On 11.10.2017 13:50, Dan Haywood wrote:
> Hi Andi,
>
> Many thanks for raising this.
>
> When we've talked about this in the past in the community, the strong
> preference I think is exactly in the direction that you've indicated ... to
> make ourselves properly a JEE citizen and leverage its capabilities.  In
> particular, we don't want to take a dependency on Spring (though we do want
> to remain compatible with Spring, eg in the way that the Incode Platform's
> quickstart archetype lets a Spring container be instantiated "alongside"
> Isis in a single webapp.
>
> One of the main benefits of JEE is of course CDI support.  Now, Isis has
> its own home-grown dependency injection stuff (ServiceInjector class) and I
> would love to get rid of it and replace it with CDI throughout.
>
> It's possible that vanilla CDI doesn't support all the capabilties we need
> (eg we support injecting into List<SomeService> as well as just SomeService
> ... and there's some use of threadlocals deep in the bowels
> (IsisSessionFactory#currentSession) which may need some attention.  But I
> do know that CDI is extensible, and Apache DeltaSpike provides a bunch of
> useful extensions also that might do what we need.
>
> As Oscar says, we do have some guice in the mix, that's mostly for the
> wiring up of the Wicket viewer.  I think my intention when I introduced
> that was to replace Isis' implementation, but CDI is the better way to go.
> The Wicket Viewer will need some attention here, though, because I think it
> uses wicket-guice in order to do auto-injection of guice-registered
> components into Wicket components/pages.  I think there's also wicket-cdi
> integration though, so it hopefully will be possible to port this.
>
> With respect to other JEE features, some that come to mind are:
>
> - maybe we could ditch our depenency on RestEasy if JAX-RS is baked into
> JEE (is it, I'm not sure)
> - maybe we could remove our web.xml configuration (though note: this
> changes the developer "experience")
> - maybe we can standardize on using JEE datasources rather than using DN's
> connection pooling.
>
> Related, I'd like to do a bit of a purge on our third party dependencies,
> and to rationalize them.  Several reasons here:
>
> - it's not a good first impression to seemingly download half the internet
> - it increases the chances of a "JAR hell" conflict.  One dependency that
> we use a lot is guava, but I've come across blog posts from other open
> source folks saying they avoid it because it updates often and they fairly
> aggressively remove deprecated stuff
> - having lots of dependencies will make supporting Java 9 modules much more
> difficult.
>
> So, I think we're on the same page here.  The only reason none of this has
> happened so far has been down to priorities and time.  But I'm looking
> forward to making Isis leaner!
>
> Thx
> Dan
>
>
[...]