Re: New Java 9 master

[Romain Manni-Bucau]

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

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

> I don't think this is the case actually. If you use CXF as-is right now in
> modular application, its components will
> be loaded as automatic modules, implicitly. The only step forward we are
> taking is to hint JVM what the name of the
> automatic module should be (instead of relying on the automatic
> conversions). Rules don't change, the presence
> of automatic module name in the manifest does not make the JAR a named
> module, only module-info.java will do that
> (and this would be a large and risky change indeed). But the presence of
> the better name would help us to do
> migration to module-info.java a bit more smoothly, since the module name
> won't change but semantics of the module
> 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 it.
> 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>> 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>> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :
>
>  RMB>> I am not sure about plugin part, to be honest. I would better craft
> the module-info.java by hand (but use
>  RMB>>  the tooling, jdeps f.e., to get the initial list of modules) and
> have it in the source tree for each module,
>  RMB>>  so to keep the history, etc. That would be aligned with Sergey's
> suggestion to have Java 9 master sometime
>  RMB>>  in the future.
>
>  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>>  going to be automatic modules nonetheless, what it will buy us?
> And looking into other projects, that seems to
>  RMB>>  be the starting point for many. Anyway, I would prefer to get it
> all and right now :-D but realistically, I see
>  RMB>>  the automatic module name to be the less riskier approach to begin
> with (just a manifest change), not necessarily
>  RMB>>  the best one though.
>
>
>
>
>
>  RMB>>  Best Regards,
>  RMB>>  Andriy Redko
>
>
>
>   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>>> why I proposed them - because you can create the module-info.java
> with java 8. This is what does the plugin I
>   RMB>>> mentionned, writing it directly with java 9 (long story short it
> has a module-info parser and writer).
>
>
>   RMB>>> Romain Manni-Bucau
>   RMB>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>   RMB>>> 2017-12-31 16:58 GMT+01:00 Andriy Redko :
>
>   RMB>>> Hi Romain,
>
>   RMB>>>  I think there are 2 parts regarding modules: 1) using CXF from
> modularized
>   RMB>>>  applications and 2) release/redesign CXF in a modular fashion (I
> mean Java 9 modules).
>   RMB>>>  The 2nd part is where we are heading eventually but we won't be
> trully modular till
>   RMB>>>  all our dependencies are available as modules as well. The idea
> of adding
>   RMB>>>  automatic module name is helping out with the 1st part.
> Regarding your questions
>   RMB>>>  though:
>
>   RMB>>>  1. Adding module-info.java would mean, at least, to branch the
> artifacts (java9+ / java8).
>   RMB>>>  2. Yes, I think it makes sense, this is the recommended way, but
> we should better make a
>   RMB>>>  proposal first (as part of the JIRA Dennis created).
>   RMB>>>  3. I think this is the only way (as module-info.java won't
> compile with Java 8)
>
>   RMB>>>  Automatic modules is a good start (arguably, for sure), because
> from the efforts
>   RMB>>>  perspetive, it looks doable in a short time vs adding proper
> module-info.java to
>   RMB>>>  each module, which would take significantly more. Thoughts?
>
>   RMB>>>  Best 

Re: New Java 9 master

[Andriy Redko]

I don't think this is the case actually. If you use CXF as-is right now in 
modular application, its components will 
be loaded as automatic modules, implicitly. The only step forward we are taking 
is to hint JVM what the name of the 
automatic module should be (instead of relying on the automatic conversions). 
Rules don't change, the presence
of automatic module name in the manifest does not make the JAR a named module, 
only module-info.java will do that
(and this would be a large and risky change indeed). But the presence of the 
better name would help us to do 
migration to module-info.java a bit more smoothly, since the module name won't 
change but semantics of the module 
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 it.
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>> 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>> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :

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

 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>>  going to be automatic modules nonetheless, what it will buy us? And 
looking into other projects, that seems to
 RMB>>  be the starting point for many. Anyway, I would prefer to get it all 
and right now :-D but realistically, I see
 RMB>>  the automatic module name to be the less riskier approach to begin with 
(just a manifest change), not necessarily
 RMB>>  the best one though.





 RMB>>  Best Regards,
 RMB>>  Andriy Redko



  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>>> why I proposed them - because you can create the module-info.java with 
java 8. This is what does the plugin I
  RMB>>> mentionned, writing it directly with java 9 (long story short it has a 
module-info parser and writer).


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

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

  RMB>>> Hi Romain,

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

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

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

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


RMB>RMB>>> Hi guys,

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

RMB>RMB>>> 1. Why not using 
https://github.com/moditect/moditect/blob/master/README.md
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 

Re: New Java 9 master

[Romain Manni-Bucau]

yep

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


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

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

> I might be mistaken (sorry, haven't worked with Jigsaw closely yet), but I
> think the service loader would work the same
> way in case of named module and automaticaly named module. The only
> differences would be contraints/rules/visibility: automaticaly
> named module just implicitly open/export/import everything while named
> module should be picky and precise.
>
> 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> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :
>
> RMB> I am not sure about plugin part, to be honest. I would better craft
> the module-info.java by hand (but use
> RMB>  the tooling, jdeps f.e., to get the initial list of modules) and
> have it in the source tree for each module,
> RMB>  so to keep the history, etc. That would be aligned with Sergey's
> suggestion to have Java 9 master sometime
> RMB>  in the future.
>
> 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>  going to be automatic modules nonetheless, what it will buy us? And
> looking into other projects, that seems to
> RMB>  be the starting point for many. Anyway, I would prefer to get it all
> and right now :-D but realistically, I see
> RMB>  the automatic module name to be the less riskier approach to begin
> with (just a manifest change), not necessarily
> RMB>  the best one though.
>
>
>
>
> RMB>  Best Regards,
> RMB>  Andriy Redko
>
>
>
>  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>> why I proposed them - because you can create the module-info.java
> with java 8. This is what does the plugin I
>  RMB>> mentionned, writing it directly with java 9 (long story short it
> has a module-info parser and writer).
>
>
>  RMB>> Romain Manni-Bucau
>  RMB>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>  RMB>> 2017-12-31 16:58 GMT+01:00 Andriy Redko :
>
>  RMB>> Hi Romain,
>
>  RMB>>  I think there are 2 parts regarding modules: 1) using CXF from
> modularized
>  RMB>>  applications and 2) release/redesign CXF in a modular fashion (I
> mean Java 9 modules).
>  RMB>>  The 2nd part is where we are heading eventually but we won't be
> trully modular till
>  RMB>>  all our dependencies are available as modules as well. The idea of
> adding
>  RMB>>  automatic module name is helping out with the 1st part. Regarding
> your questions
>  RMB>>  though:
>
>  RMB>>  1. Adding module-info.java would mean, at least, to branch the
> artifacts (java9+ / java8).
>  RMB>>  2. Yes, I think it makes sense, this is the recommended way, but
> we should better make a
>  RMB>>  proposal first (as part of the JIRA Dennis created).
>  RMB>>  3. I think this is the only way (as module-info.java won't compile
> with Java 8)
>
>  RMB>>  Automatic modules is a good start (arguably, for sure), because
> from the efforts
>  RMB>>  perspetive, it looks doable in a short time vs adding proper
> module-info.java to
>  RMB>>  each module, which would take significantly more. Thoughts?
>
>  RMB>>  Best Regards,
>  RMB>>  Andriy Redko
>
>
>   RMB>>> Hi guys,
>
>   RMB>>> Few random notes/questions:
>
>   RMB>>> 1. Why not using https://github.com/moditect/
> moditect/blob/master/README.md
>   RMB>>> and assume the moduleinfo instead of working it around with
> automatic
>   RMB>>> module name?
>   RMB>>> 2. For the naming it should really be someting like
> $group.$module IMO,
>   RMB>>> probably with underscores instead of iphens for the module and
> maybe
>   RMB>>> removing cxf from the module dince it is in the package
>   RMB>>> 3. Is it possible to double relezse each module, one with the
> module info
>   RMB>>> (if you do 1, or without the automatic module name if you dont)
> and a
>   RMB>>> qualifier jdk9 and keep current ones as today until the whole
> stack is java
>   RMB>>> 9 (transitively). Easy to break consumers otherwise.
>
>
>   RMB>>> Le 31 déc. 2017 13:38, "Dennis Kieselhorst"  a
> écrit :
>
>
>    > Exactly, that's the idea, updating the manifest with
>    Automatic-Module-Name. We could also add a sample
>    > project (this would be Java 9 ba

Re: New Java 9 master

[Andriy Redko]

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

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> Le 31 déc. 2017 19:15, "Andriy Redko"  a écrit :

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

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>  going to be automatic modules nonetheless, what it will buy us? And 
looking into other projects, that seems to
RMB>  be the starting point for many. Anyway, I would prefer to get it all and 
right now :-D but realistically, I see
RMB>  the automatic module name to be the less riskier approach to begin with 
(just a manifest change), not necessarily
RMB>  the best one though.




RMB>  Best Regards,
RMB>  Andriy Redko



 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>> why I proposed them - because you can create the module-info.java with 
java 8. This is what does the plugin I
 RMB>> mentionned, writing it directly with java 9 (long story short it has a 
module-info parser and writer).


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

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

 RMB>> Hi Romain,

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

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

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

 RMB>>  Best Regards,
 RMB>>  Andriy Redko


  RMB>>> Hi guys,

  RMB>>> Few random notes/questions:

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


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


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

   Regards
   Dennis