Small question about Dependence.Modifier.SYNTHETIC

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

Small question about Dependence.Modifier.SYNTHETIC

Alexey Fedorov
Hello!

I am playing with Jigsaw and met the following strange behavior. As I
understand, java.lang.module.Dependence.Modifier.SYNTHETIC was created
in modular JDK for underlining that the corresponding dependency was
added by the system, not by user. Consider the following code example:


/module-info.java:/

module my.module @ 1.0 {
     class mypackage.MyClass;
}


/MyClass.java:/

package mypackage;

public class MyClass  {

     public static void main(String[] args) throws IOException {
         ModuleInfo moduleInfo = MyClass.class.getModule().getModuleInfo();
         for (ViewDependence viewDependence :
moduleInfo.requiresModules()) {
             System.out.println(viewDependence);
         }
     }

}


In the middle of January output was:

>>  requires*synthetic*jdk@=8-ea


But actual output is:

>>  requires jdk@=8-ea



Here dependency "jdk@=8-ea" is not marked as*synthetic*. Is it an expected behavior or regression?


--
Thank you,
Alexey

Reply | Threaded
Open this post in threaded view
|

Re: Small question about Dependence.Modifier.SYNTHETIC

Jonathan Gibbons
There are two flags, ACC_SYNTHETIC and ACC_SYNTHESIZED.  According to
the latest spec, you should be getting ACC_SYNTHESIZED.   But, that
change may not have made it to the main repos yet.

-- Jon

On 02/06/2012 09:27 AM, Alexey Fedorov wrote:

> Hello!
>
> I am playing with Jigsaw and met the following strange behavior. As I
> understand, java.lang.module.Dependence.Modifier.SYNTHETIC was created
> in modular JDK for underlining that the corresponding dependency was
> added by the system, not by user. Consider the following code example:
>
>
> /module-info.java:/
>
> module my.module @ 1.0 {
>     class mypackage.MyClass;
> }
>
>
> /MyClass.java:/
>
> package mypackage;
>
> public class MyClass  {
>
>     public static void main(String[] args) throws IOException {
>         ModuleInfo moduleInfo =
> MyClass.class.getModule().getModuleInfo();
>         for (ViewDependence viewDependence :
> moduleInfo.requiresModules()) {
>             System.out.println(viewDependence);
>         }
>     }
>
> }
>
>
> In the middle of January output was:
>
>>>  requires*synthetic*jdk@=8-ea
>
>
> But actual output is:
>
>>>  requires jdk@=8-ea
>
>
>
> Here dependency "jdk@=8-ea" is not marked as*synthetic*. Is it an
> expected behavior or regression?
>
>
> --
> Thank you,
> Alexey
>

Reply | Threaded
Open this post in threaded view
|

Re: Small question about Dependence.Modifier.SYNTHETIC

Alex Buckley
On 2/6/2012 9:40 AM, Jonathan Gibbons wrote:
> There are two flags, ACC_SYNTHETIC and ACC_SYNTHESIZED. According to the
> latest spec, you should be getting ACC_SYNTHESIZED. But, that change may
> not have made it to the main repos yet.

Good time to explain these modifiers.

Historically, too many class file artifacts have been marked synthetic,
and thus hidden from reflection, when in fact they represent "user-land"
constructs which the Java SE specification (notably the Java Language
Spec) defines as present in classes.

The canonical example is Enum.values(), which is mandated by the JLS to
exist in enum types as a completely ordinary method. It can only be
generated by a compiler but it should not be marked synthetic because it
is not javac-specific and must be exposed via reflection.

So, the Java team has been aware for some time of the need to
distinguish "synthesized" content (compiler-generated but user-visible
and in some sense "standardized") from "synthetic" content
(compiler-generated but invisible and implementation-specific). In
neither case does the content map to constructs that were physically
present in source. Synthesized content maps to constructs that were
logically present in source.

The Jigsaw class file structures are the first to introduce a
first-class ACC_SYNTHESIZED flag to complement ACC_SYNTHETIC, but I
expect other structures will adopt it over time. The JVM Spec will say
something like:

- If an entity has the synthetic flag, then the entity represents a
source-level artifact that is specific to the implementation of the host
system which generated the class file. The entity may not exist in all
class files generated from the same source code, and should not appear
in language-level models of reflection.

- If an entity has the synthesized flag, then the entity represents a
source-level artifact that is defined by the Java SE platform despite
not appearing in source code. The entity is not specific to the
implementation of the host system which generated the class file. The
entity must exist in all class files generated from the same code, and
should appear in language-level models of reflection.

To clarify,
http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html#jigsaw-1.2 
ought to mandate a _synthesized_ dependency:

"If a module declaration does not express a dependency on the java.base
module, and the module declaration is not of java.base itself, then the
module declaration automatically has a _synthesized_ dependency on a
version of the java.base module chosen by the host system."

Alex