We Keep Coding

Eclipse unable to clean build output

I have an Eclipse (4.4.1) working set consisting of ~60 projects (the number may be relevant, as it takes more time to refresh the workspace). Occasionally, I encounter build failures because Eclipse is unable to clean the output folder before build:
It turned out that the process which locks the file is Eclipse itself:
It also turned out that files being locked are always of XML content. Particularly, if I define resources with *.foo extension as XML files (via Preferences -> General -> Content Types), there's a good chance they will be locked, too, once they're copied to the output path.
I thought the problem was caused by all XML resources being validated automatically:
-- so I added exclusion filters 1st and even disabled XML/XSD validation entirely. The problem stopped occurring that often, but still emerges from time to time. Refreshing or closing-reopening a project isn't helpful.
The only remedy is restarting Eclipse or running Unlocker every 1/2 hour, which is not very convenient.
Any ideas how to solve or at least further diagnose this?

Just my 2 cents.
Perhaps you can fix this issue by following this steps:
Project -> Properties -> Builders -> New -> Program
Define a custom "Cleaner"-Program, for example Unlocker or your own Java- or CMD-script
Move your custom Builder-Program up. It should be the first Builder in the list
P.S. some times i have similar problems caused by Avira Antivirus Scanner...

Disable third-party version control daemons. (Like TGitCache).
They only lock resources for a short while and are not visible in Process Explorer, but are the most frequent cause of such failures.

Assuming that XML Validation is the main cause of your problem, I suggest you extend your search for validation points in your projects' configuration, to set off all of them:
General preferences/Validation
General preferences/XML/XML files/Validation (the "honour all schema locations" option might be causing delay at validating)
Project preferences/Validation (check them; might be overriding the general preferences)
Project preferences/Builders/Validator
Hope it helps.

I have experienced similar issues. Yes, the number of projects is probably the cause. Close the projects not in use. If that cleans things up moving groups of related project into separate work spaces should help you out.
i.e File-> Close project

I'm not familiar with the problem, but I would tackle the problem this way:
download File Leak Detector
add the agentpath to your eclipse.ini (e.g.,
-javaagent:path/to/file-leak-detector.jar=http=19999, see documentation of File Leak Detector)
when the problem happens again, see which (eclipse) class is responsible for holding a handle of the file
Find out what is the purpose of the class that holds the handle
This way, you are maybe able to pin down the Eclipse feature that causes your problem.

Recover corrupted java file

I tried to reimport my android project on eclipse to solve a problem but I accidently overwrote all my files in the project. All of them had been corrupted which means their size is now 0B...
I tried to use Local History but it's useless since my project is no longer in my workspace, same for .metadata.
I also tried to use Recuva (Software for recovering files) which see my files with their real size but when I try recover them, their size is always 0B...
I lost about 7 days of work and I don't really want to rewrite my code using Java Decompiler...
So my question is, is there any solution to recover that files ?

I wrote 200 lines of code and suddenly system restarted. I lost all code. But I recovered data from eclipse's local history. Right click on the file -->replace with-->previous from Local History

Eclipse has a local history, although by default it's set very low - one of my first tasks when setting up a new development machine is to up the values (in addition to my other version control)
If you do have a history you can right click on your class, and select compare with local history.

You could try decompiling with something like JD-GUI. It might not be as onerous as you think. Obfuscators exist for a reason.

It is not really programming question, but i had similar situation and "Mini Tool Power Data Recovery" tool helped me (it is paid tool, free version exists, but maybe you can search in this direction and find something open source). I tried some another tools then, but with no results.

Mirth Running Old JAR File Code

This is really driving me crazy. No matter what I do, it seems that Mirth (1.8.2) is running an older version of my JAR file; I know because of various signs, like:
I can't call any functions
Information logged is not showing up in the logs
Changed log messages are not changed in the log files
Files that were once created and written to in code, but no longer touched by code, are still being created and written
I've tried everything I can think of to make this work. It was working at one point, but now it seems like it's no longer being updated. My process to integrate my changes into Mirth are:
Run an ant script to build the JAR file
Copy the JAR file to \lib\custom
Restart the Mirth service (via Mirth administrator)
I've tried restarting (Mirth service via Services, Java, computer) -- to no avail. I know my JAR file is correct, because I've decompiled it (to make sure it has the latest code) and hashed it (to compare to the hash of the ant-built JAR) -- it is correct and the code is there; it's just not being run.
I'm at wit's end; this occurs infrequently but completely blocks me from developing.
Edit: I also know that my code is correct, because when I run unit tests, it generates the right files and calls the right functions and logs the right information. Only Mirth seems to "not get it."
And my classes are very simple; simple one-argument constructors and a few public methods that return various data. Nothing complex, no nested classes/JARs/dependencies.
Edit: I even deleted my custom JAR file and restarted Mirth, and it's still running my code. Awesome :/ I've added a bounty for this question. I suspect the JAR is cached somewhere (even though they deny it on the Mirth forums) and that cache needs to be cleaned out somehow (although why restarting the Mirth service and my PC doesn't do it is beyond me).
I've also killed all instances of Java (and rebooted my computer), so that makes it highly unlikely that the JVM is caching the JAR somewhere.
I tried reinstalling Mirth. For some reason, it had my custom channel when I booted the administrator for the first time; and infuriatingly, it's still running the old JAR, even though I've updated it with the new one in lib\custom.

I ended up solving this with a combination of actions:
Uninstalling Mirth and Java, and then reinstalling.
I also removed all Java installations except one (one JDK and one JRE).
I stopped Mirth when you copying my JAR. Stop Mirth, copy, and restart; don't try to copy on a live installation. It may or may not pick up your updated JAR depending on if it's loaded into a JVM or not.
This combination of steps seemed to work. Prior to this, I had 3-4 JREs installed (and two JDKs) and I was copying (successfully, according to Windows 7) the JARs while Mirth was running. It's working now!

Mirth is a J2EE application running on a plain old JVM; you have options for debugging it.
You could follow the instructions here for running Mirth Connect via Eclipse. You could then see the JVM classpath, you could set breakpoints and use the debugger.
Mirth is based on the Mule ESB. Mule has its own way of class-loading. You could research it.
If Mirth is really using an old version of your JAR, maybe it's got a cached version around somewhere. Or maybe you made some configuration changes you've forgotten about - perhaps you added a new directory for jars. (Not sure how you do that.)
Mule pays attention to an environment variable named MULE_LIB; maybe that's relevant.
It looks like Mirth Connect 1.8 and Mirth Connect 2.0 have different places for jars (lib/custom and custom-lib, respectively). Which version are you using?

Why does GWT sometimes successfully compile and other times just stall?

I am working on a demo for a client of what's possible with GWT-Ext for GWT. After browsing for the simplest way to get up and running, I decided on installing the Google Plugin for Eclipse and using the New Web Application Wizard.
First time around, I followed these steps for create the default application:
Selected File > New > Web Application Project from the Eclipse menu.
In the New Web Application Project wizard, entered a name for the project (ExtDemo) and a java package name, com.extdemo.
Unchecked the "Use Google App Engine" check box.
Clicked Finish.
Right clicked it in package explorer and selected Run As > Run Configurations
Put a check in the Automatically Select Unused Port checkbox.
Clicked Run to see the default GWT 1.7 application
This worked fine... it launched GWT's hosted browser and the app worked as supposed to.
(I then continued to import GWT-Ext and add all sorts of widgets building up a nice little demo app)
However at some point when relaunching the app in hosted mode, the hosted browser displays an empty iframe. I even reverted the code to a point where everything was working as supposed to and... same thing, an empty iframe with the surrounding static content.
Now what is really strange is when I go through the process of creating the default application again by following the steps above, the hosted browser launches with an empty iframe again.
However when I click on Compile/Browse, this sometimes allows the app to launch in Firefox.
Anyone have this happen to them?

I have seen some odd behaviors occasionally. Here are some basic suggestions (some are dumb and you might have tried them already):
Use a new workspace
I do not know if GWT plugin somehow caches stuff in the embedded Jetty. If you are re-creating the default app/project, try and use a different name for the project.
Try and re-use a fixed port so that there is no possibility of having multiple servers running.
Update: Found a new "classic" solution:
Delete the cache in IE and possibly Firefox too. Apparently the 'script' tag content tends to be cached by IE. If this works, we can all try tearing our hair out!
Found the updated answer at this link:

I have had the same problem in the past and found it is much more likely to happen if limited CPU is available. For example if my older laptop was running on battery and had stepped down the CPU speed to save power it frequently happened. When running on mains in max performance mode it only happened occasionally. Now I have a much newer and more powerful laptop and the problem has gone away.
Another cause I found was too many breakpoints set up in eclipse and removing breakpoints would often clear the problem.

I've had issues with the browser caching.
Try clearing your browser cache, refresh a few times after a failed load, etc.
You can also try using a different port so the URL is different.
It takes some time to download and run the GWT app, particularly if you are using extra libraries, so wait for a few seconds to see if the app finally loaded.
What makes the app loading to fail randomly is something I don't know yet, but I suspect, as stated by Daniel Vaughan, that is related with a lack of computer resources, CPU, memory, etc.

Exporting EAR file in Eclipse taking long time

I'm working on a project on Eclipse, more specific RAD build. The EAR file exported is around 40 mb, last week it was taking 1 minute, today its taking more than 10 minutes.
I didnt change much code, nor changed any config related to the JVM.
I export directly from RAD, right click on the project and export EAR.
So whats going wrong?

Thoughts:
Clearly something is different. What could it be?
Your app: Could you now have lots more little graphics files or some such?
Your app: could you be referencing some external resource eg. XSDs from somewhere remote, is it generating code at this point with some such reference?
Environment: Disk drive. Are you exporting to some nearly full disk? Or a network drive that's suddenly really slow, or somehow a revision control system is trying to adopt what you are exporting.
Environment: Memory. I've seen Eclipse get stupidly slow when paging is happening. Could you just have increased your memory usage a tad or now be running something new in the background?
As none of those apply (you really sure?) then I would do this:
take the app to another workspace
take the app to another machine
Break the app down to pieces, binary chop until you find what the expensive bit

The problem is fixed, im not sure which of these fixed it, but one of them did:
The output folder was shared on the network, stopped the sharing
Defragmented the disk
Emptied the Recycle Bin (it had almost 5 GB)
I made them all together, so i not sure which solved the problem, but i suspect one of the first two.
It was a an OS problem, nothing to do with Eclipse.