gmane.comp.java.openjdk.compiler.devel

Re: ARM and repeating exceptions

Aleksey Shipilev — 2012-05-23T16:05:56

On Wed, May 23, 2012 at 8:01 PM, Aleksey Shipilev
<aleksey.shipilev-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Sorry, I was meant to say "equality check":

    final VariableModifiers_minus_final R Identifier = Expression;
    Throwable #primaryExc = null;

    try ResourceSpecification_tail
        Block
    catch (Throwable #t) {
        #primaryExc = #t;
        throw #t;
    } finally {
        if (Identifier != null) {
            if (#primaryExc != null) {
                try {
                    Identifier.close();
                } catch (Throwable #suppressedExc) {
                    if (#suppressedExc != #primaryExc)  // add this
                          #primaryExc.addSuppressed(#suppressedExc);
                }
            } else {
                Identifier.close();
            }
        }
    }

-Aleksey.

Re: ARM and repeating exceptions

Aleksey Shipilev — 2012-05-23T16:01:31

Hi Joe,

On Wed, May 23, 2012 at 7:03 PM, Joe Darcy <joe.darcy-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

I can see that. However, the rules for good language design dictates
the orthogonal features of the language should inter-operate. Are you
saying that current try-wth-resources spec prohibits throwing the
*same* (literally, the same) exception from close()? Would you care to
state that explicitly in AutoCloseable javadoc?


Yes, I had read that paragraph through even before the first reply.
Arguably, that paragraph tells you nothing about the behavior when the
secondary exception is equal()-ly the same. It does not really tell
you can get IllegalArgumentException out of thin air when using
try-with-resources. I would say that is the blind spot of the spec,
and I would strongly encourage us to do least astonishing thing in
that blind spot.


The trouble is not about "rejected by the library code". The trouble
is surprising exception at the runtime. By the way, that surprising
IllegalArgumentExceptio

Re: ARM and repeating exceptions

Joe Darcy — 2012-05-23T15:03:21

Hello Aleksey,

On 5/22/2012 10:41 PM, Aleksey Shipilev wrote:

The desugarings for try with resources in JLS 14.20.3.1 and JLS 14.20.3.2:

try (VariableModifiers_opt R Identifier = Expression ...)
     Block

=>

{
     final VariableModifiers_minus_final R Identifier = Expression;
     Throwable #primaryExc = null;

     try ResourceSpecification_tail
         Block
     catch (Throwable
     ...
}

etc., define precisely what try-with-resources means.  This meaning does 
not support the usage pattern you have brought up.



The the Project Coin/JSR 334 effort took pains to include javadoc for 
Throwable.addSuppressed to discuss the difference between caused by and 
suppressed:

"Note that when one exception causes another exception, the first 
exception is usually caught and then the second exception is thrown in 
response. In other words, there is a causal connection between the two 
exceptions. In contrast, there are situations where two independent 
exceptions can be thrown in sibling code blocks, in p

Re: ARM and repeating exceptions

Aleksey Shipilev — 2012-05-23T05:41:39

Hi Joe,

On Wed, May 23, 2012 at 3:41 AM, Joseph Darcy <joe.darcy-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

I have failed to see where in the spec you can find this:


The wording and spirit of Throwable.addSuppressed API argues it should
be used when you have *another* exception and only one needs to be
propagated. In the test case like mine you can *single* exception that
needs to be propagated, so there is no reason to suppress any other
exceptions.

That said, imposing that additional requirement without even
mentioning this in spec violates the "principle of least
astonishment".


-Aleksey.

Re: ARM and repeating exceptions

Joseph Darcy — 2012-05-22T23:41:24

Hello Aleksey,

The semantics of the try-with-resources statement are defined in the 
Java Language Specification:

     
http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.20.3

Any changes to the semantics of try-with-resources would need to be done 
in the context of a Java SE platform release, such as Java SE 8, and not 
just as a javac change.

That said, I would not support altering the try-with-resources 
desugaring to support this use case.  One exception should be at most 
the cause of XOR suppressed by another.

Cheers,

-Joe

On 5/22/2012 3:07 AM, Aleksey Shipilev wrote:

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

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