Bugzilla – Full Text Bug Listing
| Summary: | Compilation slow when APT is enabled | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Walter Harley <eclipse> | ||||||
| Component: | APT | Assignee: | Walter Harley <eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P1 | CC: | daniel_megert, edwinc, jacek.pospychala, jkingdon, jzhang, karasiuk, markus.kell.r, melickm, Olivier_Thomann, rstheo, rtaniwa, srinivas.surapaneni | ||||||
| Version: | 3.4.1 | ||||||||
| Target Milestone: | 3.5.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 285799 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
More details about the workspace causing the slowdowns: — Happens on Mac/Carbon and Windows — About 300 Java files in about 20 packages — About 20 of these files are annotated with my custom annotations. Those files are small, 50-100 lines of code, and contain on average 10-15 annotations We're talking about Java 5 annotation processors only (Eclipse 3.4.1). Wow, that is not a very big project for such a pronounced slowdown. Are the annotations also in source code, or are they coming out of a .jar? Are there any particularly large (>10MB) jar files on the build path? If necessary, would it be possible for you to share the entire project with an Eclipse developer, for troubleshooting purposes? (I don't know what IP issues exist around your code, just asking.) The annotations are in a jar (in which there's also the annotation processor), but the contents of the jar comes from two separate project in that workspace. There is no such big jar file on the classpath. For IP issues, I cannot share the actual code I'm working on, but I'll try to recreate another similar situation where those slowdowns occur. JP, I was able to reproduce very long build times (17 second) with the test workspace. The problem is caused by including the project org.eclipse.ui.workbench as a source project. As a result, APT retrieves far more classes from source files instead of .class files, when it builds the AST view for your editor type. I suggest you remove the org.eclipse.ui.workbench source plugin & replace it with the jar file (unless there is some reason that you must include it as a source project - do you know why its included as a source plugin?). When I include the workbench plugin as a binary jar, my build time is less than 2 seconds. Kent, Thanks for your time and help. org.eclipse.workbench.ui is included because it's slightly modified in a few places. I could regenerate a jar each time I change it and not have it listed as a source project, but it's a non-minor inconvenience actually… Why does APT need to perform this expensive step? Can't it be done lazily? And why does it need to be done each time my annotation processor is run, even if it hasn't changed in the meantime? Best, J.-P. The source for ui.workbench must be parsed & converted to an AST by APT each time because you have chosen to include it on your buildpath as a source project instead of a binary jar file. Walter could probably give you a better detailed description as to why, but the bottom line is any requested type that is found as a source file is parsed & a new AST is created for it + any types that it references. Including lots of 'extra' source files on your classpath can cause a real performance problem. I accept that creating a new jar for ui.workbench is a pain, but I do not see an alternative if you want to continue to use APT. I see. Thanks for the explanations. Could we consider excluding certain projects on the build path from being parse each time? Maybe as a preference in the AST preference pane in the project properties? I imagine this problem can show up easily in other cases, as the number of source file grows. I mean, the silly thing is that those files are totally unrelated to the processing I'm doing. Now, APT cannot know this, granted; but if I have a mechanism to tell it that I don't need those source files, this would sound to me like a reasonable option. Or maybe a checkbox "Provide AST for this project only" in the same preference pane… What would you think of that? "those files are totally unrelated to the processing I'm doing" But that IS the problem. The classes from ui.workbench are needed to compile your editor type. For example, your editor class imports: import org.eclipse.ui.IActionBars; import org.eclipse.ui.IEditorInput; import org.eclipse.ui.IEditorPart; Once your editor type references these 3 classes (and likely a few more) in ui.workbench then we end up resolving all of their type references and eventually parse 100's of types. I think you will find very different compile times for your own classes. If they do not reference a ui.workbench type then it should be quick to compile. I'm not sure I'm understanding this. When APT is disabled, it compiles quickly, even if it references those other source files in ui.workbench. But when APT is enabled, then all of a sudden they all need to be reparsed? Technically, they have been compiled already, right? None of those the classes there is annotated. We really can't limit the AST generation to the current project? Would it be any different with a Java 6 annotation processor? Thanks, J.P. and Kent, for pursuing this and figuring out the cause.
J.P., I think you're suggesting either that (1) we should support a different build classpath for processing than for compilation (i.e. the compiler bases its image of a type on source while APT gets it from a binary representation that might not be the same), or (2) we should cache ASTs across compilations (and only update the AST when the source changes), or that (3) we should allow users to specify that source types from some projects have less correct and complete type information than from others.
We certainly don't want to do #1; I hope that's obvious. Option #2 is not acceptable from a memory standpoint - remember that the compiler is only one player in a build, and if the compiler hangs on to huge amounts of memory it's not available for other subsequent build steps.
I can sort of see option #3, but I do not relish the idea of designing and implementing that UI, nor of trying to explain to users what information won't be available. I get enough flack from people who think APT already has way too much configuration required!
If it helps to understand, one reason we need ASTs for source is that the APT interface explicitly supports (indeed, has to support) semantically incomplete or incorrect types in source. For instance, I might have the following:
@GenerateInterface("IFoo")
class Foo implements IFoo {
@IncludeInInterface
@Override
void someMethod() { ... }
}
Where IFoo does not exist until it is generated at processing time. The processor needs to be able to read Foo's methods and annotations even though Foo contains compilation errors.
However, there may also be some other reasons buried in there - I wasn't involved in that part of the project at the time that design decision was made so it's possible that I'm missing some of the details.
Anyway, one idea without too much UI required might be to have an option like "don't allow APT to provide information about types in upstream projects, unless the project (or type) is compiling without errors". That might work out, because the compile dependency should always be in one direction, but I'd need to think more deeply about it to prove that. Also it's not obvious to me that the information about a source type's location is readily available in the right place for APT (or the compiler) to make that judgement. It does not sound easy to me.
I think this might be an interesting direction to pursue if or when we get time to focus on APT performance issues; these project dependencies are an area where the IDE has more information than a command-line build would. But I do not see myself having that time soon. I am afraid that for now the answer is that we treat source as source, binary as binary, and we do not have a finer-grained option.
Walter, Kent, thanks a lot for your time and your explanations. I clearly understand the underlying situation now. AFAIC, Walter, I'm enjoying every single bit of APT in Eclipse, and love it. I hardly see how you could offer less configuration for it without cropping important functionalities. I hope someone has time one day to look into this. In the meantime, I'll find a workaround by putting workbench.ui in another workspace, or something. Thanks again for your time. Assigning this back to APT component. Some notes from yesterday: The editor type that takes 17 seconds to build ends up requesting & converting 1125 files when ui.workbench is on the path as a source project. When its a binary project, only 152 types are requested. Hi, I'm having a similar issue with large workspace (~6000 compilation units). As a result Eclipse runs out of memory during building ASTs for APT and before calling the annotation processors. Does that mean that APT doesn't scale well? Are there any plans to change this? (In reply to comment #14) > Hi, > I'm having a similar issue with large workspace (~6000 compilation units). > As a result Eclipse runs out of memory during building ASTs for APT and before > calling the annotation processors. Hi, Jacek. Sorry, I'm sure that's frustrating. > Does that mean that APT doesn't scale well? I would say "doesn't scale well" is too broad to be useful. All systems have some usage patterns where they scale well and others where they don't; clearly APT is not scaling well to your particular case, and the question is whether and how that could be fixed. Please read the preceding comments in this bug report, and see if that helps you understand what the specific limits are, and whether you can restructure your classpath to solve this. As to whether APT can't handle workspaces with a lot of files, all I can say is that so far, the only two problem reports I have are yours and the one that led to this bug report. It's possible that most APT users are working with smaller workspaces (as it is primarily used in JEE development) and haven't noticed. Or it's possible that there's something else unusual about your workspace. How much memory are you giving Eclipse, when it runs out? Does giving it more memory solve the problem in your case? Do you have Java 5 processors, Java 6 (JSR-269), or a mix of both? > Are there any plans to change this? It is too late in the 3.5 cycle to make the sort of changes suggested in comment #10, but clearly if there's a problem that can't be addressed in a different way then it needs to be fixed. As for when that would happen, contributions are of course always welcome; as I think you already know, APT is currently maintained by one part-time volunteer (me) with very limited hours. Walter, it can be that later this year I can find some time to look into the source code of APT a bit more, if it turns out to be worth it. How hard would it be to implement the creation of the AST lazily, i.e., only when client code would specifically request the details would the AST be constructed? What do you think, would such an approach have a chance? Created attachment 136547 [details]
Graph of performance of createASTs
Thanks, James, having some concrete info on this is helpful. Are those classes in the same project, workspace, ...? Do the classes all contain annotations? How big are they? Sorry Walter, I meant to add the following explanation with the graph.
I did some investigation of the performance issue, results shown in the
attachment "Graph of performance of createASTs".
I created a synthetic test project containing multiple copies of a trivial
class:
package com.ibm.test0;
@SuppressWarnings("unchecked")
public class Test0 {
}
I then timed the call to ASTParser.createASTs from
org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs with
different numbers of classes. The non-linear behaviour is quickly evident as
shown in the attached graph. I also timed how long it took to create the
CompilationUnits from the BuildContexts and the time taken calling the
registered annotation processors, but both of these were small compared to the
time spent in createASTs.
One area I haven't investigated is the time taken in the callback acceptAST
method. This code looks suspicious from a scalability standpoint:
public void acceptAST(ICompilationUnit source, CompilationUnit ast) {
for( int i=0, len = asts.length; i<len; i++ ){
if( source == parseUnits[i] ){
asts[i] = ast;
break;
}
}
}
I should mention that my main concern was performance as I was investigating a
customer problem which was focussed on performance issues. The related problem
of OutOfMemoryExceptions is presumably going to require a change of approach to
cut back on the number of ASTs that are simultaneously required.
Regards,
James.
Discussed with Walter that we will look into this for 3.5.1. A longer-term solution could also profit from better JDT/Core support for creating many ASTs, see bug 150657. For memory and performance reasons, JDT/UI refactorings currently call ASTParser.createASTs(..) in batches (e.g. at most 150 CUs for Infer Generic Type Arguments), and we do all our processing in the acceptAST(..) callback and don't keep references to the ASTs when that method returns. In the APT case, batches may be problematic, since I guess you need to keep references to IBindings, and those only share their environment (identity guarantees, etc.) for one batch. But not keeping references to ASTs should bring down memory usage. We had similar issues. Our project is a big annotations project. Close to 400 files with annotations We are allocating 1400 MB for eclipse. When it is compiling this project, it uses almost all the memory and sometimes give out of memory errors When it is done compiling the project, memory usage is only 60 MB I am attaching the jrockit jra recording also when this is happening Please get the jrockit jra recording from http://www.datascantech.com/debug/recording.zip Thanks, Srinivas. Can you tell me where to download the tool to analyze the JRA recording? Hi Walter You can download jrockit mission control from oracle website http://www.oracle.com/technology/software/products/jrockit/index.html You will see jrmc.exe in the bin directory You can open jrmc and open the recording and analyze it Thanks Srinivas Well, it is a bit hard to tell from that profile, but it looks to me like the problem here is that the Beehive annotation processor is making expensive calls that require parsing every file and cracking every jar. Take a look at the call trees of the hot methods, to see what I mean. For example, the single hottest trace is under the method org.apache.beehive.netui.compiler.FlowControllerChecker.checkForOverlappingClasses, which tries to get all the classes in a package, presumably to check that none of them have conflicting annotations. If this is being done for every class, you can imagine it's going to be a problem. Remember that a package may be distributed over multiple projects and classpath jars. The APT team presented several "best practices and antipatterns" tutorials at EclipseCon and JavaOne to try to educate processor writers on what sort of calls to avoid in order to stay performant; there's more material on this topic at http://www.eclipse.org/jdt/apt/main.html . That said, although there's probably no way to make a large Beehive project run fast, it may be possible to make it at least run successfully without running out of memory. That'll take some fairly deep investigation. In the meanwhile, I apologize but I wonder whether it is possible to break the project into smaller pieces? This is a web application and it is difficult to break into multiple projects If it is a utility project, i would have broken into multiple projects. Thanks Srinivas I understand. How many classes per package are there, on average? Is it possible to try breaking into smaller packages, to see if that helps? Also, if you build at the command line (with javac and apt), how much memory does it take? This is not an exact comparison because IDE and batch builds have different requirements, of course, but it would be informative. Perhaps you could record a JRA file from a command-line build? Hi Walter We have a top level package and underneath it we have multiple packages We have 400 beehive controllers and each controller will be in a package by itself This is enforced by beehive ( each new controller will be in a package by itself) I will try to get the JRA recording for command line and upload it to you. Thanks Srinivas Hi Walter I ran the build process from command line using ant I could not get the JRA recording for this But I watched the memory usage for apt and it never went above 240mb and it is successful all the time In eclipse, it is using up all the 1400 mb and some times getting out of memory errors Thanks Srini Reassigning to jdt-apt-inbox, per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009. Hi Walter Is this a JDT bug? Is this going to be fixed in 3.5.1? Thanks Srinivas (In reply to comment #32) > Is this going to be fixed in 3.5.1? At this point we do not have a set of performance test cases with which to reproduce and study the problem; therefore, we do not have a good handle on what parts of the system might be causing the problem. If there are perf improvements that do not require substantial redesign or destabilization, and that can be accomplished by 3.5.1, they'd certainly be considered. APT is currently maintained by one volunteer, me, in my limited spare time; so any promises about what will and won't be fixed in 3.5.1 are probably irresponsible. The perf issue is my highest priority for APT but there is still a very limited amount of time available. If anyone affected by APT performance problems is able to contribute development effort, in particular by helping to write a realistic set of performance test cases (that can be committed to Eclipse) and then gather profiling data on them, that would be very welcome; please contact me directly if so. Raising priority to P1 and targeting for 3.5.1 in the hopes that we'll be able to make some short-term progress on this. I've been doing some profiling of large projects containing simple (non-processed) annotations, with annotation processing enabled or disabled. One interesting finding is that with APT enabled, in a project with 4000 small classes each containing an @SuppressWarnings annotation, the compiler is spending almost half the total build time in the following call stack: org.eclipse.jdt.internal.compiler.util.HashtableOfObject.rehash() org.eclipse.jdt.internal.compiler.util.HashtableOfObject.removeKey(char[]) org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(ICompilationUnit[], String[], ASTRequestor, int, Map, WorkingCopyOwner, int) org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(ICompilationUnit[], String[], ASTRequestor, int, Map, IJavaProject, WorkingCopyOwner, int, IProgressMonitor) org.eclipse.jdt.core.dom.ASTParser.createASTs(ICompilationUnit[], String[], ASTRequestor, IProgressMonitor) org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(IJavaProject, ICompilationUnit[], ASTRequestor) org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildContext[]) org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(BuildContext[], BuildContext[], IJavaProject, AbstractCompilationEnv$EnvCallback) Performance with these files (small, annotated with non-processed annotations) is approximately O(n^1.5). On my machine, building 1k files takes 5 seconds; 2k takes 14; 4k takes 42. It appears that org.eclipse.jdt.internal.compiler.util.HashtableOfObject.removeKey() always calls rehash(), which always creates a new table of double the size and copies all the remaining entries. This seems like a problem. removeKey() is only called once per file, but assuming that the expense of rehash() is roughly O(N log N), this would easily account for the problem. Indeed: when I replace the HashtableOfObject in CompilationUnitResolver with an ordinary java.util.HashMap, performance is O(N), and is improved in absolute terms. I will enter a bug against JDT core. Entered bug 285799 to track the HashtableOfObject performance problem. Good catch Walter! I'm now looking at the case where there are many files that contain annotations that are processed, but that do not result in new types or errors being generated - that is, simple typesystem inspection by a JSR-269 processor. I'm basing this test on the o.e.jdt.apt.pluggable.tests.processors.modeltester.ModelTesterProc processor. With the CompilationUnitResolver tables replaced by HashMap, as per previous suggestion, it seems that compilation is slower by about 3x when annotation processing is enabled; however, it scales linearly in the number of files. A substantial part of the processing cost, in this simple case, is in the construction and population of HashMaps, within methods like ManyToMany.getValues() that are called from within the annotation processor. The ManyToMany data structure returns copies, rather than views. It would be worth taking a look at uses of this (internal) type to see if its behavior can safely be changed to return a view. Note, though, that in a more complex processor this particular cost might be lost in the noise. Created attachment 143844 [details] Patch As noted in bug 285799, fixing HashtableOfObject so that key removal is efficient may be difficult. Instead it might be best to just use that class for collections where removal is rare, and stick with HashMap when removal is frequent. The attached patch uses HashMap for the requestedKeys and requestedSources tables in CompilationUnitResolver. An alternative would be to pre-filter these tables so that they do not contain duplicate entries, per the comment on line 743, "remove at the end so that we don't resolve twice if a source and a key for the same file name have been requested." If we fix this, APT performance will be linear in the number of types requested. Still, per comment #13, unexpectedly many types may be requested; and per comment #40, the extra work done by APT causes a slowdown which, even if linear, is substantial. >the extra work done by APT causes a slowdown which, even >if linear, is substantial. How's that in numbers i.e. how much does the suggested patch from comment 41 buy us for big workspaces? (In reply to comment #42) > How's that in numbers i.e. how much does the suggested patch from comment 41 > buy us for big workspaces? For 2000 trivial files, on my machine, build time with HashtableOfObject was 14 seconds; with HashMap it was 9 seconds. The difference goes up steeply as the number gets larger than this. I am a performance analyst of an adopting product. We currently have a customer workload that we've migrated to our upcoming release that is encountering this problem. APT is now turned on by default for all our projects by a server plugin we depend on (to enable WebService annotations). The workload has a single package that has 109 Java files (generated) that total 66 MB on disk (quite large Java files). Trying to build just this single package (nothing else in the workspace) with APT enabled results in OOM with a 1024m heap. This is clearly an issue and a deal-breaker for APT in this case. I'm not sure I can contribute any analysis time, but I'd be willing to test out any proposed fixes (but we're on JDT core version 3.4.5.v_895_R34x, JDT APT core version 3.3.101.R34x). For my workload referenced above, the only annotations used are the @SuppressWarnings flavor. If I take them out. The same workload builds fine with a peak memory usage (using a constrained heap for accurate GC data) at about 220MB. With the annotations in there, I get OOM with -Xmx1524m. (In reply to comment #45) APT, in its current implementation, requires an AST for every type being compiled; there's no other way to find out what all the annotations are. ASTs are big. It would be helpful if you could provide a sample workspace. There is very little we can do to help you without a specific example. Walter, do you need all ASTs together? If not, do we make sure that they get disposed/unreferenced when no longer needed? Maybe we also need to do a gc manually to make sure we don't run into an OOME. Is there an inherent requirement somehow that all the ASTs be live in memory during calling of the processors? As comments 19 and 21 pointed out, that is the main reason for the OOM (still building all the ASTs and haven't even gotten to the processing yet). Why is it that we can't load one, call the processors, release the AST and move on to the next? Is this a limitation in order to be Sun APT compatible? Would there be any way to limit the number of live ASTs? In my experiments, about 17 mb of Java source expanded to about 600 mb in memory. Perhaps we can get more mileage out of optimizing memory use during the AST creation rather than (if it's even possible) figuring out how to limit the number of ASTs for APT processing. Just brainstorming... (In reply to comment #48) > Is there an inherent requirement somehow that all the ASTs be live in memory > during calling of the processors? Indeed, that's the $64,000 question. I didn't design that part of the APT implementation. Knowing the people who did, it's hard for me to believe that they'd have done it that way if they didn't feel it to be necessary; I doubt it was done by accident. But it's definitely the next thing to take a close look at. The API that APT presents to processors allows them to ask arbitrary questions about types; not just questions about the types being processed at the moment. A processor can, for example, ask questions like "does the method I'm processing right now override any of the other methods with the same annotation". But operations on type bindings are only valid when the bindings were requested at the same time, or so I understand. My initial guess is that this need for all the bindings to be compatible may be the main underlying limitation. Hi Walter I tested the patch. It improved the compile time by 10%. But the memory issue is still there for APT processing Thanks Srinivas (In reply to comment #50) > I tested the patch. > It improved the compile time by 10%. > But the memory issue is still there for APT processing Would you have a chance to try the patch included in bug 285799? Thanks. I tested with the 3.6 nightly build and the memory issue is still there I got the August 23 build Thanks Srinivas Nothing has been done about memory yet; thus far we have only addressed speed (in particular, the problem with speed scaling nonlinearly). How did the patch affect your compilation time? I think with the speed improvement this bug should be closed as FIXED. A new bug should be open to address the memory issues. It is unrealistic to try to address these issues for 3.5.1. They should be investigated for 3.5.2 or only 3.6. AFAIK we have fixed the nonlinear scaling of compilation time. Compilation is still slower by a constant factor, but that is probably inevitable. If any of the people on the cc list would like to comment, please do so. If I don't hear back in a couple days that there is still a speed issue, I will close this and open a new bug regarding memory size. I agree it is highly unlikely we will be able to address memory size in 3.5.1. Closed per comment 54 and comment 55. Opened bug 288211 for discussion of the memory issue. |
A user on eclipse.tools.jdt reports extreme slowness when compiling his project if APT is enabled, even if the processor is implemented as a NoOpProcessor. An excerpt of the forum thread follows, followed by some console thread dumps taken during a typical slowdown. Note that although APT is enabled, the call stack is not inside a processor; rather, we're inside AST generation. I'm assigning this to JDT Core rather than APT, because I suspect someone from the compiler team will need to help troubleshoot. The problem may be incorrect use of JDT APIs by APT; reassign to APT as appropriate. Forum excerpts (edited together from several posts) [...] Until recently, where my IDE started becoming much less responsive. I didn't know what it was due to, until it became unbearable: now, saving certain files requires about 10 seconds. Turns out that disabling the annotation processing makes it recover its snappiness instantly. I did some basic profiling in my annotation processor, and found that my code was not the bottleneck. It executes, for a single file, in about a tenth of a second. Actually, even if I return AnnotationProcessors.NO_OP from my AnnotationProcessorFactory, saving is this incredibly slow. Here's typical stack traces of the two threads that are most active when compiling takes so long (see end of message -- and sorry for the long post!). Looks like newReconcileEnv and newBuildEnv, called by AptCompilationParticipant#processAnnotations, take a lot of time. I fail to see what would be the problem, though... I tried doing the annotation processing only on build and not on reconcile. I also tried returning an empty list for the supported annotation in the factory -- no luck, still takes ages to compile. My annotation processor doesn't generate source files. The slow files are the Java files which use my custom annotations, or (apparently) other Java files which cause those annotated classes to be recompiled. This happens when I save them manually from the Java Editor, or whenever it is rebuilding the workspace. I created a new workspace and imported all projects, copying them into the new workspace with the Eclipse import wizard. Compilation was slow immediately. There is nothing in the error log. Nothing on the terminal either. > Is it possible that the slowdown correlates with an increasing use of > annotations in your project? I think that when annotation processing is > enabled, the compiler (before it even gets to processing) has to scan for > annotations; I wonder whether that scan is bogging down? A couple of thread > dumps may help to answer that question. It looks like it could be an explanation... But I'm unsure about the interpretation of the thread dumps, though. Thread dumps: "main" prio=6 tid=0x09401540 nid=0xa046c720 runnable [0xbfffd000..0xbffff158] at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.analyseCode(MethodDeclaration.java:87) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:670) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:201) at org.eclipse.jdt.internal.compiler.ast.QualifiedAllocationExpression.analyseCode(QualifiedAllocationExpression.java:78) at org.eclipse.jdt.internal.compiler.ast.FieldDeclaration.analyseCode(FieldDeclaration.java:76) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:634) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:253) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:118) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:749) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:211) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:159) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1185) at org.eclipse.jdt.internal.corext.util.JavaModelUtil.reconcile(JavaModelUtil.java:544) at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:262) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditorBreadcrumb.getCurrentInput(JavaEditorBreadcrumb.java:646) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditorBreadcrumb.setInput(JavaEditorBreadcrumb.java:618) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.setBreadcrumbInput(JavaEditor.java:1908) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2168) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$EditorSelectionChangedListener.selectionChanged(JavaEditor.java:297) at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2575) at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2527) at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2506) at org.eclipse.swt.widgets.Display.runTimers(Display.java:3568) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3045) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=1 tid=0x094df0a0 nid=0x534eb600 runnable [0xb0b93000..0xb0b94d90] at java.lang.Object.hashCode(Native Method) at java.util.HashMap.put(HashMap.java:418) at org.eclipse.jdt.internal.compiler.CompilationResult.record(CompilationResult.java:355) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.record(ProblemHandler.java:191) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:162) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:179) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1830) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.rawTypeReference(ProblemReporter.java:5802) at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:157) at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:197) at org.eclipse.jdt.internal.compiler.ast.AllocationExpression.resolveType(AllocationExpression.java:240) at org.eclipse.jdt.internal.compiler.ast.Assignment.resolveType(Assignment.java:192) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:882) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:101) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:233) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:444) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:211) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:159) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206) "Worker-8" prio=5 tid=0x0946d8c0 nid=0x5340e800 runnable [0xb0c95000..0xb0c96d90] at java.lang.String.toLowerCase(String.java:2296) at org.eclipse.core.internal.content.FileSpec.getMappingKeyFor(FileSpec.java:57) at org.eclipse.core.internal.content.ContentTypeCatalog.getDirectlyAssociated(ContentTypeCatalog.java:468) at org.eclipse.core.internal.content.ContentTypeCatalog.internalFindContentTypesFor(ContentTypeCatalog.java:423) at org.eclipse.core.internal.content.ContentTypeCatalog.findContentTypesFor(ContentTypeCatalog.java:265) at org.eclipse.core.internal.content.ContentTypeMatcher.findContentTypeFor(ContentTypeMatcher.java:48) at org.eclipse.core.internal.resources.ContentDescriptionManager.getDescriptionFor(ContentDescriptionManager.java:322) at org.eclipse.core.internal.resources.File.internalGetCharset(File.java:260) at org.eclipse.core.internal.resources.File.getCharset(File.java:221) at org.eclipse.core.internal.resources.File.getCharset(File.java:208) at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:629) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8505) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:729) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:613) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:337) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) 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.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=1 tid=0x094df0a0 nid=0x534eb600 runnable [0xb0b94000..0xb0b94d90] at org.eclipse.jdt.internal.compiler.codegen.ConstantPool.literalIndex(ConstantPool.java:312) at org.eclipse.jdt.internal.compiler.ClassFile.completeCodeAttributeForProblemMethod(ClassFile.java:4391) at org.eclipse.jdt.internal.compiler.ClassFile.addProblemMethod(ClassFile.java:987) at org.eclipse.jdt.internal.compiler.ClassFile.createProblemType(ClassFile.java:195) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:500) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:581) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:345) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:755) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:211) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:159) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206) "Worker-8" prio=5 tid=0x0946d8c0 nid=0x5340e800 runnable [0xb0c95000..0xb0c96d90] at org.eclipse.jdt.core.compiler.CharOperation.indexOf(CharOperation.java:2115) at org.eclipse.jdt.core.compiler.CharOperation.indexOf(CharOperation.java:2062) at org.eclipse.jdt.core.compiler.CharOperation.replace(CharOperation.java:3156) at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.getLocalizedMessage(DefaultProblemFactory.java:150) at org.eclipse.jdt.internal.compiler.problem.DefaultProblemFactory.createProblem(DefaultProblemFactory.java:99) at org.eclipse.jdt.internal.core.CancelableProblemFactory.createProblem(CancelableProblemFactory.java:37) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.createProblem(ProblemHandler.java:91) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:135) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1808) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1871) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.missingOverrideAnnotation(ProblemReporter.java:4862) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:169) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:613) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:337) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) 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.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=1 tid=0x094df0a0 nid=0x534eb600 runnable [0xb0b94000..0xb0b94d90] at org.eclipse.jdt.internal.compiler.lookup.BlockScope.addLocalVariable(BlockScope.java:86) at org.eclipse.jdt.internal.compiler.ast.Argument.bind(Argument.java:58) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.bindArguments(AbstractMethodDeclaration.java:91) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:399) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:211) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:159) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206) "Worker-8" prio=5 tid=0x0946d8c0 nid=0x5340e800 runnable [0xb0c96000..0xb0c96d90] at org.eclipse.jdt.internal.compiler.lookup.ArrayBinding.erasure(ArrayBinding.java:138) at org.eclipse.jdt.internal.compiler.ast.Expression.computeConversion(Expression.java:567) at org.eclipse.jdt.internal.compiler.ast.MessageSend.computeConversion(MessageSend.java:121) at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.resolve(LocalDeclaration.java:193) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:444) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:191) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1096) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1184) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:535) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:743) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:613) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:337) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) 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.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "org.eclipse.jdt.internal.ui.text.JavaReconciler" daemon prio=1 tid=0x094df0a0 nid=0x534eb600 runnable [0xb0b94000..0xb0b94d90] at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:386) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1145) at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8505) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:729) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.ReconcileEnv.openPipeline(ReconcileEnv.java:108) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newReconcileEnv(AbstractCompilationEnv.java:97) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.reconcile(APTDispatchRunnable.java:211) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringReconcile(APTDispatchRunnable.java:159) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.reconcile(AptCompilationParticipant.java:223) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation$1.run(ReconcileWorkingCopyOperation.java:257) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:770) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1224) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:124) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.access$0(JavaReconcilingStrategy.java:108) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy$1.run(JavaReconcilingStrategy.java:89) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:87) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:149) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.reconcile(CompositeReconcilingStrategy.java:86) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:102) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206) "Worker-8" prio=5 tid=0x0946d8c0 nid=0x5340e800 runnable [0xb0c96000..0xb0c96d90] at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9236) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java:9598) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.parseStatements(MethodDeclaration.java:122) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.parseMethods(TypeDeclaration.java:802) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8513) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:729) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:613) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:337) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) 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.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "Worker-8" prio=5 tid=0x0946d8c0 nid=0x5340e800 runnable [0xb0c96000..0xb0c96d90] at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at org.eclipse.core.internal.filesystem.local.LocalFile.openInputStream(LocalFile.java:356) at com.ibm.team.filesystem.client.internal.ManagedFileStore.openInputStream(ManagedFileStore.java:804) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:642) at org.eclipse.core.internal.resources.File.getContents(File.java:298) at org.eclipse.jdt.internal.core.util.Util.getResourceContentsAsCharArray(Util.java:1140) at org.eclipse.jdt.internal.core.CompilationUnit.getContents(CompilationUnit.java:635) at org.eclipse.jdt.internal.compiler.parser.Parser.getMethodBodies(Parser.java:8505) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:729) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:697) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:474) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:736) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:856) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:613) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:337) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) 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.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)