On 12/04/2015 09:48 AM, Alan Bateman wrote:
On 04/12/2015 13:50, Reinier Zwitserloot wrote:
:
Emphasis mine: "only"?
"Just add some command line switches" is not exactly a nice solution.
From
personal experience, the vast majority of java users do not know how
to add
configure command line switches to the various compile and build VMs
being
started by their build tools of choice, for example. Also, not something
Alan mentioned here: Adding the command line switches is currently the
_ONLY_ solution, so tools that are aware of the issue can't even fix it,
other than by mangling modules (bad idea, I think we all agree on that I
assume), or advising the userbase not to actually USE any of the
modularity
features and, preferably, to avoid switching to JDK9 altogether.
The context for this discussion, as least my understanding, is that we
were talking existing code where you are trying to run it in the same
way as you did in JDK 8. If that code is using JDK-internal APIs then
the command-line option is the only workaround proposed to keep that
code working.
I agree that setting the command-line is a challenge in many
environments, esp. when it is buried in XML files or scripts. You may be
right that it is beyond some developers too. We've tried to make error
and exceptions as clear as possible so that it's not too difficult to
figure out what is going on.
Emphasis mine: "starting out"?
This gets back to an earlier issue I raised on this mailing list: Okay,
starting out this isn't an issue, but by having no way to opt out of
export-based access control, it's a bit like switching from driving on
the
left side of the road to the right: Unless the entire greater java
community switches in the same instant, we're all going to have a bad
time.
The current design and prototype provides support for migration to
modules without waiting for the rest of the world to migrate. We're
going to need more experience, help, feedback to make sure that this is
useful.
The main challenge is of course is the tension between frameworks and
strong encapsulation. Existing frameworks don't know about modules and
so it will be important for willing maintainers of at least some
important frameworks to work with us to get to the right solution. Maybe
then we can start switching to the other side of the road, a gradual
migrating, starting with the big trucks :-)
At the risk of going well beyond annoyingly repetitive, I'd like to
point out that our experience shows that the existing frameworks may not
know about modules... certainly not Jigsaw-flavor modules... but they
generally *do* know about ClassLoaders, and we've found that the vast
majority of frameworks we employ and make available to users already
function acceptably well in a class loader-based module system. So the
act of breaking existing frameworks should not be misconstrued as a
necessary result of adding modularity; it is only a necessary result of
the current Jigsaw modularity design.
--
- DML
