Late for the train

[Daniel Latrémolière]

Le 20/07/2012 00:02, mark.reinhold at oracle.com a écrit :
> Leaving that particular design direction aside, I don't think it's a good
> idea to deliver a module system for user applications without, in the
> same major release, also using that system to modularize the JDK itself.
>
> The danger is that if we deliver a module system in release N but don't
> use it to modularize the platform until release N+1 then we run a big
> risk of getting something fundamentally wrong in the module system.
> If that happens then we'd have to fix it in release N+1, and fixing
> fundamental design flaws after the fact almost always leads to a poor
> end result.
Each new version of Java is (near) compatible with previous version, but 
without update of source code, it will have a technical debt. By 
example, try-with-resources is very useful and even if Java6 source code 
can be compiled and executed completely unchanged on Java7, the source 
code need to be updated to not be in technical debt comparatively to 
Java7 new source code.

For me, an imperfect but reasonable design seems better, even if 
slightly breaking source code compatibility in N+1 version for 
correcting some small parts. If Java 1.0 does not existed because memory 
model has waited Java 1.5 to be rigorously defined, Java would probably 
not be the most common programming language. I see the gap, between MIDP 
and JavaSE, full of Android devices for the same problems of abuse of 
compatibility (particularly lack of a Java mobile/core profile).

For me, a fundamental design flaw is less probable if something is 
designed from external requirements than from internal implementation (a 
module-private access control is this sort of black-box design, clearly 
incomplete for implementing a full module system but exactly defined by 
itself and without expectable need of future semantic change). If 
existing, it will make a good path for adoption of some modules features 
in some Java programs. When completed with all others Jigsaw features, 
it would have all the features of module system but with probably a 
faster global adoption (big features/projects need time to really be 
adopted, probably more than the two parts of the same project after 
cutting it).

Some big Oracle projects (e.g. JavaFX) have suggested (and developed 
tools for) embedding of a specific version of Java runtime in 
application for controlling compatibility problems, then compatibility 
is not probably a magical solution even at Oracle. For me, including 
technical debt, each Java version is correctly compatible with previous 
version, but not strictly compatible (excepted when Java will be dead or 
no more evolving usefully) and I see this as good feature because it 
tell that Java is not dead and add useful features.

Including technical debt, source compatibility is never perfect, except 
for a dead language, then it is (at least for me) acceptable to have 
possible changes between versions of Java for correcting design errors. 
Each version already need source changes for reducing technical debt.

> Aside from that, there are less than ten months to go in the Java 8
> schedule for work on major features.  There just isn't enough time to
> consider such an alternative in a way that would take into account the
> varied needs of the entire Java community.  Sorry.
I can perfectly understand this and it is sad because it would be useful 
to have a small significant part of modularity, for improving source 
code and starting adoption of modularity in JavaSE, even without the big 
rest of modularity.

Thanks,
Daniel.