Compile time vs. runtime deps

[Jaroslav Tulach]

Dne Čt 12. července 2012 10:54:27, David Holmes napsal(a):
> >> I don't see why I need to make the distinction to the compiler. I
> >> declare an optional dependency and at compile-time it is, or isn't
> >> found.
> > 
> > That could produce different result during the compilation. The
> > compilation
> > could either succeed or fail. Javac and IDEs need to know whether the
> > optional (in runtime) library should or should not be on the compilation
> > "classpath".
> You mean the tools are going to dynamically examine my
> module-info.java/class and use it to determine what they should set
> modulepath/classpath to ???

Hello David,
yes, that is the jigsaw plan. module-info.java is going to be the source of 
compilation classpath for javac. It is supposed to save us for "classpath 
hell". However, unlike other tools that shield us from such "hell", the 
current design addresses just a half (at most) of the problem. Should it stay 
this way, we are going to be faced to "classpath nightmare"...

> That is not something I would have expected at all. 

I guess you are looking at Jigsaw from VM perspective, then! That is OK, but 
the Jigsaw tries to define (a bit of) tooling story too.

> If I build a project
> and the optional, but needed at compile-time, module is not present then
> I get a compilation error: type XXX not found. It is then up to me to
> realize that I am missing the module that exports XXX and either install
> it to the main library or add the library it is in to the appropriate
> path. (Just as I would have to add the jar file today.)

The vicious circle is closed by noting that the "appropriate path" is 
expressed in module-info.java. And we are back where we started: this missing 
module is required for compilation, but optional for execution - we need a way 
to express that inside of module-info.java.
-jt

> 
> >> During compilation I reference a type and a module for that type
> >> is, or isn't, found. Whether the module was omitted or was optional it
> >> is simply a compile-time error if the type is not found. (I don't expect
> >> javac to know or determine that the not-found type would have been found
> >> in the missing optional module - how could it?)
> > 
> > The Javac and IDEs have to know. My proposal was to introduce some way of
> > telling the system that there is a compile time only dependency. Thus for
> > the case when you want a fully optional dependency you could say:
> > 
> > requires optional m at 1.0;
> > 
> > which would mean "m at 1.0" should not be present while compiling. Or one
> > could use
> > 
> > requires compile optional m at 1.0;
> > 
> > which would make the "m at 1.0" optional during execution, but Javac and
> > other
> > source processing tools would know that it has to be present.
> 
> Seems like an unnecessary complication to the module system to me.
> 
> Cheers,
> David
> 
> > -jt
> > 
> >>> This is another example when runtime and compile time dependencies may
> >>> differ. The first one I know is the list of annotation processor
> >>> providing
> >>> modules to be present when compiling, but not during execution.
> >>> 
> >>> Time to introduce "requires compile m at 1.0"?
> >>> -jt