cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: New Java 9 master
Date Thu, 04 Jan 2018 09:35:13 GMT
Ok, the behavior is a bit different with this flag or not transitively (a
named module will see these classes as belonging to a named module so using
them you looks SPI, RB etc... but not for their own usage) but it looks it
can work "good enough" short term.

Le 3 janv. 2018 22:42, "Andriy Redko" <> a écrit :

Because it will be **always** named automatically, there is nothing we can
do about it. The only thing we can
do is to suggest the better name for automatic naming (which still keeps
module in unnamed category). I think the
good example may be a convincing argument towards go / no-go decision, will
try to find time to work on it this week.

RMB> Le 3 janv. 2018 18:28, "Andriy Redko" <> a écrit :

RMB> As per my understading of the efforts required (I hope to be wrong
here), this is ideal but unrealistic for CXF. We either
RMB>  start build some foundation (following other projects), or embark on
transforming everything to named modules (and we will be
RMB>  affected by all our dependecies anyway, there is nothing we can do
about it). I see the first option doable, CXF won't
RMB>  able to embrace the migration at once untill all and every dependency
we use does the same. This might happen eventually
RMB>  but not any time soon for sure :-(

RMB> Why not keeping it unamed then? There are very few adherence on cxf
except in integrations, no?

 RMB>> This is my first point. Once named and fully migrated you hit both
issue: not default classloader and visibility
 RMB>> change. First is surely workaround-able but last impacts users so
better to let people migrate on java 9...only
 RMB>> once and not N times cause CXF didnt embrace it at once. This is my
big concern.

 RMB>> Le 3 janv. 2018 01:56, "Andriy Redko" <> a écrit :

 RMB>> I don't think this is the case actually. If you use CXF as-is right
now in modular application, its components will
 RMB>>  be loaded as automatic modules, implicitly. The only step forward
we are taking is to hint JVM what the name of the
 RMB>>  automatic module should be (instead of relying on the automatic
conversions). Rules don't change, the presence
 RMB>>  of automatic module name in the manifest does not make the JAR a
named module, only will do that
 RMB>>  (and this would be a large and risky change indeed). But the
presence of the better name would help us to do
 RMB>>  migration to a bit more smoothly, since the module
name won't change but semantics of the module
 RMB>>  will (one by one they should become named modules).

  RMB>>> yep

  RMB>>> issue is exactly this one: automatic modules are a one way path,
you can't go back on manual modules since you
  RMB>>> exposed the world and would introduce a breaking change modifying
  RMB>>> The other one I tried to mentionned is: what about all the cases
where CXF will be deployed on java 9 but not in
  RMB>>> the root classloader (tomcat to cite a random case) which doesnt
support the new SPI loading? You are broken :(

  RMB>>> Romain Manni-Bucau
  RMB>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

  RMB>>> 2018-01-02 14:54 GMT+01:00 Andriy Redko <>:

  RMB>>> I might be mistaken (sorry, haven't worked with Jigsaw closely
yet), but I think the service loader would work the same
  RMB>>>  way in case of named module and automaticaly named module. The
only differences would be contraints/rules/visibility: automaticaly
  RMB>>>  named module just implicitly open/export/import everything while
named module should be picky and precise.

RMB>    RMB>>> Or the worst since you dont expose the "api" but all the
classes and breaks SPI since service loader loading is different in named
modules, no?

RMB>    RMB>>> Le 31 déc. 2017 19:15, "Andriy Redko" <>
écrit :

RMB>    RMB>>> I am not sure about plugin part, to be honest. I would
better craft the by hand (but use
RMB>    RMB>>>  the tooling, jdeps f.e., to get the initial list of
modules) and have it in the source tree for each module,
RMB>    RMB>>>  so to keep the history, etc. That would be aligned with
Sergey's suggestion to have Java 9 master sometime
RMB>    RMB>>>  in the future.

RMB>    RMB>>>  But, by and large, you may be right and the plugin is the
viable option. Still, if 99% of the CXF dependencies are
RMB>    RMB>>>  going to be automatic modules nonetheless, what it will buy
us? And looking into other projects, that seems to
RMB>    RMB>>>  be the starting point for many. Anyway, I would prefer to
get it all and right now :-D but realistically, I see
RMB>    RMB>>>  the automatic module name to be the less riskier approach
to begin with (just a manifest change), not necessarily
RMB>    RMB>>>  the best one though.

RMB>    RMB>>>  Best Regards,
RMB>    RMB>>>      Andriy Redko

RMB>>    RMB>>> Hmm, shout if I didn't get your comments properly and my
comment is obvious but I think 1 and 3 are fine - that's
 RMB>>    RMB>>> why I proposed them - because you can create the with java 8. This is what does the plugin I
 RMB>>    RMB>>> mentionned, writing it directly with java 9 (long story
short it has a module-info parser and writer).

 RMB>>    RMB>>> Romain Manni-Bucau
 RMB>>    RMB>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn

 RMB>>    RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko <>:

 RMB>>    RMB>>> Hi Romain,

 RMB>>    RMB>>>  I think there are 2 parts regarding modules: 1) using CXF
from modularized
 RMB>>    RMB>>>  applications and 2) release/redesign CXF in a modular
fashion (I mean Java 9 modules).
 RMB>>    RMB>>>  The 2nd part is where we are heading eventually but we
won't be trully modular till
 RMB>>    RMB>>>  all our dependencies are available as modules as well.
The idea of adding
 RMB>>    RMB>>>  automatic module name is helping out with the 1st part.
Regarding your questions
 RMB>>    RMB>>>  though:

 RMB>>    RMB>>>  1. Adding would mean, at least, to
branch the artifacts (java9+ / java8).
 RMB>>    RMB>>>  2. Yes, I think it makes sense, this is the recommended
way, but we should better make a
 RMB>>    RMB>>>  proposal first (as part of the JIRA Dennis created).
 RMB>>    RMB>>>  3. I think this is the only way (as
won't compile with Java 8)

 RMB>>    RMB>>>  Automatic modules is a good start (arguably, for sure),
because from the efforts
 RMB>>    RMB>>>  perspetive, it looks doable in a short time vs adding
proper to
 RMB>>    RMB>>>  each module, which would take significantly more.

 RMB>>    RMB>>>  Best Regards,
 RMB>>    RMB>>>      Andriy Redko

  RMB>>>    RMB>>> Hi guys,

  RMB>>>    RMB>>> Few random notes/questions:

  RMB>>>    RMB>>> 1. Why not using
  RMB>>>    RMB>>> and assume the moduleinfo instead of working it around
with automatic
  RMB>>>    RMB>>> module name?
  RMB>>>    RMB>>> 2. For the naming it should really be someting like
$group.$module IMO,
  RMB>>>    RMB>>> probably with underscores instead of iphens for the
module and maybe
  RMB>>>    RMB>>> removing cxf from the module dince it is in the package
  RMB>>>    RMB>>> 3. Is it possible to double relezse each module, one
with the module info
  RMB>>>    RMB>>> (if you do 1, or without the automatic module name if
you dont) and a
  RMB>>>    RMB>>> qualifier jdk9 and keep current ones as today until the
whole stack is java
  RMB>>>    RMB>>> 9 (transitively). Easy to break consumers otherwise.

  RMB>>>    RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst" <> a écrit :

  RMB>>>    >>>> > Exactly, that's the idea, updating the manifest
  RMB>>>    >>>> Automatic-Module-Name. We could also add a sample
  RMB>>>    >>>> > project (this would be Java 9 based) to illustrate
basic usage of
  RMB>>>    >>>> CXF from/within green field Java 9
  RMB>>>    >>>> > modular project (although we may need to do more
here I suspect).
  RMB>>>    >>>> Thanks.
  RMB>>>    >>>> I've opened CXF-7600 for it. What should be the
  RMB>>>    >>>> for cxf-core? Just org.apache.cxf? Or org.apache.cxf.core
which doesn't
  RMB>>>    >>>> match the package name structure?

  RMB>>>    >>>> Regards
  RMB>>>    >>>> Dennis

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