Francesc Martinez

Thanks Jan!
This problem was driving us crazy!

Any idea?

I read Head First Design Patterns a few months ago I I think it is an excellent book. It explains not only patterns but also why they are good, based on some recommended basic rules (don't repeat code, hide the implementation ie. program to interfaces, etc). I highly recommend you to re-read that book and pay special attention to the reasons for the patterns.

Because HashXXX classes uses hashCode() to find objects.

Javadoc in these classes should explain something about that. I also highly recommend the book "Effective Java" for this and other important matters.

You can look for information about hash tables. How they work, how objects are indexed using the "hash code" for quick access.

Hello,

I've come across this situation where I need to use a method with generic return type inside a for-each (enhanced for) loop.

The generic method is this:
/** Returns an Iterable for a IDfList */ public static <E> Iterable<E> getIterable(IDfList list) { return new IterableIDfList<E>(list); }
Then, I can use it this way:
Iterable<IDfCopyNode> copyNodes = DfcUtil.getIterable(copyOp.getNodes()); // Infers the return type for ( IDfCopyNode node : copyNodes ) ...
But I can't inline the copyNodes variable:
for ( IDfCopyNode node : DfcUtil.getIterable(copyOp.getNodes()) ) ... // WON'T COMPILE; doens't infer type
To do it, I must explicitly put the generic type:
for ( IDfCopyNode node : DfcUtil.<IDfCopyNode>getIterable(copyOp.getNodes()) ) ...
Do you know why? Shouldn't the compiler infer the generic type in the for-each like in the simple assignation? After all, I suppose the for-each loop performs a simple assignation behind the scenes.

Thank you!
Fran

Jaikiran Pai wrote:

Jaikiran Pai wrote:Windows OS has some known issues with this kind of file locking.

See this and the JDK bug referenced in that blog.

Great article, thank you very much!

By the way, I'm using Windows (although the article says it will happen also with UNIX).

Paul Clapham wrote:

Frank Martin Carl wrote:I've developed a simple JarFileLoader using URLClassLoader.
Now I would like it to reload new JAR files and free the old ones, but it seems URLClassLoader locks the JAR files and won't release them until the JVM is closed.

In the application I use which does that, this is the process they use: they watch for changes in the JAR file. When they see one, they copy the JAR file to a temporary directory and use that, I assume via a URLClassLoader. That way they don't care whether the temporary copy remains locked after they stop using it.

Great idea Paul, thanks!

The only problem is those temporary copies will be locked. But it's the best solution I've seen so far.

Ernest Friedman-Hill wrote:Frank,

Since JarClassLoader is your own class, we can't vouch for how it behaves. Does it open or close jar files for reading by itself? Or does this happen only in the parent URLClassLoader? Maybe we could see the JarClassLoader code.

Here is the code:

import java.net.MalformedURLException; import java.net.URL; import java.net.URLClassLoader; public class JarClassLoader extends URLClassLoader { public JarFileLoader() throws MalformedURLException { super(new URL[] {}); } public JarFileLoader(ClassLoader parent) throws MalformedURLException { super(new URL[] {}, parent); } public void addFile(String jarPath) throws MalformedURLException { addURL(new URL("file", null, jarPath)); } }

Ulf Dittmer wrote:It seems that that should work. Of course, it only would work if the classloader really did get garbage-collected. Try calling System.gc() 5 times in a row, then putting the thread to sleep for a few seconds, and then try to delete the file. That might give the JVM some extra time and inclination to perform a GC.

Hehe, that seems like a witch recipe!
I'd like to find something more "scientific".

Anyway, I'll try it. Thanks!

Ulf Dittmer wrote:

But, how can I discard the classloader? Setting it to null doesn't work: jar files are still locked.

This may go without saying, but you also need to make sure that all classes that have been loaded through that classloader are also eligible for garbage collection (meaning that none of their objects are still referenced from anywhere in your code, like in a collection).

That's not the problem, I think. I've written a small program where I create a URLClassLoader, I add a jar to it and then load a class from that jar (I just call loader.loadClass(), ignoring the returned class and not instantiating it). Then, after nulling the URLClassLoader... the jar file is still locked.

This is pseudocode of what I did:

loader = new JarClassLoader() loader.addFile("some.jar") loader.loadClass("some.Clazz") loader = null

Now, before exiting the program, I try to delete "some.jar", but it's locked!

Ulf Dittmer wrote:This may be more work than you want to embark upon (although it pays back in the long run), but this sounds like a perfect application for an OSGi container like Apache Felix.

I don't know much about OSGi; I've read it's about services.

Do you mean I could start a service (with some jars) so later I could restart that service (when I need to update the jars)?

Ernest Friedman-Hill wrote:Since the very beginning of Java, there has been one way, and one way only, to unload a class: by discarding the ClassLoader that loaded it. Normally, this works just fine. For example, when a servlet container reloads a web app, it discards the classloader that originally loaded that app, creates a new one, and loads it anew. So that's basically what you need to do.

But, how can I discard the classloader? Setting it to null doesn't work: jar files are still locked.

Hello,

I've developed a simple JarFileLoader using URLClassLoader.
Now I would like it to reload new JAR files and free the old ones, but it seems URLClassLoader locks the JAR files and won't release them until the JVM is closed.

I've read that, In Java 7, they're going to add the Closeable.close() method to URLClassLoader but, in the meantime, as to Java 5, is there any way to release the loaded JAR files? Or do you know any other class/API that lets you do it (from Apache perhaps? They need to do it in Tomcat!).

Thank you very much!!!

Just a few suggestions:

In the exam:
- There's plenty of time for the exam, don't worry about it. But... (see next)
- Don't waste time checking your answers: read carefully the question and the answers (the answers are a clue), write down the program in a piece of paper if it helps you (I did it many times), answer the question and forget it, or mark the question if you want to check it later, but don't do it with all the questions or you'll run out of time (I know a fried that had this problem).
- You can't re-open drag&drop questions without loosing the answer, so answer them and forget them. They're not very difficult, anyway.
- There are easy questions, so when you find one don't suspect there must be a trap somewhere (I thought it!).

Before the exam:
- Read the SCJP Study Guide.
- Do practice exams (Study Guide, LearnKey, Whizlabs, whatever), the more the better; it's not enough to be a Java expert.

Hello,

Some Java experience is of great help.
Also, I read THE book: SCJP Study Guide for Java 6. And did its questions.
Also, I took some LearnKey exams (included with that book), Whizlabs exams and some other free exams (can be found in this site).

LearnKey and book questions are difficult, often misleading. Whizlabs is easier and still a little harder than the official exam.
The official exam doesn't have misleading questions; I mean, for example, questions that seem to talk about exeptions when the problem is an unitialized variable. At least, I don't remember any of those. Also, I don't remember questions where the problem is that they "forgot" to put a try/catch or a throws when calling a method (e.g. Thread.sleep()).

There are not many tricky questions in the official exam, but I remember one. It was similar to this one: System.out.printf("%b %b %b", 3.14, 0, null);
Another tricky one: Mark the JavaBean compliant methods (only 2): addMouseListener, addListener, removeMouseListener, deleteMouseListener, registerMouseListener.