Re: 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