XML for module descriptor

[Eric Johnson]

On 4/17/12 5:36 PM, Debasish Ray Chawdhuri wrote:
> If JSON is used, it would not be compiled, the source will contain the same
> file I guess. Also even if compilation is done, it would give the errors
> related to the syntax of the file. The errors can be made readable. If we
> want to discourage editing the file, we should stick to binary format.

That last statement ("if we want to discourage....") seems a stretch. 
Precisely one of the values of a textual format is its accessibility for 
all sort of purposes that involve reading the file. Why would you want 
to take that away?

In already compiled JARs, has rampant editing of MANIFEST.MF files ever 
been a problem in the history of Java? How about for the history of 
OSGi? That seems evidence enough that developers are already 
appropriately disinclined to directly edit files of this ilk because of 
the zipped archive that typically carries this kind of data.

-Eric.

>
> On Tue, Apr 17, 2012 at 2:52 PM, Alan Bateman<Alan.Bateman at oracle.com>wrote:
>
>> On 17/04/2012 08:09, David Bosschaert wrote:
>>
>>> Seems like there is at least a majority for going with JSON as a
>>> format. I'm not an expert in encodings but to me it looks like it
>>> could be solved in the same way as currently done for the MANIFEST.MF.
>>> I'll start prototyping the JSON module descriptor in Penrose.
>>>
>>>   None of my business as to the format that you use but I hope that
>> developers will be strongly discouraged from editing the module
>> declarations post compilation, otherwise it may result in issues at runtime
>> that are hard to diagnose. Note that I'm not talking about the custom
>> meta-data as I don't know if that can be validated at build time. I'm also
>> not talking about tool agents as they may need to augment the access
>> control rules for instrumentation purposes.
>>
>> -Alan
>>
>
>