Ping - Re: RFR 8078812, Test RMI with client and servers as modules

[Felix Yang]

Hi Stuart,

     thanks for the comments.

On 2016/5/21 7:52, Stuart Marks wrote:
> On 5/16/16 1:18 AM, Felix Yang wrote:
>>    please review the updated webrev, which remove not-suggested 
>> filesystem
>> modification and codebase stuff:
>>
>> http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/
>
> Hi Felix,
>
> OK, this is looking much better and simpler. The big improvement is, 
> as we had discussed, the creation of a common fixture for the tests. 
> The tests then use the same fixture in different ways to exercise the 
> different cases. This makes this more easily extensible to additional 
> cases.
> ...
>
> It's up to you whether you want to accept my changes and continue from 
> this point, or go in a different direction, but to my eye this is 
> cleaner and easier to follow.
I accept your changes. 'pathJoin' looks cool. Though, I personally 
prefer to work with Path rather than strings (fileJoin). Any way, both 
ways are OK for me.

Thanks,
Felix
>
> * * *
>
> Now, finally, on to more substantive review issues. :-)
>
> One thing that seemed to be missing was that the application itself 
> wasn't wrapped up into a jar file. I've added another Jar command that 
> does this.
>
> Now we have the client, server, and app as separate hierarchies under 
> the "exploded" directory, and as modules under the "mods" directory.
>
> I think the idea of having the "exploded" class hierarchy as well as 
> jar files useful as modules is a good one. This will let you add 
> cases, where different components are on the classpath or are loaded 
> as modules, in addition to the two already present here.
>
> One issue here is that there's a module-info class for the app. This 
> makes the app an actual named module (I think) as opposed to an 
> automatic module like the client and server jar files. It seems like 
> it would be preferable to be consistent and have them all be automatic 
> modules.
>
> Given this arrangement, it should be pretty easy to have tests for any 
> of the combinations we want of classpath vs modules. I guess there are 
> 8 combinations: three components, each of which can be on the 
> classpath or as a module. It's not clear to me that we need all 8 
> combinations. It's probably sufficient to have a reasonable subset.
OK, I updated the test to a pure automatic modules version. Following 
subset is selected. Please suggest:
1. all in automatic modules
2. only dummy app as automatic module, and others are in classpath
3. client/server as automatic module, and dummy app is in classpath
4. server/app as automatic module, and client is in classpath

Updated webrev:
      http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.03/

Thanks,
Felix
>
> An idea for possible future expansion is to mix automatic modules with 
> named modules. I'm not entirely sure how to do that. Perhaps one way 
> is to have module-info files for all the components, and then create 
> variant jar files with the module-info.class omitted. That way we'd 
> have a modular jar, and then a "plain" jar (without module-info.class) 
> that'd be suitable for use as an automatic module or to be put on the 
> classpath. That'd be 3^3=27 combinations, which I certainly think is 
> overkill.
How about try this in later expansion?
All declared as named modules
Compile to exploded dir as usual
Enhance the JarUtil to accept a filter to exclude any file during 
creating jars (in this case, module-info.class)
Then expand the test by specifying mp/cp with automatic modules, 
explored named modules

-Felix
>
> In any case, for this initial changeset, I think it's sufficient to 
> test a few combinations of automatic modules vs. classpath. We can 
> extend the cases to include named modules later. Please make a 
> recommendation for some set of combinations and implement it, and then 
> send it out for a final round of review.

>
> Thanks.
>
> s'marks