Context and expectations

[Daniel Latrémolière]

>>
>> Honestly, I continue to dislike Jigsaw remembered goal: "The goal of 
>> this Project is to design and implement a standard module system for 
>> the Java SE Platform, and to apply that system to the Platform itself 
>> and to the JDK.", because "module" say all or nothing depending of 
>> reader, but is not a clear set of potentially independent features 
>> (internal improvement of OpenJDK code, abstraction for hiding some 
>> parts of implementation, deployment package compatible with RPM/DEB, 
>> object with an externally managed lifecycle, storage repository for 
>> code and JIT metadata, etc.) coming each with his improvements to 
>> developer/sysadmin life (the only real goals of OpenJDK for me) and 
>> needing or not new public API/language changes.
>> I would prefer something like "The goal of this Project is to design 
>> and implement a module system for the Java SE Platform, to improve 
>> abstraction in Java code and increase performance of VM and 
>> simplicity of deployment."
>> For me, Java developers has no direct interest to know if Jigsaw is 
>> used by OpenJDK itself or not (it is an OpenJDK-implementation detail 
>> and not a goal, even if it is a big detail). By example, OpenJDK can 
>> use specific extensions to Jigsaw (not public module API) for his own 
>> modularisation without any knowledge from Java developer.
>
> There are several reasons to not do that. You create an artificial 
> barrier between the OpenJDK code and the application code so you raise 
> the entry ticket for anyone that want to provide a patch or fix a bug 
> in the JDK, you force application developers to use their own solution 
> to solve exactly the same problem, so each implementations (the 
> OpenJDK one included) will be less tested.
>
> Netbeans has modules, JBoss, Eclipse have modules too. How many kind 
> of modules did you want before thinking that having a good standard 
> module API in the JDK is a good idea. It's better to provide a feature 
> that everybody can use, that is well tested and for the sake of 
> shaping the API, eating our own dog food is in my opinion a very good 
> idea.
Hi Rémi,

When I have a specific use-case for an Ant script not cleanly solved by 
currents tasks or a macrodef, I can create my own task (sometimes 
useful). Am I creating an artificial barrier between developer and code: 
yes, but it is simpler and more readable than a very complicated Ant 
process or completely remove Ant replaced by a custom build tool. Even 
in this case, I use common Ant tasks for 99% of my script and the 
extension use is clearly defined (by namespace used) and follow in this 
case the XML syntax. I will not try to give to Ant a complicated task 
for inclusion in their product, because no other user will use it 
(specific need). I think this example is the same problem than your 
suggest, and many projects create own Ant tasks without destroying Ant 
(even increasing interest in Ant).

Yes, Modules are already existing in multiple variants in various 
products: it's a fact and not a bad fact because it say there is a need 
for module system. For me, creating a standard is mostly extracting the 
clearly defined commons parts and improve them to allow better design 
and let extensions manage uncommon/under-defined parts. When some 
extensions are commonly used and better defined, they can be improved 
and included in the standard or at least a profile of standard.

I have seen many standards created by concatenating, in one standard, 
all the existing proposals from each vendor to clearly like short, 
incomplete and extensible standards improving as good practices help to 
choose a technical road against business roads (proposed by each vendor).

By example when standardizing a module access control in Java (with a 
ModuleLoader for enforcing the access control and an extensible 
module-info.java containing only mandatory name-version and annotations 
for all others extensions), you are attracting all current module 
systems by giving a new feature (access control in Java language) and 
you create a first common part to all existing modules systems. Each 
module system will currently have own annotations, but semantic of 
annotations can begin converging to allow future inclusion of some 
common annotations as standard constructs in module-info.java.
Replacing in one file per module (module-info.java) the OpenJDK specific 
annotation of Java 8u_n with a syntax like @View(name="my-view", 
classes={MyClass.class, ...} )  by a future standard construct in Java 
9  like "view my-view {class MyClass; ...}" is a very small work for 
avoiding technical debt of a major release. Compare this to even Java7 
update of existing source code with features like try-with-resources, 
exception multicatch, switch on strings, impacting all source code or 
NIO2, JSR292 having very big impact on some code.

If you are not trying to replace, in one step, all solutions already 
existing in the world, but to improve common parts by changing core Java 
for better integration, each solution can give focus on solving better 
his problem and another step (Java 9) in standardization will be able to 
move in core Java some others features, better tested in real-world 
(module deployment by example). If you are trying to completely replace 
in one step, then a user of another current module system will not use, 
even partially, a Java module system when he will see only one simple 
lacking feature in Jigsaw but potentially used from the other module 
system (possibly even if it is a simple change of name of the feature).

I always like eating our own dog food. But in a module system, for me, 
"eating his own dog food" is modularizing the module system (standard 
core always included with some common use-cases; allow extensions for 
specific use-cases). Then I can read "eating his own dog food"-principle 
as exactly the opposite of your reading.

Simply speaking, what is a "good standard module API" before real-world 
experiment?

Daniel.