A.J. Côté

Ranch Hand
+ Follow
since Aug 19, 2015
A.J. likes ...
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by A.J. Côté

Roel De Nijs wrote:

A.J. Côté wrote:If not, add more memory consuming code to give an opportunity to the jvm to call finalize() before your program terminates. This is how finalizers work.

That's a very nice example, but it still doesn't cover the unpredictability of this method being executed or not. And you could add all the memory consuming code you want, but if your program uses/relies on finalize() to get some task done and GC doesn't kick in, you're toast! So why spend time in implementing a method of which you have no guarantee it will be executed at all

As explained here, it is a nice to have safety net:
8 years ago

Roel De Nijs wrote:

A.J. Côté wrote:It is typical to ALWAYS use finalize to make sure a connection, thread or anything poolable is returned to its pool when there is no more reference to the wrapper object wrapping the real poolable object, more precisely when the jvm decides it is time to call finalize on the wrapper object because there is no more reference pointing to it.

Typical You have to be kidding! I've been developing Java applications for over more than 10 years and have NEVER used the finalize() method. Maybe once or twice in some test code to confirm how unpredictable this method really is. And to prove how unpredictable this method really is, here is a very simple code snippetWhen I run this application on my computer, I expect to see 10x "in finalize", but there was no output at all. When I incremented the number of iterations to 1000, 10_000 and even 100_000, still no output. When incremented to 1_000_000, a bunch of "in finalize" were printed (but definitely not 1_000_000). When you run this on your own computer, the results might be different.

Here, try to run this code, it should give you the results you expect! If not, add more memory consuming code to give an opportunity to the jvm to call finalize() before your program terminates. This is how finalizers work.

8 years ago
Are you aware of so_linger?

Are you sure this didn't occur before and how do you tell tomcat really keeps database connections open? Perspective is important here,,,

Did you switch OS as well when migrating to tomcat?

When the above are checked; tomcat has to tell the pool to release resources somehow when it shuts down. Please check the above issues first although.

8 years ago
Static fields and methods inheritance shows really strange behaviour. Static is not meant for inheritance. As a rule of thumb, always refer to static fileds and methods by prefixing them with the class name, e.g. MyClass.getX(), MySubclass.getX(). This should make everything clearer.

Vineeth Vasudevan wrote:OnLoad Javascript*

actually, one of the brightest webdev I have recently showed me that you can now replace onload= with:

I found it, and I still find it much more flexible than onload.
8 years ago

Also keep in mind that, nowadays, writing multi-threaded apps has become the swiss knife of the java environment. It is much likely comparable to the ability to write shell scripts with an added grain of multi-threading capabilities.
8 years ago
No probs Ben bro.

As Bear mentioned before; multithreading skills are less required nowaday although they are essential to the survival of the race. Let me know what you come up with please.

8 years ago