Late for the train

[Debasish Ray Chawdhuri]

I don't think Main-Class is a compile time information. The compiler has
nothing to do with the Main-Class (its just another class), only the
runtime is interested in Main-Class. Where as the compiler needs to know
the module information to resolve the types.

On Fri, Jul 20, 2012 at 6:16 AM, Eric Johnson <eric at tibco.com> wrote:

> Since this has been a pet peeve of mine, this elicits a comment from me:
>
>
> On 7/19/12 5:06 PM, Alex Buckley wrote:
>
>> On 7/19/2012 4:54 PM, Alex Buckley wrote:
>>
>>> Because the compiler needs to know every type's module membership
>>> (module name _and_ version), and assuming you want to compile
>>> multiple modules in one compiler invocation, and assuming you might
>>> start compilation with only sources (not JARs), it becomes necessary
>>> to rework your Java compiler - a lot.
>>>
>>
>> I want to add that this is where the "module declarations in Java source
>> code" theme comes from.
>>
>
> The theme, though, is a mis-statement of the problem. The problem
> statement should use the phrase "module declarations **and** Java source
> code". The choice of "in" is an implementation choice. The obvious
> requirement is that both sets of information be used together by the
> compiler, without dictating the input form of the module declaration.
>
>
>  A module declaration which gives name and version for the purpose of
>> compile-time and runtime access control is _by definition_ a first-class
>> entity in the Java platform.
>>
>
> Sure, but so is MANIFEST.MF, which carries compile-time information
> (example, Main-Class), as well as signing information, which must be used
> by the runtime when a security manager is turned on.
>
>
>  Hence a module is declared via a Java language construct with syntax
>> similar to constructs which declare other entities (classes, interfaces).
>>
>
> And *even if* you think that this should result in changes to the
> recognized keywords in ".java" files, and an input file that uses a special
> ".java" name to carry said info, there's still no reason that the output
> has to be a .class file, after the darn thing is compiled.
>
> Those are all implementation choices. And from discussions we've had,
> there are many folks such as myself that think that those implementation
> choices come at an unnecessary cost. Different implementation choices might
> be better.
>
> -Eric.
>
>


-- 
Debasish Ray Chawdhuri
http://www.geekyarticles.com/
[A collection of advanced articles on java]