FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b140)
Java HotSpot(TM) Server VM (build 21.0-b10, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux ----- 2.6.34.1 #1 SMP PREEMPT Thu Jul 8 10:08:41 BST 2010 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux.

A DESCRIPTION OF THE PROBLEM :
This may not be so much of a bug but misleading information being printed to stderr, sending an ambiguous message to the user that something insides the Java Compiler API might have crashed. There might be an easy fix commenting out the statement that prints the stack trace in Symbol.java, but it is something the developers may need to investigate and decide.

The behaviour seems to be closely related to Bug 6956462 (http://bugs.sun.com/view_bug.do?bug_id=6956462) which was reportedly fixed in b112 of release 7. The fix, see

  http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/d54300fb3554

involved catching an AssertionError in com.sun.tools.javac.comp.Attr. that would have otherwise been propagated to the user, and thus cause the Compiler API to crash when, for instance, visiting the following code fragment

class Test {
   public void test() {
      final Map fileToURL = Collections.emptyMap();
   }
}

while inferring the Scope (getScope()) from inside the initialising method call.

The AssertionError seems to originate actually from com.sun.tools.javac.code.Symbol, namely the getConstValue() function.

Subsequently after fixing this bug, however, Symbol.java has changed:

  http://hg.openjdk.java.net/jdk7/jdk7/langtools/diff/df371fd16386/src/share/classes/com/sun/tools/javac/code/Symbol.java

In this change, the stack trace is printed to stderr just before throwing the AssertionError. However, the AssertionError is caught and used in programmatic ways now, not causing the program to crash. If there is no underlying inconsistency (why catch an AssertionError?) the printing of the stack trace should be suppressed as it sends ambiguous messages to the user. I suppose the second change due to 6554097 did not anticipate that this AssertionError might be caught, and hence felt at liberty to print out additional error information (or otherwise this is just a glitch or forgetting to comment it out).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Similar to Bug 6956462.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correctly visit the code and determined the scope of all elements (same as Bug 6956462).
ACTUAL -
Printing out the stack trace where Bug 6956462 raised an error.

Otherwise the program seems to behave well in terms of functionality.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
com.sun.tools.javac.comp.Attr$BreakAttr
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:433)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418)
at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:449)
at com.sun.tools.javac.comp.Attr.attribLazyConstantValue(Attr.java:603)
at com.sun.tools.javac.code.Symbol$VarSymbol$1.call(Symbol.java:975)
at com.sun.tools.javac.code.Symbol$VarSymbol.getConstValue(Symbol.java:1007)
at com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:861)
at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:725)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480)
at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:496)
at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:903)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:781)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418)
at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:480)
at com.sun.tools.javac.comp.Attr.attribStatToTree(Attr.java:358)
at com.sun.tools.javac.api.JavacTrees.attribStatToTree(JavacTrees.java:336)
at com.sun.tools.javac.api.JavacTrees.getAttrContext(JavacTrees.java:317)
at com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:228)
at com.sun.tools.javac.api.JavacTrees.getScope(JavacTrees.java:82)
at hijac.scj.analysis.tasks.MethodTagsVisitor.getEnclosingMethod(MethodTagsVisitor.java:35)
at hijac.scj.analysis.tasks.MethodTagsVisitor.visitMethodInvocation(MethodTagsVisitor.java:79)
at hijac.scj.analysis.tasks.MethodTagsVisitor.visitMethodInvocation(MethodTagsVisitor.java:20)
at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1333)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:80)
at com.sun.source.util.TreeScanner.visitVariable(TreeScanner.java:150)
at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:736)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:90)
at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:159)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:790)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:80)
at com.sun.source.util.TreeScanner.visitMethod(TreeScanner.java:142)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:690)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:80)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:90)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:98)
at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:132)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:618)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:90)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:98)
at com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:119)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:492)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:67)
at hijac.scj.analysis.tasks.MethodTagsTask.doTask(MethodTagsTask.java:47)
at hijac.scj.analysis.tasks.AbstractAnalysisTask.invoke(AbstractAnalysisTask.java:85)
at hijac.scj.analysis.TaskProcessor.invoke(TaskProcessor.java:130)
at hijac.scj.application.Analyse.main(Analyse.java:251)

Note that this is just a message; it does not actually result in the application crashing or behaving incorrectly, at least in the examples I used.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Same as Bug 6956462. That is, visit:

import java.util.Collections;
import java.util.Map;

class Test {
   public void test() {
      final Map fileToURL = Collections.emptyMap();
   }
}

and determine the scope of the Collections.emptyMap() node.

(I used a TreePathScanner instead of a SimpleTreeVisitor, but I suppose this does not make a difference.)
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Simply comment out the line

  ex.printStackTrace();

in src/share/classes/com/sun/tools/javac/code/Symbol.java that was introduced with 6554097:

  http://hg.openjdk.java.net/jdk7/jdk7/langtools/diff/df371fd16386/src/share/classes/com/sun/tools/javac/code/Symbol.java.