Automatic module names

[David M. Lloyd]

On 02/03/2017 08:43 AM, Andrew Dinn wrote:
> On 03/02/17 14:29, David M. Lloyd wrote:
>> I think one option we should consider is to perhaps disable automatic
>> modules for 9 and revisit the idea for 10, as it's late in the day and
>> still clearly not settled.
>
> I don't think this is thinking about the trade-off correctly.
>
> Automatic modules may not work for some (or maybe many) of the more
> complicated cases but those failures can be addressed over time by
> adding a module.xml to update releases of jars.
>
> Automatic modules definitely does work for straightforward cases to
> provide an easy way of deploying jars you don't own/can't rewrite as
> modules.

Sure, but the set of JARs you can't rewrite is really pretty spare. 
And, in the few cases where it might cause a hypothetical problem (say, 
it's signed or something, though I doubt that this actually prevents 
rewriting the descriptor), there is at least one alternative provider 
that can modularize them cleanly (like ours, for example).

Tools like Maven can and probably will easily cover the vast majority of 
cases more effectively than this mechanism.  "It fixes many cases" is 
necessary but not sufficient for acceptance in my view.  "It doesn't 
bungle other cases" is also a necessary condition.

> Much as I admit that there are going to be lots of cases where it will
> fail I think those where it just works will still be a large subset. So,
> automatic modules will definitely be a big help to a lot of users who
> want to get started with Jigsaw.
>
> And, well, maybe I need to say this -- yes, an easy start is a /big/
> priority.

Yes, however there are more ways than one to bake that particular cake.

> That's merely 2 cents, gratis. Your mileage may vary, particularly when
> it fails for your app. But I don't the mere possibility of the latter as
> a reason to poop on someone (everyone?) else's parade.

I sympathize, mainly because software generally is a Tough Thing to Do, 
however "on the ground" I tend to disagree fundamentally with that 
sentiment, as in my experience this tends to lead immediately to "if the 
first idea works even a bit, run with it", which in turn means that 
quality becomes a lowest common denominator, which in turn invariably 
leads to high costs (of various types).  These ideas simply don't scale, 
and they're the ones that one inevitably looks back at 5 years down the 
road, saying "gee, I really wish we hadn't done that".  Sometimes the 
right answer is "OK, well that idea had some merit, but not enough to 
justify it".

I don't disagree with the goal of providing a rapid on-ramp for users - 
quite the opposite - but I think that the automatic modules feature 
itself is neither necessary nor sufficient in order to meet it.  I think 
tooling can be just as easy and intuitive, and far more effective in 
terms of use cases covered, flexibility, evolvability, etc.

-- 
- DML