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

[Stuart Marks]

Hi Felix,

This is looking quite nice.

One small cleanup. Client.java has a constructor Client(int port), and an int 
port field. Both are unused and can be removed.

> 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.

If you'd like to switch to using Path, that's fine with me. Jon G has also 
expressed such a preference. It should be a fairly straightforward change. The 
fileJoin() utility can be removed, and pathJoin() can be replaced with the 
alternative version from my previous mail. Otherwise it's mostly a matter of 
removing calls to Paths.get() and adding calls to toString() in the right places.

> 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/

I think this is a fine subset. The different test cases are all quite simple and 
they're all straightforward variations of each other, and they all use the same 
test fixture!

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

Yes, this would be fine for future work. The exclusion of module-info.class from 
jar file creation seems like a reasonable approach.

If you eventually end up adding more test cases, it will probably result in a 
lot of redundancy in the way the sub-JVM is invoked. Also, the way to specify 
whether a particular component is in an unnamed module, an automatic module, or 
a named module will be somewhat cumbersome, so you'll probably want helper 
methods for that. And maybe you'd end up with a data provider to drive the test 
cases, instead of writing out individual test methods.

But all of this can be future work.

* * *

In summary, I think there is only the Client.java cleanup, and (optionally) the 
String=>Path conversion.

Did you need me to push this for you? This will go into jdk9/dev, right? I don't 
think it needs to go into jake.

s'marks