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
