Thanks for the memory

Thanks for the memory Some interesting points: 1: … When a JVM’s Java heap is swapped out, the garbage collector’s performance becomes extremely poor, to the extent that the application can appear to hang. If multiple Java runtimes are in use on a single machine at the same time, the physical memory must be sufficient…

Read more

Are you kidding me? JDK 6 in OSX

Finally, it’s starting to become slowly reality. Namely JDK6 is appearently default JRE in newest OSX version, which is just being published. Which means that we need to wait only 1,5 years until it is safe to base into using it (considering the fact that it takes some times to upgrade all the macs, and…

Read more

Tig Tag – The Code Review Editor

Inspired by Tick The Code. Small utility which allows doing code reviewing without printing it into paper. Screenshot (v0.37a): Old screenshots: TigTag (v0.3a) TigTag (v0.36a) Usage: Marking code: Hit ANY key or SPACE or CTRL+V WARNING: Current version (v0.3 Alpha) may contain various defects (Send email if you find any…), and file storage format may…

Read more

Random Points of Interest

Back to Basics: RMI Revisited | Javalobby Ghost in the Java Virtual Machine | Javalobby Optimising Computer Programs for Performance | Javalobby 5 Tips For Writing Interesting Technical Articles | Javalobby The Curse of the Swallowed Exception | Javalobby JSF Jumpstarter: Free PDF Book Download | Javalobby Why Many Java Performance Tests are Wrong |…

Read more

Advanced MultiThreading in Swing

Usually when multithreading in Swing is discussed, then authors are regarding trivial issue of using ”SwingWorker” and such constructs for running worker threads from EDT (Event Dispatch Thread”. However, Swing design includes one rather different multithreading thing. Namely it’s possible to start multiple AppContext instances, and execute multiple EDT threads in single JVM. So lets…

Read more

But It Works On My Machine…

But It Works On My Machine… As summary: difference between ”server” and ”client” JVM *can* cause big surprises in badly coded thread stop conditions. Additionally other random synchronized blocks can cause unpredictability in behaviour. I tested sample program, and there really was this big difference between ”-client” and ”-server”. Changing ”stopRequested” to be volatile caused…

Read more

Thread-safe state handling

As already known, you must known your synchronization strategy, ”crossing fingers and wishing nothing bad happens” or ”synchronization problems with primitive fields don’t occur” are simply not correct answers for thread synchronization. Tobe expressed: Thread-safe state handling

Read more