• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Calling all Swing experts: What the heck is going on here?  RSS feed

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do work for a non-for-profit and our Java Swing desktop software is experiencing a GUI failure which seems to occur spontaneously, without notice. This only seems to occur while typing text into an extended JTextPane, which is the primary component used by our users.

Once the issue occurs, dialogs fail to appear on setVisible, and components such as checkboxes and scrollbars begin to fail to repaint. Eventually, if you continue to try to use the software once it's in this state, all components completely stop repainting and the software becomes unusable. However, strangely, the EDT is not blocked, keyboard input continues to be processed in the document, and all keyboard shortcuts in our actions continue to work. So, it seems to be repaint related.

The only exception we see in the console is the following when we try to show any JOptionPane dialog once the failure has started:


This exception will only be shown when we try to create a dialog after the GUI begins to fail. Dialogs work just fine until it craps the bed, then they fail to render at all.

Your first thought might be that's it's threading related. We've thoroughly checked that all Swing calls occur on the EDT using invokeLater. I even used a Java agent to inject code that spits out a stack trace if any Swing component is accessed off the EDT, so that's most likely not the cause. The EDT is also not blocked or deadlocked. You can keep typing, use shortcuts, and the EDT queue hums along just fine. Meanwhile, the GUI fails to render at all.

The only solution we've found is to force quit our software and restart it once the problem occurs.

Any ideas as to what might be happening? What would cause the GUI to stop repainting like this? Have you seen anything similar on your end while working on your own Swing projects? And is there anything repaint-related you can think of that could cause this issue to occur?

What would you recommend doing to troubleshoot this? We've done thread dumps, but everything looks normal while the problem is occurring. How would you go about troubleshooting a Swing render problem like this?

Anything that would help would be greatly appreciated.
 
Bartender
Posts: 9494
184
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to CodeRanch!

It looks like some action in the JTextPane is doing something bad which causes the renderer to go into an invalid state.

You said you guys extended it. If it's not proprietary code, can you share it with us so we might see if there are obvious things wrong?

A good strategy is to write an SSCCE. Basically, try to write the simplest code possible that demonstrates the problem, that other people can compile and run. Usually, in the process of cutting out unrelated code, you stumble upon the source of the issue by yourself. If not, others can try to debug it.
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Stephan! Thanks for the welcome and for your reply.

I was afraid you'd say that. Unfortunately we're using a third party extended JTextPane called JWord and that code is closed source. We have access to it (we obtained a license) but I can't post it here for obvious reasons.

The main thing I'm looking for then is, how might you go about troubleshooting a repaint issue like this? I'm thinking there might be a way to probe the state of the RepaintManager (or other Swing internals) but that's uncharted territory for us. If you or someone else has experience doing this, or have ideas of how to go about troubleshooting repaint problems, that would be awesome. Google and StackOverflow haven't pulled through like they normally do.
 
Marshal
Posts: 61766
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think, maybe start by referring the problem back to the code's creator.
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Campbell. Thanks, I've reached out to the code's creator as well.
 
Stephan van Hulst
Bartender
Posts: 9494
184
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm assuming the extended component is named JWordTextPane.

Do you guys override any of the methods of this class? If not, you could try to record which methods are called on the class before the problem occurs.

Then slowly eliminate calls until you find a minimal sequence that causes the problem. You can pass this on to the original developers to help them solve the issue.
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, it's called JWordTextPane. We've barely extended, just enough to add some additional state, no real behavior changes.

Great idea! Since users are typing into this document regularly, we could trace through which methods are called on every character insertion. I've already looked through the JWord repaint code, but don't exactly know what to look for aside from general glaring problems.
 
Campbell Ritchie
Marshal
Posts: 61766
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now this th‍read has come back to the top of the list: why are you using sun.swing.SingUtilities? Why is there a No 2 class, and you appear to be using an anonymous class from it. Then you are casting it. Or is the originator doing the casting? Has somebody mistaken that class for this? Not that you can cast SwingUtilities; it is uninstantiable, so it has no subtypes.
Also, why are you using a class whose name starts “sun”. I can never remember the full details, but some such classes are removed from some newer versions altogether. Or should I direct those questions to the originator, too?
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That SwingUtilities class cast exception is actually cause by us trying to create a plain old message dialog using JOptionPane.showMessageDialog(). That exception is happening inside core Java code when we try to create a dialog that way. It only happens once the GUI begins to fail! Very strange. So I am not doing that casting, that's actually Java 1.8 code that's failing there.  As to why it suddenly starts failing, I'm not sure, and would most likely illuminate the greater issue we're seeing.
 
Campbell Ritchie
Marshal
Posts: 61766
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, what happens when you run your app on Java7?
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We've tried Java 8 and 10, yet the issue persists. Our project will not compile using Java 1.7 without significant changes due to dependencies on newer Java features.
 
Campbell Ritchie
Marshal
Posts: 61766
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure I can help any more, sorry. Did you hear anything from the resource's creators?
 
Justin Mahar
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alright, thanks for replying anyways.  At least we know this isn't an easy nut to crack.

We heard back from the creator. His suggestion was: "make a custom component (a canvas for example), send addDirtyRegion requests through RepaintManager (from a menu item for example) and try to see if its "paint" method is called.
You can keep the custom component in production and create logs from paint method, if paint logs continue when gui brokes, then it means the problem is not on the event queue side."

So at least we'd know if repaint stops getting called when the issue occurs.

I'm going to look into ways to dig into the repaint internals and run some diagnostics. Wish me luck.  If you have any suggestions, I'm all ears!
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!