polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Java 9 modules
Date Mon, 19 Sep 2016 23:35:21 GMT
To further spin some ideas on the Java 9 Module system,

-o-o- Builds -o-o-
The build system should become a lot simpler, and we should not need one
subproject per produced artifact. Whether we end up with one build project
or a handful is not yet clear to me. I think a lot depends on what happens
at Gradle, but I suspect that it will be pretty good at this (compared to

-o-o- Visibility -o-o-
Does it then make sense to group a Zest Module into a Java Module? One of
the most annoying things with Zest is that Visibility shows up relatively
late in runtime. If we could get these two different module systems to
"collaborate", I think there might arise a possibility for Visibility to be
resolved at compile time, and make life easier.
Additionally, Java Module system has a "Layer" system, which means
something different from Zest "layers". Basically it is about classloader
hierarchies. But this might get a similar effect by placing the bottom Zest
layers at the "top" in the hierarchy. Probably not possible to
enforce"within Layer" and "next Layer only" visibility. Perhaps it could be
manipulated into understanding Zest semantics.

-o-o- Module Auto Assembly -o-o-
The Module system will generate at compile time meta data for Annotated
classes. This avoids the current "scan all classes" which is slow. It also
keeps the annotations well organized, as one can query module by module,
hence knowing where everything belongs. Since indexed class annotations is
becoming a standard feature, I think there is value in incorporating this
into Zest Core. A very simple approach would be a "@Assembler" annotation
on classes needed to assemble a Module. But I think there are more hiding
in the hallway on this.
Likewise, we could designate a filename that contains additional meta data,
such as which layer the module belongs to.

The latter two of these things are almost present in OSGi as well, so we
should probably abstract out the implementation detail of that and make
that pluggable at runtime.


On Mon, Sep 19, 2016 at 3:04 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> Gang,
> Just learning Java 9 Modules, and it will impact us quite a bit I think.
> The outcome will be nicer, but the entire build structure should change.
> The good part is that I now see Java 9 as July 2017, so plenty of time.
> This is just a heads-up to investigate Java 9 Modularity as it will impact
> many things we (both as Java devs as well as Zest devs) do.
> Niclas

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message