gmane.comp.java.openjdk.compiler.devel

Re: Annotation cycles

Roel Spilker — 2012-04-19T22:30:39

Yes, our proposal and implementation also supports

< at >interface A {
  Annotation[] value();
}

The implementation is pretty simple and you can already test it in java7 if
you use the jar from the page I sent.

The two main pieces of code were:
- The cycle-checking. Previously only the return type of the annotation
methods needed to be checked. Now also the default values
- The runtime proxy code became a bit more involved.

Regarding the cycles in the annotations: as long as you don't depend on
default values inside default values, you're in the clear. In other words,
you could break the cycle by providing an explicit value instead. This can
be checked compile-time.

Roel

On Tue, Apr 17, 2012 at 5:59 PM, David M. Lloyd <david.lloyd-H+wXaHxf7aLQT0dZR+AlfA< at >public.gmane.org>wrote:

Re: Annotation cycles

Bruce Chapman — 2012-04-18T10:26:35

Not so much "unstable equilibrium" as "immature atrophy".

There are several needs and use cases where the current specification 
forces you down such an ugly torturous design path that it is really 
better to not go there. The ones that pain me have relatively simple 
solutions which I don't think could be considered destabilising.

I suspect that the real problem is that these various requested 
improvements to the annotation feature are language changes but each in 
and of themselves is so seemingly minor that it doesn't appear to 
justify the hoop jumping required.

Maybe we need a JEP (or preJEP collaboration) to gather these use cases 
and investigate language changes that can address the majority of these 
pain points.

Bruce


On 18/04/2012 2:39 p.m., Brian Goetz wrote:

Re: Annotation cycles (was: repeating annotations)

Joel Borggrén-Franck — 2012-04-18T07:20:40

On 17 apr 2012, at 14:59, Jesse Glick wrote:


I suspect this change would be quite intrusive in implementation (while perhaps small in specification). The implementation of the current scheme for repeating annotations is both small and rather non-intrusive. Your proposition might (or might not) be a desirable feature, but it isn't an easy fix while doing repeating annotations.

cheers
/Joel

Re: Annotation cycles

Debasish Ray Chawdhuri — 2012-04-18T04:02:04

I am sorry but I saw neither community nor argument in this topic. Although
it appears that allowing annotation inheritance or all annotations would
not help, but it was not actually discussed in the community why such
feature is desirable. I think we should wait for the original proposers to
come up with some reason why  they think its important or desirable.

In  my opinion, people are thinking about the extensibility of XML and want
to have that in annotations too ramped up with java's features. Say for
example in some API, < at >Persistent  is an annotation that has a mandatory to
mentions the type as to whether its PersistentType.TABLE or
PersistentType.FILE. A subtype annotation < at >TablePersistent may override (so
to speak) the type() method to default to TABLE, (or may be we can have a
syntax to make it fixed to TABLE so that it cannot be specified anymore. ).
An API that only understands the < at >Persistent annotation can now
automatically use the < at >TablePersistent without any change. This is a simple
example, i

Re: Annotation cycles

Brian Goetz — 2012-04-18T02:39:53

Clearly the community is making a compelling argument that the current 
feature set is in an unstable equilibrium, and adding any more features 
would topple the balance...

On 4/17/2012 12:24 PM, Jonathan Gibbons wrote:

Re: Annotation cycles

Jonathan Gibbons — 2012-04-17T16:24:40

Creeping featurism, guys!

Re: Annotation cycles

David M. Lloyd — 2012-04-17T15:59:50

Arrays too?

On 04/17/2012 10:42 AM, Roel Spilker wrote:

Re: Annotation cycles (was: repeating annotations)

Roel Spilker — 2012-04-17T15:42:32

And while you're at it, we have another proposal ready to be pushed
allowing any annotation to be the result of an annotation method:

< at >interface A {
  Annotation value();
}

See  http://projectlombok.org/anyannotation/

The required changes to both specs and implementation are very small. All
the work has bene done already, albeit based on the jdk7 source. the only
things missing are a JEP, TCK and updating it to the current state of JDK8.

Roel

On Tue, Apr 17, 2012 at 2:59 PM, Jesse Glick <jesse.glick-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Annotation cycles (was: repeating annotations)

Jesse Glick — 2012-04-17T12:59:13

So long as you are changing the language spec for annotations, why not fix this longstanding irritation too (#6264216), which arbitrarily prevents a rather wide range of 
use cases for annotations? For example, move the cycle check from declaration time to use time, so that the only rejected constructs would be genuinely nonterminating 
cycles that no one would ever intentionally write:

< at >interface A {
   B[] bs() default {< at >B};
}
< at >interface B {
  A as() default {< at >A};
}
< at >A class X {} // oops

but so that legitimate cases compile:

< at >interface A {
   B[] bs() default {};
}
< at >interface B {
   A[] as() default {};
}
< at >A(< at >B(< at >A)) class X {} // fine

Re: OpenJDK fails to compile hadoop 0.23.1

Maurizio Cimadamore — 2012-04-16T20:28:49

Yep - this is same issue as the one I was mentioning:

http://bugs.sun.com/view_bug.do?bug_id=6650759

The fix that caused this was attempted in the JDK 7 repo - I then 
updated it with the help of Alex as this area required a bit of a JLS 
cleanup, as it was the JLS that was mandating this particular failure. 
That's why the code in JDK 7 works correctly, as it take advantage of 
the new spec goodies. As for JDK 6 (closed) the 'fix' was simply not 
there and the old compiler behavior was more powerful than the one 
described in the spec, which allowed this kind of examples to compile.

Maurizio

Re: OpenJDK fails to compile hadoop 0.23.1

Radim Kolar — 2012-04-05T15:31:54

here is code fragment:

https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/611284

it seems to be widely known bug, its mentioned in hadoop wiki too.

Re: OpenJDK fails to compile hadoop 0.23.1

Maurizio Cimadamore — 2012-04-05T15:14:12

I think this might be cause by an inference bug [1] that got picked up 
from an early JDK 7 version (as OpenJDK 6 is a 'child' of OpenJDK 7). It 
would be great if you could paste it a code snippet that recreates the 
problem.

Thanks
Maurizio

[1] - http://bugs.sun.com/view_bug.do?bug_id=6650759

Re: OpenJDK fails to compile hadoop 0.23.1

Radim Kolar — 2012-04-05T15:02:29

Dne 5.4.2012 16:25, Maurizio Cimadamore napsal(a):
openjdk7u2 works

Re: OpenJDK fails to compile hadoop 0.23.1

Maurizio Cimadamore — 2012-04-05T14:25:23

Have you tried with OpenJDK 7/8 ?

Maurizio

On 05/04/12 15:20, Radim Kolar wrote:

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

Re: Questions on documentation and hacking javac

Jonathan Gibbons — 2012-03-29T21:12:55

The compiler does not need to load the Code attribute of methods
for classes that have already been compiled, and provides no support
for doing so.

If you want to look at .class files, I suggest you use a library such
as asm to do so.

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

Re: Static import from default package ?

Ulf Zibis — 2012-03-28T20:34:46

Much thanks Dan,

-Ulf

Am 28.03.2012 21:38, schrieb Dan Smith:

Re: Optimize bytecode for combination enhanced-for and enums

Dan Smith — 2012-03-28T19:54:45


Might as well generate that method in the enum class itself (and specify it appropriately -- JLS 8.9.2):

class Edge extends Enum<Edge> {
  static E[] values() { ... }
  static Iterable<E> valuesIterable() { ... }
  static E valueOf(String s) { ... }
}

Then the only use-site optimization is for the compiler to turn Edge.values into Edge.valuesIterable, knowing that both will have the same effect in this code.

It would be nice if there were a better name, so that users would be inclined to just refer to "valuesIterable" directly...  For loops are not the only place that a writeable array is not needed, but we can't hope to catch them all with fancy optimization tricks.

—Dan

Re: Static import from default package ?

Dan Smith — 2012-03-28T19:38:54

I looked for some clarification from the spec.  I think the problem is that A is not in scope.

- 7.5.4: The static-import name must be a TypeName and it must be a canonical name
- 6.5.5.1: The meaning of an unqualified TypeName is the matching in-scope type declaration, assuming there is exactly one
- 6.3: The scope of a top-level type is "all type declarations" (_not_ all compilation units) in the same package

This odd scoping rule allows imports to get around certain name conflicts between types and packages:

---
package A; public class Foo {}
---
public class A { String Foo = "x"; }
---
import A.Foo;
class Test {
  Foo f1; // ok
  A.Foo f2; // error: A.Foo is a field, not a type
}
---

I think the JLS's giving a type in an unnamed package a "canonical name" (6.7) is pointless, because you can't use that canonical name in an import due to the scoping rules, and it's not even a unique identifier, since a system can have multiple unnamed packages (7.4.2).  So I prefer to explain your example with the (apo

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