JTable row resizing using ..JxLayer

A common usecase for a JTable is to  manually resize rows .  One  solution  googled was   Make JTable Resizable

It works fine with a couple of drawbacks..

• If the CellEditor gets activated on mouseMove(as in my application) the mouse events will be consumed by the editor component , and the table mouseListeners(for  Dragging) will Not be notfied.

• Working around the problem of rowSelection,when resizing ..needed the underlying table to be modified.

This seemed a perfect usecase for JxLayer

• Get all MouseEvents from any component parented by the underlying Table.

• Lock the UI on MouseMove & prevent the RowSelection in the table from changing(on mousePressed).

The class RowResizerUI extends LockableUI(from JxLayer) &  provides  row resizing for the underlying table.

Link to Src

Java Swing Application ‘Always on Top’

Since the last few weeks  , our  Java Swing Client  sporadically..seems to set itself  on top of every other windows application.  As things always happen, the problem was occasionally reproducible by our testing team, but  not  by our development team..but it was a big problem for our clients to have their numerous window apps  open behind our Swing app.

So finally I decided to investigate further ….a cursory search in the Sun Bug Database took me to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6829546

which explains the issue wonderfully….and the best  part was that  it was always Reproducible !

The bug states that  ‘Modal dialog causes the underlying parent JFrame to be set to Always on top’. Here are the steps to reproduce the bug

1) Open a JFrame (note the "alwaysOnTop" is not set to true).
2) Spawn a Modal Dialog with 'Always on Top' , From the Frame
3) While the dialog is open ,click on the underlying Frame (nothing happens as modal dialog is blocking it).
4) Now close the dialog and suddenly the parent JFrame is now set to be always on top. It won't happen if  the parent Frame ,was NOT clicked on while the dialog was open.

The worst part of the bug is the fact that ‘Always On Top’ property of the Frame is false although the Frame itself is visually always on top.

One workaround as mentioned is to ..

setAlwaysonTop(true)..followed by….setAlwaysonTop(false) , on the Main Window whenever a modal dialog closed .

This bug seems to have crept in only after JRE 6 Update 11  , and was submitted in early April… Hopefully it would get fixed in the upcoming releases …..

Visual VM …Saved My Day

Last week I found myself dealing with the issue , of my Java application repeatedly freezing  …i guessed it could be due to a thread deadlock but wasn’t exactly sure which part of my code was the cause.  Since I already had a license of a Commercial Java Profiler  I  thought things would be easy..but unfortunately the profiler didnt seem to auto connect to my running vm unless I explicitly gave it  the  port no.

Having heard a lot about Visual VM , I decided to give it a try and was surprised to find that it auto detected my running vm on startup and gave a brief summary of the vm properties.

The next thing I did was to take a thread dump of my application and analyze it for any deadlocks..and Visual VM saved my day here ,by auto detecting the deadlock from the Thread Dump .The explanation given..was quite clear and helped fix the dealock issue.

Once this critical issue was fixed I decided to see what else Visual Vm had to offer and have listed some of its interesting features :

1) Get a Performance Overview of the entire application..like the no of Live Threads ,Classes Loaded ,Heap Memory usage in the Monitor Tab.  The Threads tab in turn allows a deeper insight  into all the system and user threads.



2) Profile the memory usage of an application using the Profiler Tab.  This view  allows us to profile  objects of  the classes that we are interested in..and shows the size & No of Live Objects. We can also take a snapshot of the profiler output to analyse further and either save it as an image or a custom .nps format .

3) Profile the cpu usage of an application using the Profiler Tab. This view basically shows the method invocation count and time taken for execution. Again we can filter based on the methods names that we are interested in.

4)  The Ability to Compare Profiled Memory Snapshots,from the File Menu,  is another very useful feature..which helps to analyse the memory usage of the application ,taken at various stages.

---

A few features which I felt , could make VisualVm much more complete , in order of preference are :

1) Automatic Deadlock Detection and Notification of a Running application at any point during its lifetime, without having to explictly lookup its Thread Dump.

2) Finding all paths to a given Object from the various roots would help in fixing memory leaks much more quickly , than having to find it manually.

3)  Graphical Representation of the profiling results in realtime would be much easier to comprehend over a long period of time, than having a tabular display.

4) An option to freeze all the views for the currently profiled application,instead of taking indivisual snapshots of the views.

---

Conclusion:

Java VisualVM combines several monitoring, troubleshooting, and profiling utilities into a single tool and is extensibe using the Visual VM Entry Points. Most of the functionality offered by the standalone tools  such as jmap, jstat and jstack have been integrated into Java VisualVM. The best part is  that it is open source &  since JDK 6 Update 7  ,has been bundled into the standard JDK as ‘jvisualvm.exe’ .

Showing Progress without blocking the Entire application

A very common usecase  in Gui applications is to show an indeterminate progress bar whenever there is a long running task. Tasks can range from short ones such as data fetch to long ones such as a data migration or complex computations. In case of long running tasks it makes sense to show progress, but at the same time allow the user to perform other actions or work on other screens parallely ,within the application.

Swing allows us to achieve this functionality rather easily.

The demo below shows this functionality.

The overlay progress is shown whenever the tree is expanded and the nodes are loaded using swingworker, while u can continue to work on the table on the right .

The OverlayProgressContainer component enables us to do just this.

1: It makes use of the lesser known but very helpful Overlaylayout to stack components .
2: It has 2 children
a) User defined panel added as the bottom most child
b) GlassPanel added as the top most child .This panel shows progress using the JxBusyLabel and blocks keyboard(using KeyEventDispatcher),mouse events on the user defined panel .

3: The glasspanel is registered as listener to a swing worker and shows the progress based on the states(‘started’, ‘done’) of the swing worker

To make use of this component
1: Set the user defined panel using setDecoratedComponent(JComponent component)..
2: Set the swingWorker so that glasspanel can registered itself using setSwingWorker(SwingWorker worker)
Note: SwingWorker can be used only once and hence has to be created again once it has finished executing.

Link to Sources