We Keep Coding

Java Swing - GUI not refreshing or freeze after java 1.8 updates

I have a working application, which working fine in Java 1.6 and 1.7 and even 1.8 update 31. I just update my Java today 1.8 update 45 and found my application interface having issue. For an example:
This is my working application screen. This is what it should be, but after the update its become like this (below):
Once I get the not functioning interface, I need to click on the area or I need to minimize the application and open again to revert back to normal.
Code
frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
tab.setTabPlacement(2);
frame.add(tab, BorderLayout.SOUTH);
ComparePanelMin cmp = new ComparePanelMin();
tab.add("Compare", cmp);
ReportPanelMin rp = new ReportPanelMin();
tab.add("Reporting (For Single Compare)", rp);
ChangeListener changeListener = new ChangeListener() {
#Override
public void stateChanged(ChangeEvent changeEvent) {
idx = tab.getSelectedIndex();
}
Above code to switch between the tabs. Any advice or reference links is highly appreciated.
EDITED
DeadLock

I guess its an issue of deadlock I faced a similar issue of GUI freezing with Swing. Nothing worked out so I had to dig into the code of Swing and I found some really crappy codes which were causing the dead lock and it was very difficult to trace even in the thread dump.
you can try these tools and check for dead lock
http://docs.oracle.com/javase/7/docs/technotes/guides/management/jconsole.html
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/jvisualvm.html
you can search how to identify dead lock using these tools
Also the way you're adding tab in frame is not the right way you should add it using frame.getContentPane().add(tab, BorderLayout.SOUTH)

I have seen similar issues if not all Swing components are created on the event dispatch thread (EDT).
Make absolutely sure that even your initial JFrame is created/shown from the EDT:
public class HelloWorldSwing {
private static void createAndShowGUI() {
JFrame frame = new JFrame("Hello Swing");
// Your init code here...
frame.setVisible(true);
}
public static void main(String[] args) {
// Schedule creation of UI on the EDT
SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
}

Impossible Java Memory Consistency Error

first of all I'm not an English native speaker so I apologize for any eventual “weird” writing.
I'm developing a Swing Java application on Eclipse that updates a Jpanel. This panel contains several sub-panels, and I'm constantly switching the panels “modes”, what happens to be a MouseListener changing so they respond in a slightly different manner to the user mouse inputs.
Regardless of what the application do, it's happening an error that seems to have no logical explanation to me. At some point in my code I try to update the panels to what I called neutralMode. This happens on the following method:
//Guarded block (see http://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html)
private synchronized boolean waitsForUserSatisfactionAnswer()
{
while(!userIndicatedSatisfaction)
{
try {
wait();
} catch (InterruptedException e) {}
}
userIndicatedSatisfaction = false; //reset for future new query
getObjectSetVisualizationPanel().neutralMode();
//getObjectSetVisualizationPanel().queryPatternMode();
return userSatisfied;
}
This updating doesn't work (the call to neutralMode() dont do what is expected). However the call to queryPatternMode() (commented on the line right below) works perfectly. So I decided to COPY queryPatternMode()'s body and PASTE it on neutralMode()'s body ECXATLY THE SAME! AND IT STILL DOESNT WORK!
The methods code is like this:
public void queryPatternMode()
{
System.out.println("Inside queryPatternMode!!!");
System.out.println("panels.size(): " + panels.size());
for (DigitalObjectPanel panel : panels)
{
System.out.println("Inside the loop!!!");
panel.resetBehavior();
panel.setQuerySelectionBehavior(gui);
SwingUtilities.invokeLater(new Runnable() {
public void run() {
panel.validate();
}
});
}
}
public void neutralMode()
{
System.out.println("Inside neutralMode!!!");
System.out.println("panels.size(): " + panels.size());
for (DigitalObjectPanel panel : panels)
{
System.out.println("Inside the loop!!!");
panel.resetBehavior();
panel.setQuerySelectionBehavior(gui);
SwingUtilities.invokeLater(new Runnable() {
public void run() {
panel.validate();
}
});
}
}
What happens is that, when I call neutralMode(), the “panels” collection happens to be empty (panels.size() equals zero). However when I call queryPatternMode() instead, the collection happens to have it's expected size (20 panels). But both methods are equals, and both are called from the same place!!!
What it could be??? Is there any possible explanation for that??

It definitely looks like a synchronisation issue. You should check how many threads are accessing the collection 'panels'.
It is just a stroke of luck that it works for you with queryPatternMode() all the time, and not with neutralMode(). On another fine day, it might be other way around.

Multiple JFrame application, how do I bring them all to front together?

My users like having multiple JFrames; it allows them to resize the different components and place them wherever they want on the screen. However, I have a request to make all the child windows come to the front together... in other words, lets say they maximize another window in front of all the windows, and then use the task bar to click on just one of the JFrames. How can I set it so that they all come to the front? Note: it is also possible to close the child windows; if they are actually hidden, I do not want them to come to the front. I have a class ApplicationModel that keeps track of whether a window is hidden or not.
Things I've tried:
Using windowActivated() and focusGained() to try to bring them all to the front. This usually results in an infinite loop. The problem is that my eventing framework sends these requests off the Event Dispatch Thread, so any sort of blocking with an AtomicBoolean doesn't last long enough.
The main problem is not that I can't make them come to the front... I have made them come to the front. The problem is that they KEEP trying to come to the front, as bringing a window to the front throws the focusGained and windowActivated events, which creates an endless loop...
Making one window the master, and making the others a JDialog. Unfortunately, either the windows are modeless (and therefore don't come to front with the master window), or they are modal, (and therefore block the master window).
How can I fix either of these problems, or is there an entirely different third solution?

You can use a boolean field as a flag to prevent the infinite loop:
private boolean movingAllFramesToFront;
public void windowActivated(WindowEvent event) {
if (movingAllFramesToFront) {
return;
}
movingAllFramesToFront = true;
List<Frame> frames = getAllApplicationFrames();
for (Frame frame : frames) {
if (!applicationModel.isHidden(frame)) {
frame.toFront();
}
}
event.getWindow().toFront();
event.getWindow().requestFocus();
EventQueue.invokeLater(new Runnable() {
public void run() {
movingAllFramesToFront = false;
}
);
}
Another thing you can try is the new autoRequestFocus property introduced in Java 1.7. I have never tried using it, but here's my understanding of how it works:
public void windowActivated(WindowEvent event) {
final List<Frame> frames = getAllApplicationFrames();
for (Frame frame : frames) {
if (!applicationModel.isHidden(frame)) {
frame.setAutoRequestFocus(false);
frame.toFront();
}
}
EventQueue.invokeLater(new Runnable() {
public void run() {
for (Frame frame : frames) {
if (!applicationModel.isHidden(frame)) {
frame.setAutoRequestFocus(true);
}
}
}
);
}

I have an application with a lot of windows and had a problem similar to yours. My workaround is:
#Override
public void windowActivated(WindowEvent e) {
if (e.getOppositeWindow() == null) {
//front every window
}
}
First I created a class "SlveFrame" (Slve being the name of my app), a child of "JFrame".
public class SlveFrame extends JFrame implements WindowListener {
static ArrayList<SlveFrame> frames = new ArrayList<SlveFrame>();
public SlveFrame () {
addWindowListener(this); / /to make JFrame fire WindowListener's method
}
/ /... every method added from WindowListener
#Override
public void windowActivated(WindowEvent e) {
if (e.getOppositeWindow() == null) { // return null if window is not from my (or Your) work
for (SlveFrame frame : frames) { // if you have no idea what this is, look for "for each loop java" in google
frame.toFront();
}
}
}
/**
* The use of SlveFrame is almost the same as Jframe
*/
#Override
public void setVisible (boolean b) {
if (b)
frames.add(this);
else
frames.remove(this); // may raise an exception if you're not careful
super.setVisible(b); // or your window will simply not be visible.
}
#Override
public void dispose () {
frames.dispose(this) // may raise an exception you'll want to handle
}
}
The trick being that WindowEvent.getOppositeWIndow() returns a Jframe if the JFrame (or child class) is from your own program, meaning that if you switch to another program or app (such as eclipse, Firefox or a text editor) then back to any of your windows, then a call to getOppositeWindow() will return a 'null'. A simple if (e.getOppositeWindow()) makes it fairly easy to determine whether your window gain focus in condition that would require you to bring every window to the front, or rather to let everything be.
The overriding of setVisible (boolean b) and dispose () are optional but allow the dev to use it as a regular window.
I hope i could be of some help. Sincerly ~a lama

Setting text on jLabel using setText is delayed

I was building a small test tool with Java Swing using Netbeans IDE.
I am trying to update a label, which is somehow not getting 'repainted'/'refreshed'. I looked into a couple of similar questions on SO but was not able to resolve my problem.
private void excelFileChooserActionPerformed(java.awt.event.ActionEvent evt)
{
if(!JFileChooser.CANCEL_SELECTION.equals(evt.getActionCommand()))
{
String selectedFile = excelFileChooser.getSelectedFile().getAbsolutePath();
loaderLabel.setText("Please Wait..");
try {
//This is sort of a blocking call, i.e. DB calls will be made (in the same thread. It takes about 2-3 seconds)
processFile(selectedFile);
loaderLabel.setText("Done..");
missingTransactionsPanel.setVisible(true);
}
catch(Exception e) {
System.out.println(e.getMessage());
loaderLabel.setText("Failed..");
}
}
}
loaderLabel is a JLabel and the layout used is AbsoluteLayout.
So, my problem is "Please Wait..." is never shown. Although call to the method processFile takes about 2-3 seconds, "Please Wait..." is never shown. However, "Done..."/"Failed..." are shown.
If I add a popup (JOptionPane) before the call to processFile, "Please Wait.." is shown. I am not able to clearly understand why this is happening.
Is there a "good practice" that I should follow before a heavy method call? Do I need to call an explicit repaint/refresh/revalidate?

You need to call
processFile(selectedFile);
in another thread (not in the AWT thread). To do so you can do something like this :
Thread t = new Thread(){
public void run(){
processFile(selectedFile);
// now you need to refresh the UI... it must be done in the UI thread
// to do so use "SwingUtilities.invokeLater"
SwingUtilities.invokeLater(new Runnable(){
public void run(){
loaderLabel.setText("Done..");
missingTransactionsPanel.setVisible(true);
}
}
)
}
};
t.start();
Please not that I didn't work with swing for a long time, so there may be some syntax issues with this code.

Have you tried dispatching the call to the EDT with SwingUtilities.invokeLater() ?
http://www.javamex.com/tutorials/threads/invokelater.shtml

Threading Problem with Java and Android

I'm designing an app, which flicks through a series of pictures, like flicking through a photo album. Pretty standard stuff I'm sure.
Since the picture must be viewed for a few seconds before it automatically changes ot the next pic, I decided to ake a thread that shows the pic, waits couple of second and then moves on.
Picthread(ImageView Image1) {
this.image = Image1;
}
public void run(){
showPicture(image);
animal_array = new String[7];
while (counter < 7){
try{
int timer = 0;
while (timer < 2000){
sleep(500);
timer+=500;
}
image.post(new Runnable(){
public void run() {
showPicture(image);
}
});
}
catch (InterruptedException e) {
}
}
}
This actualy worked. showPictures is a very simple method that just chooses a picture and puts it on an ImageView. It isn't necessary to know about it for my problem.
At first itdidn't work, the logcat said I couldn't touch a view on a view heirarchy that wasnt created in this thread. I wasn't sure what that meant so I did the
image.post(...)
code. Which worked. My main question is: Why was this necesary? If you look at my above code, the first showPicture() method is not inside the image.post() code. But no exception is registered. I don't understand this, why isn't a post needed? But also why do I need to post, since Image is a class variable, and I thought could be viewed by all threads. I was happy it worked, but puzzled.
Please bare in mind, this is my first attempt at threading in Java on anything more than trivial textbook examples. SO I'm still pretty confused.
By the way, in the end I ditched the whole thread, and just did
new Thread(new Runnable() {
public void run() {...}

When doing "things" with the GUI you should always be on the GUI thread. That is what View.post(Runnable) does, ensuring that the gui thread does the work of the runnable.
Even though your showImage works once does not mean that it always works...