Feature complete?

[David M. Lloyd]

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