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; }

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.mapreduc

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 cre

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

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:

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 corre

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);

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(){