gmane.comp.java.openjdk.compiler.devel

ARM and repeating exceptions

Aleksey Shipilev — 2012-05-22T10:07:16

Hi,

There is some understandable, but still weird behavior in ARM. Should
the code cache or throw the same exception on some op(), and close(),
then ARM block will throw IllegalArgumentException. The minimal test
case is [1]. I think it can be fixed with simple fix in javac
desugaring scheme, placing additional check if exception from close()
is actually the original exception, and not trying to suppress it.

Thanks,
Aleksey.

[1]

import java.io.IOException;

public class ArmTest {

    // fails with IllegalArgumentException at Throwable.addSuppressed()
    public static void main(String[] args) {
        try (MyAutoCloseable worker = new MyAutoCloseable()) {
            worker.doWork();
        } catch (IOException e) {
            throw new IllegalStateException("Chained", e);
        }
    }

    private static class MyAutoCloseable implements AutoCloseable {
        private static final IOException EXCEPTION = new IOException();
        public void doWork() throws IOException { throw EXCEPTION; }
        public void close() throws IOException { throw EXCEPTION; }
    }
}

OpenJDK fails to compile hadoop 0.23.1

Radim Kolar — 2012-04-05T14:20:52

ponto:(crawler)/tmp/hadoop-common>java -version
openjdk version "1.6.0_30"
OpenJDK Runtime Environment (build 1.6.0_30-b24)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

fails with:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile 
(default-compile) on project hadoop-mapreduce-client-core: Compilation 
failure: Compilation failure:
[ERROR] 
/tmp/hadoop-common/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapred/Counters.java:[93,49] 
incompatible types; inferred type argument(s) 
org.apache.hadoop.mapreduce.Counter,java.lang.Object do not conform to 
bounds of type variable(s) C,G
[ERROR] found   : <C,G>java.lang.String
[ERROR] required: java.lang.String
[ERROR] 
/tmp/hadoop-common/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapred/Counters.java:[576,33] 
incompatible types; inferred type argument(s) 
org.apache.hadoop.mapreduce.Counter,java.lang.Object do not conform to 
bounds of type variable(s) C,G
[ERROR] found   : <C,G>java.lang.String
[ERROR] required: java.lang.String
[ERROR] 
/tmp/hadoop-common/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapred/Counters.java:[588,36] 
incompatible types; inferred type argument(s) 
org.apache.hadoop.mapreduce.Counter,java.lang.Object do not conform to 
bounds of type variable(s) C,G
[ERROR] found   : <C,G>org.apache.hadoop.mapred.Counters
[ERROR] required: org.apache.hadoop.mapred.Counters

replacing openjdk tools.jar with oracle java 6 tools.jar solved this 
problem  - hadoop compiles fine.

Questions on documentation and hacking javac

Thiago Silva — 2012-03-29T19:50:04

Hello,

not sure if this is the best place to ask this kind of help, I hope
someone can point me out in the right directions.

I'm looking for any form of documentation on detailed stages of the
compiler and its classes and overall structure, if such exists. For
example, docs on the structures, their relationships and detailed
stages notes. I've noticed the AST being constructed uses some Type
classes hierarchy and Symbols hierarchy, involving environment objects
and context objects (and Todos and tasks, and so on and so forth)....I
can make some sense of them, but hasn't been so easy to get a good
idea on how to make use of the available code and what are some of the
requirements to use them. If there is no such docs, then perhaps, a
few pointers.

Mostly, with quite ease, I've been able to change the parser, added a
few kinds of nodes to the ASTs and (with less confidence) I was able
to resolve the identifiers, types and method signature consistency on
my new syntax.

Now, the actual problem: I need to create callgraphs from any A.x() to
any B.y() given (supposedly, A and B are classes either existing on
the classpath or are inputs to the the current compilation and should
be present on the AST constructed). I've identified I should do this
before the Flow stage.

To build the callgraph, I certainly need to inspect method bodies
looking for calls, and I will encounter a number of C.z() in between
the graph whose class C were not passed as input to the compiler --
therefore I should look for them in the classpath. In other words, if
class A is an input to the compiler, I know I can inspect x's body
through the AST; but if its not, I don't know if the compiler has the
code in place to load the class and inspect the body of methods.

I know the compiler can load extra class files, as it must resolve the
types of identifiers and signatures of methods for variables and
invocations occurring on the code being compiled (definitions which
are not part of the current compilation units), but I can tell if
there is code in place to inspect the methods in .class files.
Unfortunately, I'm not very acquainted with what is at my disposal.

Thank you in advance for any pointers,
Thiago

Static import from default package ?

Ulf Zibis — 2012-03-28T15:59:08

Hi all,

is there any reason, why we can't import static from class in default package?

Example:
class A {
     static final type CONSTANT = 123;
     static final type method() {...};
}

import static A.*;
class B {
     static final type HERE = CONSTANT;
     static final type now() { return method(); };
}

Use case:
JDK's jtreg tests (based on default package).

Regards,

Ulf

Optimize bytecode for combination enhanced-for and enums

Roel Spilker — 2012-03-28T13:39:30

Hi all,

TL;DR: for (Edge edge : Edge.values()) copies an array every time it is
executed. This can be prevented. Is that a good idea and how to proceed
from here?

I'm new to this list, so please let me know if this is not the place to
post this.

When I was profiling our application I notices that we allocate quite some
memory when iterating over enum values. The pattern used was:

class  Foo {
  void bar() {
    for (Edge e : Edge.values()) {
      // do some work
    }
  }
}

The call to Edge.values() obviously creates a new clone of the Edge[]
containing all enum constants. So we've modified our code:

class  Foo {
  private static final Edge[] EDGES = Edge.values();

  void bar() {
    for (Edge e : EDGES) {
      // do some work
    }
  }
}

This solves our allocation problem, but it is not a nice solution. Since
code in the enhanced-for has no way to modify the array this pattern can be
done at compile-time. A synthetic inner class can be generated to keep the
copy of the array. The desugared (pseudo) code would then look something
like this:

/* syncthetic */ class Foo$0 {
  static final Edge[] EDGES = Edge.values();
}

class  Foo {
  void bar() {
    for (Edge e : Foo$0.EDGES) {
      // do some work
    }
  }
}

There is precedence for this kind of desugaring/optimization: When you use
an enum-in-switch, a synthetic class is generated containing an int array
for the ordinals.

I have a few questions:
- Do you think this is a good optimization? The trade-off here is creating
a copy every time the enhanced-for is used (could be in an inner loop)
versus the overhead of loading an extra class.
- Is there a better optimization possible/required? EnumSet
uses SharedSecrets.getJavaLangAccess().getEnumConstantsShared(elementType),
but that won't work in user code.
- If it is a good idea, how do I proceed from here? Possibly create a JEP?
How can I contribute? Who wants to support?

Roel Spilker

Result: New Compiler Group Member: Dan Smith

Jonathan Gibbons — 2012-03-26T10:18:43

|The vote for*Dan Smith*  [1] is now closed.

Yes:*6*
Veto: 0
Abstain:*0*

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

*Jon Gibbons*

[1]|http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004145.html

Result: New Compiler Group Member: Brian Goetz

Jonathan Gibbons — 2012-03-26T10:16:53

|The vote for*Brian Goetz*  [1] is now closed.

Yes:*6*
Veto: 0
Abstain:*0*

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

*Jon Gibbons*

[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2012-March/004144.html|

Initial proof of concept for implementation of -Xlint:hiddenclass

Fredrik Öhrström — 2012-03-16T12:12:10

Although legal, the use of multiple top level classes in the same file
is somewhat questionable to begin with, but it is particularly bad when
in some package class A in A.java refers to class B defined in C.java. 
This requires that at times the files must be compiled together, and
prevents implicit compilation from locating such "hidden classes".

Proof of concept impl:
http://cr.openjdk.java.net/~ohrstrom/webrev-7153951-v1/

It seems to detect the problem correctly. And there are a few of these
in the jdk, it seems, ~100.

How to do isSameFile test properly?
How to report each hidden class reference only once?
Are line numbers neccesary?
Where to put checkForHiddenAccess?
Does it cover all possible use cases?
What else did I miss?

//Fredrik

Draft specification of repeating annotations language changes

Joe Darcy — 2012-03-11T22:19:21

Hello,

Work has commenced on the repeating annotations feature discussed in JEP 
120:

     JEP 120: Repeating Annotations
     http://openjdk.java.net/jeps/120

First, the meta-annotation type used to declare the containing 
annotation has been added to java.lang.annotation:

     7151008: Add library support for repeating annotations in 
java.lang.annotation
     http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99b91217370d

Updates to the AnnotatedElement interface will be made later.

Next, with feedback from other members of the compiler team, I've 
written a draft specification of the needed language changes:

Updates to JLS 9.6

If annotation type T is annotated with an annotation a of type 
ContainerAnnotation then:

The value of the < at >ContainerAnnotation annotation is called the 
containing annotation type TC.

TC must declare a value() method whose return type is T[], or a 
compile-time error occurs.

(This implies that TC can be the containing annotation type for only a 
single annotation type.)

[Note: Since an annotation type T cannot declare a method that returns T 
or T[] as a value, that implies that it is a compile time error for an 
annotation type to specify itself as a container annotation type.]

TC may declare methods other than value(). Any such method must have a 
default clause, or a compile-time errors occurs.

[Note: this is a bit weird "action at a distance" in terms of compiler 
errors   The error message here is given at the site of the T since the 
containing annotation might only be present as a class file.]

It is a compile time error if the retention of T is not a subset of the 
retention of TC.  This comparison is made taking default retention into 
consideration.

    In more detail, if the retention of the TC is SOURCE, the retention 
of T must be SOURCE.
    If the retention of TC is CLASS, the retention of the T may be 
either CLASS or SOURCE.
   if the retention of the TC is RUNTIME, the retention of the T may be 
SOURCE, CLASS, or RUNTIME.

It is a compile time error if T is < at >Documented and TC is not < at >Documented.

[Note that it is permissible TC to be < at >Documented and for T to *not* be 
< at >Documented.]

It is a compile time error if T is < at >Inherited and TC is not < at >Inherited.

[Note that it is permissible TC to be < at >Inherited and for T to *not* be 
< at >Inherited.]

It is a compile time error if T has target values that are not included 
in the target set of TC, taking default target values into account.

Note that an annotation type TC may be a container type for annotation 
type T while also having its own container type TCC.

[However, two annotation types cannot be containers for each other 
because that would create an illegal cyclic annotation type situation.  
For example, the following program is rejected by javac:

public < at >interface Mutual {
     Omaha[] value() default {};
}

< at >interface Omaha {
     Mutual[] value() default {};
}

< at >Mutual({< at >Omaha, < at >Omaha})
< at >Omaha({< at >Mutual, < at >Mutual})
class Foo {
}

with the message

Mutual.java:2: error: cyclic annotation element type
     Omaha[] value() default {};
             ^
1 error ]

Updates to JLS 9.7

"It is a compile-time error if a declaration is annotated with more than 
one annotation for a given annotation type."

Change to "unless the annotation type is annotated with an 
< at >ContainerAnnotation."

Annotation types with an < at >ContainerAnnotation are known as repeatable 
annotation types.  The presence of an < at >ContainerAnnotation indicates 
multiple annotations of that annotation type will be logically replaced 
with a single annotation synthesized by the compiler.  The type of the 
synthesized annotation, TC, is the type given by the value of the 
ContainerAnnotation annotation on T. The order of the elements of the 
value() method of the synthesized TC annotation matches the left to 
right order of the base repeatable annotations.

If an element only has a single repeatable annotation, the annotation is 
not replaced.

It is conventional to place the repeatable annotations of a given type 
contiguously on an element, but this is not required.

It is a compile time error if an element is annotated with both multiple 
base annotations of a repeatable annotation type T and one or more 
annotations of the containing type TC.

[In other words, the collapsing of repeatable annotations to their 
containers is *not* recursive.]

Cheers,

-Joe

CFV: New Compiler Group Member: Brian Goetz

Jonathan Gibbons — 2012-03-10T18:53:57

|I hereby nominate Brian Goetz to Membership in the Compiler Group.
|
Brian Goetz is Java Language Architect at Oracle and Specification Lead
for JSR-335, Lambda Expressions for the Java (TM) Programming Language.
Brian needs no introduction to the Java community, having brought us
zillions of articles on Java development as well as the best-selling
book"Java Concurrency in Practice". He was part of the JSR-166 Expert
Group that brought us java.util.concurrent, and has racked up more
JavaOne Rock Star awards than almost anyone else.
|

Votes are due by the end of March 24.

Only current Members of the Compiler Group [1] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [2].

CFV: New Compiler Group Member: Dan Smith

Jonathan Gibbons — 2012-03-10T18:53:59

|I hereby nominate Dan Smith to Membership in the Compiler Group.
|
Dan has been working closely on Compiler Group projects since
joining Oracle in November 2010.  He has been heavily involved
in design, specification, and JCP work for Lambda, and also
participated in discussions about Coin; he often analyzes bugs
and participates in code reviews for JDK 8 (and formerly JDK 7).
Previously, he received a PhD studying compilers, programming
languages, and type systems at Rice University.

|
Votes are due by the end of March 24.

Only current Members of the Compiler Group [1] are eligible
to vote on this nomination.

For Lazy Consensus voting instructions, see [2].

Code review request: 7151580 - Separate DA/DU logic from exceptionchecking logic in Flow.java

Maurizio Cimadamore — 2012-03-09T11:00:07

Hi,
this is a biggie changeset [1] for separating the definite assignment 
logic from the exception analysis logic in Flow.java. The two logic used 
to share the same visitor - moving forward it would be nice to split the 
two routines in two separate visitors as there are use cases in which we 
might only need to run one of the two (i.e. when inferring thrown types 
of a lambda).

The inspiration for this work came from the BGGA prototype which 
featured a similar refactoring. I have added my own little twist to the 
code - for example, both visitors are nested classes inside Flow - they 
also share a common super class that contains shared routine for 
handling jumps.

[1] - http://cr.openjdk.java.net/~mcimadamore/7151580.0/webrev/ 
<http://cr.openjdk.java.net/%7Emcimadamore/7151580.0/webrev/>

Maurizio

hg: jdk8/tl/langtools: 7150579: Moved ant code into a separatepackage, anttasks.

2012-03-07T12:12:16

Changeset: 7245999a0075
Author:    ohrstrom
Date:      2012-03-07 13:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7245999a0075

7150579: Moved ant code into a separate package, anttasks.
Summary: To allow langtools to be built without ant, the ant tasks were moved to a separated package. The packages were also renamed to proper lower case package names.
Reviewed-by: jjg

! make/build.xml
! make/netbeans/langtools/build.xml
- make/tools/CompileProperties/CompileProperties.java
- make/tools/CompileProperties/CompilePropertiesTask.java
- make/tools/GenStubs/GenStubs.java
- make/tools/SelectTool/SelectToolTask.java
+ make/tools/anttasks/CompilePropertiesTask.java
+ make/tools/anttasks/GenStubsTask.java
+ make/tools/anttasks/SelectToolTask.java
+ make/tools/compileproperties/CompileProperties.java
+ make/tools/genstubs/GenStubs.java

RFR (XXS): 77150579: build-infra merge: Langtools, move ant dependencyinto separate package.

Fredrik Öhrström — 2012-03-05T13:18:20

Hi,

the dependency on ant for the langtools repo, encoded into the build
tools CompilePropertiesTask and GenStubs,
can be separated into a separate package.

This enables build-infra makefiles to compile langtools without the
ant.jar simply by avoiding the ant specific package.
Ant can of course still be used to build langtools.

WEBREV:
http://cr.openjdk.java.net/~ohrstrom/webrev-7150579-v1/

TESTING:
Builds fine using ant, even when genstubs is tricked to actually be used, which it normally is not.

Feedback welcome!

//Fredrik

Apparent generics compilation bug new to Java 1.7

Benedict Elliott Smith — 2012-02-23T14:08:03

Hi,

The below class no longer compiles (1.7.02); I can't see any good reason
for it not to, and nor can ecj or the 1.6 JDK, so I think it is quite
probably a bug. Could you confirm I'm not just being an idiot, and I'll
file a bug report? I had a poke around the bug tracker to see if it has
already been filed, but I can't say with confidence it hasn't been.

public class TypeTest {
 static abstract class A<K, V, I extends B<K, V>, I2 extends B<V, K>> {
 abstract A<V, K, I2, I> test();
 }
 static class B<K, V> {
 }
}

javac output is:

TypeTest.java:7: error: type argument I2 is not within bounds of
type-variable I
                abstract A<V, K, I2, I> test();
                                 ^
  where I2,V,K,I are type-variables:
    I2 extends B<V,K> declared in class A
    V extends Object declared in class A
    K extends Object declared in class A
    I extends B<K,V> declared in class A
1 error

JEP 139: Enhance javac to Improve Build Speed

2012-02-21T22:11:27

Posted: http://openjdk.java.net/jeps/139

- Mark

Weird usage of Java Generics compiles correctly with JDT (and coderuns) but does not compile with Oracle's Java6 compiler

Danilo Tommasina — 2012-02-21T12:43:39

|Hello,

please look at the following code:

public  class  MyWeirdClass  {

     public  void  entryPoint()  {
         doSomethingWeird();
     }

     < at >SuppressWarnings(  "unchecked"  )
     private  <Textends  A&  B>  T getMyClass()  {
         if  (  System.currentTimeMillis()  %  2  ==  0  )  {
            return  (T)  new  MyClass_1();
         }  else  {
            return  (T)  new  MyClass_2();
         }
     }

     private  <Textends  A&  B>  void  doSomethingWeird()  {
         T obj=  getMyClass();

         obj.methodFromA();
         obj.methodFromB();
     }

     static  interface A{
         void  methodFromA();
     }

     static  interface B{
         void  methodFromB();
     }

     static  class  MyClass_1  implements  A,  B{
         public  void  methodFromA()  {};
         public  void  methodFromB()  {};
     }

     static  class  MyClass_2  implements  A,  B{
         public  void  methodFromA()  {};
         public  void  methodFromB()  {};
     }
}


This code compiles correctly using the eclipse JDT compiler, however generates errors using the Oracle's JDK (Java 6) compiler.
The problem is that the method||entryPoint()|  calls|method doSomethingWeird()|  which will try to infer a type that cannot be uniquely identified resp. in this case does not even physically exist.
(I know it may be possible to define an interface AB extends A,B but this is not the question ;) )
  
My question is: Is this case defined in the JSL, resp. will it be supported in future releases of OpenJDK's / Oracle's JDK compilers?
Thanks in advance for any comment.

Kind Regards
Danilo Tommasina

javac lexer parser rewrite

2012-02-07T09:57:30

Hello

Javac scanner and parser now are handwritten. The code, especially in parser is quite messy and
hard to read and modify.
It is possible to rewrite lexer and parser using some kind of java parser generator.
It would improve readability and allows for easier modifications.

There is a project 'compiler grammar' (which seems dormant). Java lexer and parser were rewritten
using antlr. But antrl generated parsers are very slow.

Many lexer and parser generators exists which are able to process 'classic' regular expressions for lexer or
context free grammars for parser and produce fast code (ie. jflex, beaver, jikes parser generator and more)

What do you think about it? Is there a need for such thing? Is it worth the effort?

Regards
Leszek Piotrowicz

javac pretty printer probable bugs

Crazy Java — 2012-01-29T12:40:29

Hi,


as part of the javac AST Visualizer project, I have some difficulties with
javac's pretty printer. The problem is the fact, that I am doing double
compilation (after first compilation I get the textual representation of
produced AST and that is in fact used for visualization purposes). Double
compilation is needed because I want to visualize all the compiler sugar
(default constructor, effectively final variables in ARM, code generated
for enum, ...).

The problem is that javac's pretty printer (I guess it is pretty printer)
after calling CompilationUnitTree.toString() produces in some specific
situations code that is not able to compile:

1.) it transforms
public class FullClassUsage {
    {
        new <Object> ArrayList<String>(10) {
            {
                add("123");
            }
        };
    }
}
into
public class FullClassUsage {

    public FullClassUsage() {
        super();
    }
    {
        new <Object>ArrayList<String>(10){

            (int x0) {
                super(x0);
            }
            {
                add("123");
            }
        };
    }
}
the (int x0) is the problem.

2.) when using together with enum types it transforms:
public enum SimpleEnum {
    ENUM_CONSTANT_1,
    ENUM_CONSTANT_2
}
into
public enum SimpleEnum {
    /*public static final*/ ENUM_CONSTANT_1 /* = new SimpleEnum() */,
    /*public static final*/ ENUM_CONSTANT_2 /* = new SimpleEnum() */;

    private SimpleEnum() {
        super();
    }
}
that is really weird. Not only it generates comments ??? but also a super
call causing the code not to compile. I would also assume that it will
generate all the enum type code (constructors with n+2 arguments, valueOf()
factory method, extending java.lang.Enum, ...).

Is there any reason why it produces that weird code?
Is there any better way to get the Textual representation of
CompilationUnitTree (using pretty printer) that will compile in both of
these examples ?


//Martin

javac AST Visualizer on NetBeans Platform

Crazy Java — 2012-01-21T15:39:09

Hi,


I just finished my first NetBeans platform application. It visualizes
javac's AST from given java source file.

Maybe some of you might be interested in or provide feedback... I wrote an
article about it on my blog <http://crazyjavahacking.com/>.


Cheers

Generics compilation failure casting List toList under Java 7

Andrew Phillips — 2011-12-31T15:17:21

Hi all

During some recent work to get jclouds to compile under Java 7 I came  
across a generics compilation failure that can be reproduced using the  
following sample code:

classGenericCompilationFailureDemo{
     List<?extendsGenericCompilationFailureDemo>newList(){
         returnnewArrayList<GenericCompilationFailureDemo>();
     };

     voiduseList(){
         List<GenericCompilationFailureDemo>list =
             (List<GenericCompilationFailureDemo>)newList();
     }

     List<?extendsSet<GenericCompilationFailureDemo>>newListOfSpecificSets(){
         returnnewArrayList<Set<GenericCompilationFailureDemo>>();
     };

     voiduseListOfSpecificSets(){
         List<Set<GenericCompilationFailureDemo>>listOfSpecificSets =
             (List<Set<GenericCompilationFailureDemo>>)newListOfSpecificSets();
     }

     List<?extendsSet<?extendsGenericCompilationFailureDemo>>newListOfSets(){
         returnnewArrayList<Set<?extendsGenericCompilationFailureDemo>>();
     };

     voiduseListOfSet(){
         List<Set<?extendsGenericCompilationFailureDemo>>listOfSets =
             (List<Set<?extendsGenericCompilationFailureDemo>>)newListOfSets();
     }
}


This passes under Sun JDK 1.6.0_20 and _24 but fails under Oracle JDK  
1.7.0 and _01 with:

[ERROR]src\main\java\GenericCompilationFailureDemo.java:[56,78]error:inconvertible  
types

The comments and tentative answer to my resulting StackOverflow question

http://stackoverflow.com/questions/8637937/why-does-a-generic-cast-of-a-list-extends-set-to-listset-succeed-on-sun

seem to suggest that this is a compiler bug. We found a simple  
workaround, by the way: do the cast in a separate method (see  
https://github.com/jclouds/jclouds/commit/1ba75f623f03908d87c2fddce46e276098f3db40).

Any comments or suggestion much appreciated! And a belated Merry  
Christmas and Happy New Year, of course ;-)

Regards


Andrew