Self-describing sources: the JavaC patch

[Jaroslav Tulach]

Hello Paul,
I am on vacation, but I found this message worth replying sooner than I get 
back.

Dne Út 3. července 2012 14:45:23, Paul Sandoz napsal(a):
> 
http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#commandlineargfile
> 
> I suppose a motivation for this feature was command line length limitations.

Very likely this support has been created to workaround some OS limitation. On 
the other hand, it basically captures the IDE needs.

> On Jun 26, 2012, at 11:14 AM, Jaroslav Tulach wrote:
> > Hello guys.
> > We had a discussion with Paul recently trying to find a way to have a form
> > of self-describing sources and not to compromise ''module-info.java''
> > purity.
> > 
> > Here is a proposal
> > http://wiki.netbeans.org/JavacOptionsInSourceFiles
> > that modifies JavaC a bit and seems to fulfil many of the needs IDEs
> > have[1].
> > 
> > What can stop us from changing JavaC to perform
> > 
> > $ javac @source-info.cfg
> > 
> > by default? Using this format for OpenJDK sources itself?
> > 
> > 
> > Changing other CLI
> > tools jar, jmod to extract information from the same configuration file?
> 
> Would it be fair to say the logical progression is towards a project
> description configuration?

Right. Sources can't live alone and you need some information to process them 
the right way. Basically it sounds like a project description configuration, 
but see [1].

> I don't see how the NetBeans goal of 100% parity with a headless build could
> be achieved otherwise.

The way JavaC and other JDK tools (jmod, jar) understand the sources should be 
driven by the file layout. Not by (extensively long) command line parameters.

> How would NetBeans differentiate between source and test source? 

[1] Please don't imagine Maven, we don't need to go that far. In certain 
systems "project" may not mean code+test. I've seen some systems that have a 
special project for the sources and other project for tests. I have not 
noticed any activity on the JDK team side to adhere to 21st century testing 
standards. And I don't need it. Code can live without tests, in spite what 
Maven tries to teach us...

> Or
> differentiate between building a modular jar or a jmod file?

My proposal was suggesting different sections for [jar] and for [jmod] inside a 
single configuration file. Thta would basically be it, I guess. Details are TDB, 
first I need to convince JavaC team to even consider this idea, then jar and 
jmod will be the next target.

> There needs to be an orchestrating meta-tool and configuration, and if such
> a meta-tool exists then is there any point in each tool processing the
> configuration file? since the meta-tool can tell the other tools what to
> do.

Is not that a matter of abstraction? Maven certainly defines "phases" that 
abstract from compilation, war, jar packaging, etc. For our purposes, it is 
essential to know that is it necessary to invoke javac before invoking jmod. 
But for that we don't need an "orchestrating meta-tool". Enough to hard code 
it for now.

-jt

PS: Please keep in mind that I am investigating options what will allow 
NetBeans to support Jigsaw without using Maven. Of course, if Jigsaw team 
tells us: "Go use Maven", we can get all our meta-information there.