Foreach syntax + generics, Possible compiler bug?

I'm encountering an odd problem trying to use generics and the foreach (colon) syntax. The code in question:
for (Iterator<String> it = col.getParameterNames().iterator(); it.hasNext();) {}
for (String paramName : col.getParameterNames()) {}col is an instance of an inner class of the class whose method this code snippet is from, getParameterNames has the signature:
public Set<String> getParameterNames();
The first line, using the Iterator<String> explicitly, compiles fine. The second line, when present, raises the compiler error:
found : java.lang.Object
required: java.lang.String
for (String paramName : col.getParameterNames()) {
I cannot seem to reliably reproduce this situation in other (simpler) classes I write, but this one in particular seems to trigger it. Is it possible this is a compiler bug, or might there be something I'm doing incorrectly that I'm missing? Are my expectations about how the second line should work incorrect? It seems to in other circumstances...
javac is 1.6.0_01. Any ideas?

Here is a quick update, I'm more inclined to think of this as bad behavior now.
This code compiles:
public class Test {
Vector<InnerTest> inners = new Vector<InnerTest>();
    public class InnerTest {        
       public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
    public Test() {
        for (InnerTest it : inners) {
            for (String s : it.someSet()) {        
}however, the following does not:
public class Test {
Vector<InnerTest> inners = new Vector<InnerTest>();
    public class InnerTest<P> {        
       public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
    public Test() {
        for (InnerTest it : inners) {
            for (String s : it.someSet()) {        
}Again, the problem might be with my expectations (I haven't gone through the specifications yet with this in mind), but I can't fathom how or why the unused parameter would make a difference in that method's tpye matching.

Similar Messages

  • Assertion:   (../lnk/exprparse.cc, line 1454) - compiler bug??

    Hi,
    I get the following error message:
    CC -DLT_OBJDIR=\".libs/\" -I. -I. -I./include -DSOLARIS2 -DSTHREAD_CORE_PTHREAD -DARCH_LP64 -DNO_FASTNEW -DW_LARGEFILE -I/usr/local/include -xtarget=ultraT1 -m64 -features=extensions,zla -xthreadvar=no%dynamic -xdebugformat=stabs -xs -g0 -xO4 -mt -lpthread -library=stlport4 -c -o tests_simple-simple_test.o `test -f './src/tests/simple_test.cpp' || echo './'`./src/tests/simple_test.cpp
    >> Assertion: (../lnk/exprparse.cc, line 1454)
    while processing ./src/tests/simple_test.cpp at line 28.
    The source code looks like this (tried to make a simple a possible):
    ---- shell.h:
    class shell_t
    shell_t() {}
    ~shell_t() {}
    int start();
    virtual int process()=0;
    virtual int usage()=0;
    --- shell.cpp:
    int shell_t::start() {
    ...code
    --- simple_test.cpp
    class test_shell : public shell_t
    public:
    test_shell()
    : shell_t()
    ~test_shell() {}
    int process() { ...code... }
    int usage() { ...code...}
    int main(int argc, char* argv[])
    test_sell as;
    as.start();
    return (0);
    Has anyone seen this already?
    Does somebody know, what it means, and how to fix my code?
    Many thanks for all comments.
    -Ippokratis.
    Edited by: Ippokratis on Jun 5, 2008 11:37 PM

    Any compiler assertion is a compiler bug.
    If you want us to address this given issue, please, provide reproducable testcase
    (e.g. exact program that fails to compile together with a command line for compilation that fails).
    regards,
    __Fedor.

  • Local class and switch statement -- compiler bug?

    Does anybody know why the following does not compile with "LocalClass cannot be resolved to a type" error in the case 1: block
    public class ProblemClass {
         public void localClassProblem() {
                   class LocalClass {
                        void doNothing() {};          
                   int i = 0; 
                   switch (i) {                    
                        case 1: {
                             LocalClass instance1 = new LocalClass();  //ERROR: unresolved type
                                            break;
    }while the following does (I only added case 2: where LocalClass type is not referenced within an embedded block)
    public class ProblemClass {
         public void localClassProblem() {
                   class LocalClass {
                        void doNothing() {};          
                   int i = 0; 
                   switch (i) {                    
                        case 1: {
                             LocalClass instance1 = new LocalClass();
                                            break;
                        case 2:
                             LocalClass instance2 = new LocalClass();
    }Is it a compiler bug? Thanks for clarifying this.
    --Michal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    I'm using 1.5.0-b64
    --Michal                                                                                                                                                                                                                                   

  • Strange compiler bug in method overloading mechanism

    Hi,
    current javac compiler in version 1.4.2_10 and probably earlier versions seem to have a bug in the overloading mechanism of static methods in a certain case.
    I consider reporting this as a compiler bug but would like to have some feedback before.
    Would you consider this class correct? With 5+ years of java experience I'd consider it being correct:
    package test;
    public abstract class AbstractClass {
       public class RealizationClass extends AbstractClass {
          public void someMethod() {
             m(1); //Error: m(int,int) in test.AbstractClass cannot be applied to (int)
             m(1, 2);
       private static int m(int i) {
          return i+1;
       private static int m(int i, int j) {
          return i+j;
    }Interestingly the order of those two static method and their visibility affects the error (changing visibilty to public/protected makes javac accept the code).
    Eclipses compiler does not have this problem, it happily accepts the code above.
    What do you think?
    -Sebastian

    JLS 2.0 says on page 147: "The scope of a declaration of a member m declared in or inherited by a class type C is the entire body of C, including any nested type declarations."
    I read somewhere that in the case a nested or inner class accesses private fields of its enclosing type, the compiler generates "sythetic accessor methods" to allow access. Maybe there's something wrong with the generation of these generated methods...

  • Xerox_mfp scanner not working in arch (compilation bug?)

    I have discovered that my xerox_mfp printer/scanner Xerox Workcentre 3119 is not working in archlinux. However, with the same libsane version, scanner is working in debian.
    I checked the two libraries libsane-xerox_mfp.so.1.0.22: they are different in size.
    I have copied the debian library in /usr/lib/sane and now the scanner is working.
    Compilation bug?
    Last edited by hifi25nl (2011-05-24 17:35:01)

    architecture: x86-64
    samsung scx-4200: xerox_mfp sane backend
    the same problem
    libsane-xerox_mfp.so.1.0.22 from debian libsane_1.0.22-6_amd64 package is working

  • Another Compiler Bug (message: An internal build error has occurred... Unknown Flex Problem)

    I was fighting with this problem for a few days. Finally I've got it resolved. I want to describe it and fill in BUG in the bug report, but I am not sure about Adobe support options. So, I am putting bug report here.
    1. ASSUMPTION: All problems which compiler reports as unknown problem are the real compiler BUGs/Problems. Eventually MXML compiler/ActionScript compiler should be able to take C++ or FORTRAN code or an aribitrary text and nicely tell "Error: It is not ActionScript (Flex) code" or "the code is corrupted from Line so and so...". When compiler crashed, it is most probably due to one of the states not handled (or not handled correct). Keeping this in mind I assume, that my code has nothing to do with the compiler crash.
    2. PROBLEM Description.
         - I tried to port our internal project from Flex3.5/Flex Builder 3 to Flex4.1/Flash Builder 4.
         - After checking out and trying to build code I start getting weird problems like Error 1037: Packages cannot be nested.
         - After cleaning and compiling project by project, walking up dependency tree, I was able to get rid of this problem.
         - On last Project I've got another problem (An internal build error has occurred... Unknown Flex Problem). Which I stuck with for a while.
         - When I checked log file I found following messages:
    ============================================================
    !ENTRY com.adobe.flexbuilder.project 4 43 2010-12-21 15:45:24.353
    !MESSAGE Uncaught exception in compiler
    !STACK 0
    java.lang.ClassCastException: macromedia.asc.parser.InputBuffer cannot be cast to flex2.compiler.as3.CodeFragmentsInputBuffer
    at flex2.compiler.as3.AbstractSyntaxTreeUtil.lineNumberToPosition(AbstractSyntaxTreeUtil.jav a:1266)
    at flex2.compiler.mxml.ImplementationGenerator.generateBinding(ImplementationGenerator.java: 569)
    at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetupFunction(ImplementationG enerator.java:863)
    at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetup(ImplementationGenerator .java:812)
    at flex2.compiler.mxml.ImplementationGenerator.generateInitializerSupportDefs(Implementation Generator.java:1878)
    at flex2.compiler.mxml.ImplementationGenerator.generateClassDefinition(ImplementationGenerat or.java:1044)
    at flex2.compiler.mxml.ImplementationGenerator.<init>(ImplementationGenerator.java:206)
    at flex2.compiler.mxml.ImplementationCompiler.generateImplementationAST(ImplementationCompil er.java:499)
    at flex2.compiler.mxml.ImplementationCompiler.parse1(ImplementationCompiler.java:197)
    at flex2.compiler.mxml.MxmlCompiler.parse1(MxmlCompiler.java:168)
    at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2871)
    at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2824)
    at flex2.compiler.CompilerAPI.batch2(CompilerAPI.java:446)
    at flex2.compiler.CompilerAPI.batch(CompilerAPI.java:1274)
    at flex2.compiler.CompilerAPI.compile(CompilerAPI.java:1496)
    at flex2.tools.oem.Application.compile(Application.java:1188)
    at flex2.tools.oem.Application.recompile(Application.java:1133)
    at flex2.tools.oem.Application.compile(Application.java:819)
    at flex2.tools.flexbuilder.BuilderApplication.compile(BuilderApplication.java:344)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder$MyBuilder.mybuild(A SApplicationBuilder.java:276)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder.build(ASApplication Builder.java:127)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASBuilder.build(ASBuilder.java:190)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASItemBuilder.build(ASItemBuilder.java:7 4)
    at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.buildItem(FlexProjectB uilder.java:480)
    at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.build(FlexProjectBuild er.java:306)
    at com.adobe.flexbuilder.project.compiler.internal.FlexIncrementalBuilder.build(FlexIncremen talBuilder.java:157)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:218)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:360)
    at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:516)
    at org.eclipse.core.internal.resources.Project.build(Project.java:94)
    at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:221)
    at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:162)
    at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:483)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38 )
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
    !SESSION 2010-12-22 09:48:27.766 -----------------------------------------------
    eclipse.buildId=M20100909-0800
    java.version=1.6.0_16
    java.vendor=Sun Microsystems Inc.
    BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
    Framework arguments:  -product org.eclipse.epp.package.jee.product
    Command-line arguments:  -data C:\Client_Flex4 -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
    ================================================
    3. RESOLUTION/WORK AROUND
         - I was able to get this problem cleared by putting compiler option for Flex Application projects:  -keep-generated-actionscript
    4. SIDE NOTE
      I do not really see putting this compiler option as the solution and living with the mistery is making me fill a bit bad.

    Hi Faser,
    I just tried it on Vista with our latest FB Plugin build but
    I was unable to reproduce your issue with the following setup:
    - FB Plugin build installed by Administrator account user
    under her Documents folder
    - Administrator account user can launch, create Flex projects
    under her own workspace without any problems
    - Standard account user can launch the FB Plugin build (need
    Admin's password) and create Flex project (default location) under
    his own workspace
    If your setup is different, can you please log a bug at
    http://bugs.adobe.com/flex.
    Be sure to include what build you are using, whether it's
    reproducible, the detail of the setup, etc...
    thanks,
    Sharon

  • SS9 CC5.6 compiler bug - algorithm count confused with struct member

    Found some code that fails to compile in CC 5.6
    CC: Sun C++ 5.6 2004/07/15
    #include <algorithm>
    using namespace std;
    struct A {
      int count;   
    struct B
      struct A *a;
    int main(int argc, char **argv)
      struct B *b = 0;
      // This line fails to build, any other operator is ok
      if ( b->a->count < 50 )
      return (1);
    }Fails with error :
    "c56_algorithm_bug.cpp", line 21: Error: Unexpected ")" -- Check for matching parenthesis.
    "c56_algorithm_bug.cpp", line 22: Error: "," expected instead of "{".
    "c56_algorithm_bug.cpp", line 22: Error: Illegal value for template parameter.
    "c56_algorithm_bug.cpp", line 22: Error: ")" expected instead of "{".
    4 Error(s) detected.The compiler is getting confused with the use of the count struct member vs the count algorithm. Changing the < to a > fixes the problem.
    Using CC5.3 works fine as well as all other compilers we use (gcc 3.4, mipspro 7.4, VC 7.1)
    Anyone seen this ?
    - mark

    This bug has been fixed in the C++ 5.6 compiler. I'm not sure if the fix is in the first patch which is about to be released. If not, the fix definitely will be in the next patch.
    The workaround is not to use
    using namespace std;That using-declaration is a pretty big hammer, and often results in conflicts with user code, compiler bugs aside.

  • Compiler bug with generics and private inner classes

    There appears to be a bug in the sun java compiler. This problem was reported against eclipse and the developers their concluded that it must be a problem with javac.
    Idea also seems to compile the example below. I couldn't find a bug report in the sun bug database. Can somebody tell me if this is a bug in javac and if there is a bug report for it.
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=185422
    public class Foo <T>{
    private T myT;
    public T getT() {
    return myT;
    public void setT(T aT) {
    myT = aT;
    public class Bar extends Foo<Bar.Baz> {
    public static void main(String[] args) {
    Bar myBar = new Bar();
    myBar.setT(new Baz());
    System.out.println(myBar.getT().toString());
    private static class Baz {
    @Override
    public String toString() {
    return "Baz";
    Eclipse compiles and runs the code even though the Baz inner class is private.
    javac reports:
    Bar.java:1: Bar.Baz has private access in Bar
    public class Bar extends Foo<Bar.Baz>
    ^
    1 error

    As I said in my original post its not just eclipse that thinks the code snippet is compilable. IntelliJ Idea also parses it without complaining. I haven't looked at the java language spec but intuitively I see no reason why the code should not compile. I don't think eclipse submitting bug reports to sun has anything to do with courage. I would guess they just couldn't be bothered.

  • Generics: compiler bug or not?

    Hi.
    I faced with some strange issue, which may be described as follows:
    import java.util.Collections;
    import java.util.List;
    public class Test<T> {
        public List<String> getStrings() {
            return Collections.emptyList();
        public static void main(String[] args) {
            Test test = new Test();
            for (String s : test.getStrings()) { // first
                System.out.println(s);
            Class aClass = test.getClass();
            Deprecated annotation = aClass.getAnnotation(Deprecated.class); // second
    }The lines commented as "first" and "second" cause compilation error "incompatible types". The problem can be fixed the following way:
            Test<?> test = new Test();
            for (String s : test.getStrings()) { // first
                System.out.println(s);
            Class<?> aClass = test.getClass();
            Deprecated annotation = aClass.getAnnotation(Deprecated.class); // secondBut why does it appearat all?
    Regards,
    Maxim

    Might be better off sticking this in the generics
    forum, since Mr von der Ahe hangs around there so
    much. Although I'm not convinced he'd concede that
    ECJ got it right where his beloved javac didn't :-)Ok, I will cross post (and flag it as a cross post). I remember that I had another thread there, a long time ago, and Eclipse was correct at that time :)
    Kaj

  • [Bug] Compiler bug in JDev  10.1.3.0.4 (SU5)

    Hello,
    I would like to report a bug with Java 5 compiler in JDev 10.1.3.0.4 (SU5) build JDEV_ADF_10.1.3_NT_030125.0900.3673 regarding covariant return types.
    As of Java 5, it's now possible to override a method with a different return type as long as the new return type is a subclass of the overridden method's return type. JDeveloper compiler will manage that correctly (no compilation error), but will result in a java.lang.AbstractMethodError if the overriding definition come from an interface.
    So the reproduction case is :
    public interface Interface1 {
       public Object myMethod();
    public interface Interface2 extends Interface1 {
      public String myMethod();
    public abstract class AbstractInterface2 implements Interface2 {
    public class MyClass extends AbstractInterface2 {
      public String myMethod() {
        return "Hello"!;
    public static void main(String... args) {
      Interface1 myObject = new MyClass();
      myObject.myMethod();
    }I did not test with other JDev version.
    Regards,
    Simon Lessard

    quick workaround is to set project output directory to the WEB-INF/classes directory and compile the jsp from jdeveloper, oc4j then updates the loaded class file without re-compiling the jsp.
    This works fine, but if I let OC4J try to compile the JSP problem still occurs, anyone have any ideas why either of these problems occur?

  • Syntax errors possible at runtime?

    Hello,
    i need to know something about those, i didn't really find any good explinations at google..
    so a syntax error is an error because we write something wrong: it's not written like it should
    so a syntax error is a compile time error, but now im a bit unsure if it is possible to have a syntax error which doesnt give an error at compile time, but does at run time
    i think like having
    public void main(String[] args) // we forgot the static declaration
    //do stuff
    it won't give an syntax error because it is fine, but when we run it it gives an error... is this then a syntax error hidden at compile time but a detected syntax error at runtime?
    anyone can confirm and if possible with my/an example?
    thanks in advance

    796870 wrote:
    public void main(String[] args) // we forgot the static declaration
    //do stuff
    it won't give an syntax error because it is fine, but when we run it it gives an error... is this then a syntax error hidden at compile time but a detected syntax error at runtime?Not really, since there's nothing wrong with the syntax. It's just not the right syntax for a class intended to run as a program.

  • Syntax error while compiling

    Hi Gurus,
    I have started with VC and while compiling a model, I get a syntax error in Fiscalyear (variable in the query).
    the message is "The expression in field 'FiscalYear' contains an error: Syntax error".
    "Stopped due to errors"
    Have no clues as the other variable (Cost center) is working fine.
    We are on NW7.0 SP13
    Tks
    KS

    Hi
    Right click on the joining line after that form. Go to the field mapping & go to the field for the 'Fiscal Year'
    Do following changes 
    If by default you are getting there '@Fiscal year' then make it '@Fiscal year_Key' means whatever is there, just add "_key" after that. Then instead of compiling & deploying, Directly Deploy the model & then check if you are getting any error.
    Regards
    Sandeep

  • Multiple constraining classifiers in generic templates - compiler broken

    can not compile multiple constraining classifiers to a generic template if the classifier is defined in the template:
         public <U, T extends U> void a() {}
    will compile.
    java language specification: 4.4 Type Variables says:
         public <T extends Object & Comparable<? super T> > void a() {}
    will compile, but:
         public static <U, T extends U & Comparable<? super T> > void a() {}
    will not compile.
    U is defined within the template but is only accepted as a constraining classifier to T if it is on its own. When the interface is added, the java compiler breaks.
    (please ignore ">" as required.)
    compile error message:
    "a type variable may not be followed by other bounds"

    thanks...You're wecome.
    B.t.w. my guess it's not the compiler, though.+1
    'select' isn't broken :-)I'll put that one in my bookmarks, next to The Ten Commandments
    ; )

  • SDK 3.0: Compiler bug with std::deque?

    When I call std::deque::assign(), I get all kinds of compile-time errors, including internal compiler errors.
    Note, however, that this happens only when I compile for the 3.0 device. It does not happen when I compile for the 3.0 simulator, 2.x device or 2.x simulator. In all those other modes it compiles and works just fine. Only when compiling for the 3.0 device, the compiler errors happen.
    I'm pretty certain this is a bug in the SDK. Has anyone else noticed this?

    Assign is a particularly tricky one. There are two assign methods. One takes two iterators and the other takes a size and value:
    template<class InputIterator>
    void assign(InputIterator first, InputIterator last);
    void assign(size_type n, const T & t);
    For whatever reason, the compiler for the 3.0 device is saying "int" and "int *" are the same type. It is instantiation the version with the iterators instead of the second one. This is a typical error you might see on a platform with weak C++ support. I used to have to deal with things like this all the time in the early days of MacOS X.
    Unfortunately, the only workaround is to do something else. The following should work:
    #include <algorithm>
    std::deque<int> values;
    std::filln(std::backinserter(values), 10, 1);

  • Error in compilation - Bug in the Oracle Java Compiler ? (10.1.3)

    I've the following situation :
    I've a class wich extends ViewObjectImpl,named ClViewObjectImpl, and another class, named RbViewObjectImpl wich extends ClViewObjectImpl.
    My classes have only a constructor with no parameters .
    Compiling with standard Oracle complier I get the following error
    Error: method $init$() in class oracle.jbo.server.RbViewObjectImpl cannot override method $init$() in class oracle.jbo.server.ClViewObjectImpl with weaker access privileges, was
    Compiling with javacc it compiles.
    Is it an bug ?
    Is there any workaround ?
    Tks
    Tullio

    Repost

Maybe you are looking for