Francesc Martinez

Greenhorn
+ Follow
since Feb 13, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Francesc Martinez

Thanks Jan!
This problem was driving us crazy!
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.
12 years ago
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.
12 years ago
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:

Then, I can use it this way:

But I can't inline the copyNodes variable:

To do it, I must explicitly put the generic type:

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
12 years ago

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).
13 years ago

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.
13 years ago

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:

13 years ago

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!
13 years ago

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:



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

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)?
13 years ago

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.
13 years ago
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!!!
13 years ago
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.


13 years ago
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:
Another tricky one: Mark the JavaBean compliant methods (only 2): addMouseListener, addListener, removeMouseListener, deleteMouseListener, registerMouseListener.

13 years ago