javac: "legacy" mode

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

javac: "legacy" mode

Jonathan Gibbons
Until recently, javac implicitly supported "legacy" compilations
(meaning compilations that were valid in JDK 7 or earlier). This was as
side-effect by design of "single-module mode", because the default
requires if none was given was "jdk@8-ea".

Now, we have changed the default requires to "java.base@>=8".  This
means that without any other changes, a legacy compilation referencing
non-base classes will fail to compile.

There are two possible solutions.

1. Have javac support -Xmode:legacy, which would change the default
requires. It would also require everyone to change the way they use
javac for legacy compilations.

2. Distinguish between the case of no module compilation units in a
compilation and module compilation units involved, but not containing
any requires on the base module.  If no module compilation unit is
observable, one would be synthesized containing "requires jdk;" or some
equivalent.   If any observable module compilation unit does not contain
a requires for the platform base, then a "requires java.base>=N;" will
be generated, with an appropriate value of N, per the spec.

-- Jon

Reply | Threaded
Open this post in threaded view
|

Re: javac: "legacy" mode

Peter Jensen
On 01/27/12 13:37, Jonathan Gibbons wrote:

> Until recently, javac implicitly supported "legacy" compilations
> (meaning compilations that were valid in JDK 7 or earlier). This was
> as side-effect by design of "single-module mode", because the default
> requires if none was given was "jdk@8-ea".
>
> Now, we have changed the default requires to "java.base@>=8".  This
> means that without any other changes, a legacy compilation referencing
> non-base classes will fail to compile.
>
> There are two possible solutions.
>
> 1. Have javac support -Xmode:legacy, which would change the default
> requires. It would also require everyone to change the way they use
> javac for legacy compilations.

That pretty much seems like a no-go, for legacy tooling.

>
> 2. Distinguish between the case of no module compilation units in a
> compilation and module compilation units involved, but not containing
> any requires on the base module.  If no module compilation unit is
> observable, one would be synthesized containing "requires jdk;" or
> some equivalent.   If any observable module compilation unit does not
> contain a requires for the platform base, then a "requires
> java.base>=N;" will be generated, with an appropriate value of N, per
> the spec.
What happens if I have some classes, compiled in legacy mode, and I want
to mix them into a module?
Example: I may not have the source files, but I really want to reuse
these classes.


>
> -- Jon
>

Reply | Threaded
Open this post in threaded view
|

Re: javac: "legacy" mode

Mandy Chung
In reply to this post by Jonathan Gibbons
On 1/27/2012 1:37 PM, Jonathan Gibbons wrote:

> Until recently, javac implicitly supported "legacy" compilations
> (meaning compilations that were valid in JDK 7 or earlier). This was
> as side-effect by design of "single-module mode", because the default
> requires if none was given was "jdk@8-ea".
>
> Now, we have changed the default requires to "java.base@>=8".  This
> means that without any other changes, a legacy compilation referencing
> non-base classes will fail to compile.
>
> There are two possible solutions.
>
> 1. Have javac support -Xmode:legacy, which would change the default
> requires. It would also require everyone to change the way they use
> javac for legacy compilations.
>

This seems a major compatibility concern but it might worth taking the
migration story into account.   What if javac -source 7 -target 7 uses
the entire "jdk" as the default and keep "java.base" as the default for
-source 8 -target 8 (possibly provide a switch to say using the entire
"jdk" rather than just the base)?   I'm in two minds and I think it
deserves some more thought.

> 2. Distinguish between the case of no module compilation units in a
> compilation and module compilation units involved, but not containing
> any requires on the base module.  If no module compilation unit is
> observable, one would be synthesized containing "requires jdk;" or
> some equivalent.   If any observable module compilation unit does not
> contain a requires for the platform base, then a "requires
> java.base>=N;" will be generated, with an appropriate value of N, per
> the spec.

I did some work to support legacy mode in runtime some time ago [1].  I
have re-based it with the latest jigsaw forest.   It's just a good
timing and discuss how legacy mode should work in runtime/compile-time.  
I should restart this work soon.

Mandy
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001061.html

Reply | Threaded
Open this post in threaded view
|

Re: javac: "legacy" mode

Ekaterina Pavlova
On 1/27/12 5:28 PM, Mandy Chung wrote:

> On 1/27/2012 1:37 PM, Jonathan Gibbons wrote:
>> Until recently, javac implicitly supported "legacy" compilations (meaning compilations that were valid in JDK 7 or earlier). This was as side-effect by design of
>> "single-module mode", because the default requires if none was given was "jdk@8-ea".
>>
>> Now, we have changed the default requires to "java.base@>=8". This means that without any other changes, a legacy compilation referencing non-base classes will fail to
>> compile.
>>
>> There are two possible solutions.
>>
>> 1. Have javac support -Xmode:legacy, which would change the default requires. It would also require everyone to change the way they use javac for legacy compilations.
>>
>
> This seems a major compatibility concern but it might worth taking the migration story into account. What if javac
> -source 7 -target 7 uses the entire "jdk" as the default
> and keep "java.base" as the default for -source 8 -target 8 (possibly provide a switch to say using the entire "jdk"
> rather than just the base)? I'm in two minds and I
> think it deserves some more thought.

Perhaps introduce something like -Xmode:module and keep legacy mode as default one
is more safe as the compatibility will not be broken.
Later defaults can be changed.

-katya
Reply | Threaded
Open this post in threaded view
|

Re: javac: "legacy" mode

Jonathan Gibbons
On 01/27/2012 09:49 PM, Ekaterina Pavlova wrote:

> On 1/27/12 5:28 PM, Mandy Chung wrote:
>> On 1/27/2012 1:37 PM, Jonathan Gibbons wrote:
>>> Until recently, javac implicitly supported "legacy" compilations
>>> (meaning compilations that were valid in JDK 7 or earlier). This was
>>> as side-effect by design of
>>> "single-module mode", because the default requires if none was given
>>> was "jdk@8-ea".
>>>
>>> Now, we have changed the default requires to "java.base@>=8". This
>>> means that without any other changes, a legacy compilation
>>> referencing non-base classes will fail to
>>> compile.
>>>
>>> There are two possible solutions.
>>>
>>> 1. Have javac support -Xmode:legacy, which would change the default
>>> requires. It would also require everyone to change the way they use
>>> javac for legacy compilations.
>>>
>>
>> This seems a major compatibility concern but it might worth taking
>> the migration story into account. What if javac
>> -source 7 -target 7 uses the entire "jdk" as the default
>> and keep "java.base" as the default for -source 8 -target 8 (possibly
>> provide a switch to say using the entire "jdk"
>> rather than just the base)? I'm in two minds and I
>> think it deserves some more thought.
>
> Perhaps introduce something like -Xmode:module and keep legacy mode as
> default one
> is more safe as the compatibility will not be broken.
> Later defaults can be changed.
>
> -katya

I think it is more helpful to have javac just "do the right thing".  
There are three recognizable types of compilation for javac, roughly
corresponding to 0, 1, many module-info files in the compilation.

legacy mode:
     no module-path option, no module-info to be compiled or on classpath
     source hierarchy is organized by packages, as now
     output dir will be organized by packages, as now

single module mode:
     class path set, or module path not set
     source hierarchy is organized by packages, as now
     output dir will be organized by packages, as now

multi-module mode
     module path set but not class path.
     source hierarchy must be organized by modules.
     output dir will be organized by modules

The presumption is that in legacy mode, you should have access to all
JDK classes.  In either module mode, unless you specify otherwise, a
module will only have access to the classes in the java.base module.

I also think we should add to -verbose, so that javac can be more
informative about the type of compilation it is doing

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: javac: "legacy" mode

Alan Bateman
On 28/01/2012 16:37, Jonathan Gibbons wrote:

> :
> I think it is more helpful to have javac just "do the right thing".  
> There are three recognizable types of compilation for javac, roughly
> corresponding to 0, 1, many module-info files in the compilation.
>
> legacy mode:
>     no module-path option, no module-info to be compiled or on classpath
>     source hierarchy is organized by packages, as now
>     output dir will be organized by packages, as now
>
> single module mode:
>     class path set, or module path not set
>     source hierarchy is organized by packages, as now
>     output dir will be organized by packages, as now
>
> multi-module mode
>     module path set but not class path.
>     source hierarchy must be organized by modules.
>     output dir will be organized by modules
>
> The presumption is that in legacy mode, you should have access to all
> JDK classes.  In either module mode, unless you specify otherwise, a
> module will only have access to the classes in the java.base module.
>
> I also think we should add to -verbose, so that javac can be more
> informative about the type of compilation it is doing
>
> -- Jon
Joining this thread a bit late but I think it is the case that javac has
to do the right thing. There would be a bounty on your head if the world
had to change their command-lines to compile existing code the way it
has always compiled. So if there isn't any module compilation units then
would it mean that jdk@8 (as opposed to jdk.base@8 when compiling in any
module mode) would be required?

-Alan.