Self-describing sources: the JavaC patch

[Paul Sandoz]

Hi,

On Jul 5, 2012, at 10:45 PM, Jaroslav Tulach wrote:
> 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.
> 

So a default path for the source-info.cfg, and perhaps default paths for source, compilation of and jars/jmods?


>> 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...
> 

While i had maven in mind i was also thinking more generally e.g. unit-like tests are run and need to pass before installing and/or releasing.


>> 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.

OK, just trying to work out what a larger picture might be.

I suspect any largish project is likely to consist of multiple modules that are, where possible, compiled and installed independently in a well-defined order. I hope the JDK modularization effort of source restructuring heads towards that approach but it may take a while to get there.


> -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.
> 


We need the likes of Jon et. al. to opine on this.

I feel a little under qualified to espouse confidently on this area but it seems to me the approach of defaults and options in a source configuration file is low enough down in the stack to be flexibly reused by other tooling and quite useful for simple Java projects.

Paul.