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
