 
| View previous topic :: View next topic |
| Author |
Message |
Wade Chandler
Posted via mailing list.
|
 Posted: Sun Jul 19, 2009 6:56 pm Post subject: component creation outside EDT |
 |
|
This actually illustrates my point precisely, the informaiton in the second link you sent is just wrong as done is always called on the EDT, so of course he would see the output he presents from that example, and thus he is indeed more correct than he realizes when he states that his example is not realistic:
http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html#done()
Of course we should all know, if we know anything about threads, that access would not be good as nothing is synchronized. However, creating an instance, it possibly having multiple embedded instances of different objects itself, and then handing that off to another thread by passing it as an argument is perfectly fine and in fact the only way to hand information from one thread to another unless it is global or in scope say an inner class and another thread.
In the case where he mentions the button and the label being set, he fails to note that the button is not repainted just by setting its label. There has to be a graphics context for which it is added, and some other things have to take place. Thus it has to actually be realized for that to be an issue. The flip side is if that code were production code it would just be incorrect because he would have called something which forced two threads to access the same information because done is called on the EDT, and that would be a programmer error. Otherwise, if he just called the add method, and never realized anything with a setVisible, and had not called anything to cause another thread to enter the picture, everything would have been perfectly fine.
My point when I wrote again was that in JDK 6 the Swing team changed the rules a bit which I just noticed when reading back over some documents, but seemingly based not in reality, but instead on something else, and I am concluding it must be based on folks incorrect assumptions, bad code, and all the misinformation all quite possibly causing them more headaches trying to explain things; WIN32, Borland VCL, and many others work just like Swing in regard to this idea of a single thread and having objects you create on another has always been part of that.
http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/package-summary.html
Search the swing sources for invokeLater which is the only way to enter the EDT where two threads can access the same code at the same time during by calling a constructor without realizing a component and having Swing and the repaint manager enter the EDT for you where one of those threads is the EDT. invokeAndWait blocks the current thread, so if it is the thread creating the instance neither thread will be trying to change the values at the same time, and is why I'm not mentioning invokeAndWait.
Now, take this I'm mentioning above. You have a button and some other things. You instantiate the button, even call add on a container, etc. Yet you never call revalidate or validate yourself on the container and you never add it to a visible parent container where this is done for you when the parent is repainted or validated. That code won't enter the EDT if you have a peek in the Swing sources specifically looking for code that enters it. The exact same thing should be true for a NB TopComponent which is never laid out, not just having components added to it, or which has not been added to some parent container, and is indeed true per Substances check to let you know that you are not working on the EDT at that point, and to that end, how else is the EDT going to come into play on that instance where Substance is raising this exception?
There is a big difference between instantiating and setting up some properties from a single thread versus adding those things to something which will actually put them in the EDT and then accessing those same things from the other thread or outside the EDT afterwords.
Seems like a big crazy train out of control this whole EDT debate, and not at all based in reality. Of course multiple threads accessing something which is not synchronized is bad unless from a purely read-only point of view where it is never reset by another thread, but that is the case in every framework and language I know of and is part of correct threading and multi-processor based programming.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 5:25:10 PM
Subject: Re: [nbdev] component creation outside EDT
Hi Wade,
the rule from Swing documentation, that indicates that it's save to create
unrealized components off the EDT, seems to have changed with 1.5:
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html
http://www.javaworld.com/javaworld/jw-08-2007/jw-08-swingthreading.html?page=5
So it's also not valid anymore to create components off the EDT... it looks
to me like it's really a problem of NetBeans, not of substance.
--Toni
Wade Chandler wrote:
| Quote: |
According to the Swing threading page, it is not a bug to create
unrealized components off the EDT. Sounds more like a bug to substance to
me. The only problem with threading which should arise is when multiple
threads try to access the swing components as they are not thread safe.
So, if you thread is only accessing them, then you had those objects off
to the EDT to show and allow the user to interact with them only a single
thread at a time will be interacting with them.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton
To: address-removed
Sent: Saturday, July 18, 2009 7:07:45 AM
Subject: [nbdev] component creation outside EDT
I'm currently writing a JTabbedPane based replacement for
TabbedContainer. It
works nicely with third.party look & feels except substance. Substance >
5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7.
I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error
messages.
I'm going to file a bug for this (with the log), but currently
issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing
list
archive at Nabble.com.
|
|
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24551934.html
Sent from the Netbeans Project Developers (not for user help) mailing list
archive at Nabble.com. |
|
|
| Back to top |
|
 |
eppleton
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 7:26 pm Post subject: component creation outside EDT |
|
|
Wade Chandler wrote:
| Quote: |
This actually illustrates my point precisely, the informaiton in the
second link you sent is just wrong as done is always called on the EDT, so
of course he would see the output he presents from that example, and thus
he is indeed more correct than he realizes when he states that his example
is not realistic:
http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html#done()
|
You're right, done() is called on EDT, but that's the point of the example.
It's the intention to show that the initialization code is running on one
thread while other UI code is running on the event-dispatch thread at the
same time, thereby violating swings single-threaded rule.
Here is a more realistic example that illustrates a real world bug:
http://bugs.sun.com/view_bug.do?bug_id=6718641
It is closed with the comment:
"This is not expected to work since about 2003. The rules for threading in
Swing were changed to say that all object contruction must be done on the
event dispatching thread (EDT). Prior to then object contruction was allowed
before the top level(Frame) was realised, but that is no longer the case.
Almost all code in Swing assumes it is running on the EDT in a single
threaded model, Nimbus LAF is no different. There is documented in the Swing
Tutorial at
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/initial.html
.Also the history is exmplained at
http://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/"
The last link covers the history of the change:
http://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/
So component creation off the EDT is not only considered a bad practice, but
can cause deadlocks and is considered a bug in the application.
Wade Chandler wrote:
| Quote: |
My point when I wrote again was that in JDK 6 the Swing team changed the
rules a bit which I just noticed when reading back over some documents,
but seemingly based not in reality, but instead on something else, and I
am concluding it must be based on folks incorrect assumptions, bad code,
and all the misinformation all quite possibly causing them more headaches
trying to explain things;
|
I don't think so, they seem to have had actual problems with their very own
coding examples causing deadlocks even though they didn't do anything
particularly nasty:
"Out of all the demos in the Swing Tutorial, we encountered a problem only
in ComponentEventDemo. In that case, sometimes when you launched the demo,
it would not come up because it would deadlock when updating the text area
if the text area had not yet been realized, while other times it would come
up without incident."
http://web.archive.org/web/20040413005634/http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
Now the curren Java Tutorial states this:
"Why does not the initial thread simply create the GUI itself? Because
almost all code that creates or interacts with Swing components must run on
the event dispatch thread. This restriction is discussed further in the next
section."
--Toni
--
View this message in context: http://www.nabble.com/component-creation-outside-EDT-tp24546811p24555727.html
Sent from the Netbeans Project Developers (not for user help) mailing list archive at Nabble.com. |
|
| Back to top |
|
|
Wade Chandler
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 7:55 pm Post subject: component creation outside EDT |
|
|
----- Original Message ----
| Quote: | From: eppleton <address-removed>
To: address-removed
Sent: Sunday, July 19, 2009 5:26:45 AM
Subject: Re: [nbdev] component creation outside EDT
Wade Chandler wrote:
| Quote: |
This actually illustrates my point precisely, the informaiton in the
second link you sent is just wrong as done is always called on the EDT, so
of course he would see the output he presents from that example, and thus
he is indeed more correct than he realizes when he states that his example
is not realistic:
http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html#done()
|
You're right, done() is called on EDT, but that's the point of the example.
It's the intention to show that the initialization code is running on one
thread while other UI code is running on the event-dispatch thread at the
same time, thereby violating swings single-threaded rule.
Here is a more realistic example that illustrates a real world bug:
http://bugs.sun.com/view_bug.do?bug_id=6718641
It is closed with the comment:
"This is not expected to work since about 2003. The rules for threading in
Swing were changed to say that all object contruction must be done on the
event dispatching thread (EDT). Prior to then object contruction was allowed
before the top level(Frame) was realised, but that is no longer the case.
Almost all code in Swing assumes it is running on the EDT in a single
threaded model, Nimbus LAF is no different. There is documented in the Swing
Tutorial at
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/initial.html
.Also the history is exmplained at
http://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/"
The last link covers the history of the change:
http://bitguru.wordpress.com/2007/03/21/will-the-real-swing-single-threading-rule-please-stand-up/
So component creation off the EDT is not only considered a bad practice, but
can cause deadlocks and is considered a bug in the application.
|
In the first case, the only reason the EDT is entered in the code is because in a container listener for add, which we were never to expect to always be executed on the EDT, the programmer adds a bug which causes two threads to exist or operate within that context. Swing doesn't do that, but instead the way the programmer uses it does.
It is easy enough to work around and not make that happen and the fact that once we cause the EDT to enter the picture more than one thread can be involved if we access from outside the EDT creates the end point for access to those things from outside it. Until something happens which explicitly makes the logic enter the EDT, then it will not come into play, and the current Swing sources will not do this outside of realization; less Nimbus obviously.
This next thing about Nimbus, which was not written by the original Swing architects as I understand it, gets to another point about thread rules being violated by a small portion of code (possibly a Swing look and feel...definitely in this case), bad programming, and someone not knowing what they were doing; apparently.
None of the other things in Swing do this now except for Nimbus that I can tell. The funnier part about this Nimbus bug is that it has nothing to do with the EDT except for the fact that the code is creating instances in more than one thread and then Nimbus uses the new Java 5 for loop over a Hashtable entry set versus getting an array which would be immutable for the purpose of the code, and this bug would not exist, and then there is the funny cop out...EDT.
Think about it, if the original underlying code which creates the Hashtable was thinking...oh EDT and single thread...then why not use HashMap...faster. If the developers code did all that pump/prep work in a single thread versus the EDT it would still work, but the issue would be if something like NB tried to use Nimbus it would get an error if multiple modules do prep work in multiple threads, and it is perfectly valid to want to create your instances up front and then only worry about the showing in the EDT to limit the time it is bogged down; more true in the cases something is installed into a running application and new UI components must be created and placed into the UI.
Nimbus really should just be fixed, but maybe they have decided to change up the rule when working on Nimbus, and more likely what happened was someone didn't know the rules, and obviously didn't know everything they were doing, certainly not about the threading and the keySet and looping business, and then here we are. I would love to see the information which is quoted as being available since 2003. The JavaDocs for Swing certainly were not updated pre-Nimbus to reflect such a change.
All one has to do to see this is go into their JDK 1.6.0_14 folder, unzip src.zip, and search the source folders involved to see what happens at this very moment. Of course, if the programmer introduces logic which accesses those things from more than one thread there is a bug and an issue. So, if Nimbus itself is fixed, then this problem really should not exist except for code which tries to do more than instantiate some things off the EDT or in the case of Nimbus, and any others like it, which uses some other logic which will directly break because of concurrency issues.
I have written some folks to get some kind of an answer as that really makes no sense. It is like someone threw in a crap shoot, let someone work on Swing who didn't understand threading nor the way things have worked for years, or at least nobody explained it or something might be the best way of saying it, and then decided it was cheaper internally to just change the rule less fix the actual issue. Again, the funny thing about it all, if you look over the Swing logic and search of the EDT entry etc, it doesn't happen in the normal Swing classes...the classics anyways. Too, Nimbus doesn't do anything really bad except for the way it uses set iteration which has a concurrency issue.
package testnimbus;
import java.awt.*;
import javax.swing.*;
// javac TestNimbusThreading.java
// java -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel TestNimbusThreading
public class TestNimbusThreading {
public TestNimbusThreading() {
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
final JFrame mainFrame = new JFrame();
final JPanel jpGrid = new JPanel(new GridLayout(5, 5));
final SwingObjectCreation[] tableCreation = new SwingObjectCreation[25];
for (int i = 0; i < tableCreation.length; i++) {
tableCreation[i] = new SwingObjectCreation();
tableCreation[i].start();
}
for (int i = 0; i < tableCreation.length; i++) {
tableCreation[i].join();
}
SwingUtilities.invokeLater(new Runnable() {
public void run() {
jpGrid.add(new JButton("Hello"));
for (int i = 0; i < tableCreation.length; i++) {
jpGrid.add(new JScrollPane(tableCreation[i].getTable()));
}
mainFrame.getContentPane().add(jpGrid);
try {
UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
} catch (Throwable e) {
e.printStackTrace();
}
SwingUtilities.updateComponentTreeUI(mainFrame);
mainFrame.pack();
mainFrame.setVisible(true);
mainFrame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
}
});
} catch (Exception ex) {
ex.printStackTrace();
}
}
public static void main(String[] args) {
new TestNimbusThreading();
}
public static class SwingObjectCreation extends Thread {
private JTable table;
public void run() {
table = new JTable(3, 2);
}
public JTable getTable() {
return table;
}
}
}
Actually works every single time (windows but have had similar code on Linux...just running windows right now). As well if one uses Metal by changing the first set lnf to UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName()); it works correctly.
This code will run and loop over the above logic 100 times without issue and you can run and re-run until you turn blue in the face. Only change was the invokeAndWait because of where I have it setting the LNF. Too I am disposing of the frame etc to not create so many flipping frames.
package testnimbus;
import java.awt.*;
import javax.swing.*;
// javac TestNimbusThreading.java
// java -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel TestNimbusThreading
public class TestNimbusThreading {
public TestNimbusThreading() {
for (int runtimes = 0; runtimes < 100; runtimes++) {
try {
UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
final JFrame mainFrame = new JFrame();
final JPanel jpGrid = new JPanel(new GridLayout(5, 5));
final SwingObjectCreation[] tableCreation = new SwingObjectCreation[1000];
for (int i = 0; i < tableCreation.length; i++) {
tableCreation[i] = new SwingObjectCreation();
tableCreation[i].start();
}
for (int i = 0; i < tableCreation.length; i++) {
tableCreation[i].join();
}
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
jpGrid.add(new JButton("Hello"));
for (int i = 0; i < tableCreation.length; i++) {
jpGrid.add(new JScrollPane(tableCreation[i].getTable()));
}
mainFrame.getContentPane().add(jpGrid);
try {
UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
} catch (Throwable e) {
e.printStackTrace();
}
SwingUtilities.updateComponentTreeUI(mainFrame);
mainFrame.pack();
mainFrame.setVisible(true);
mainFrame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
mainFrame.dispose();
}
});
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
public static void main(String[] args) {
new TestNimbusThreading();
}
public static class SwingObjectCreation extends Thread {
private JTable table;
public void run() {
table = new JTable(3, 2);
}
public JTable getTable() {
return table;
}
}
}
Anyways, the dialog I would like to start with the Swing folks is 1) why the change? 2) there is a perfectly valid case for prepping and priming UIs in different contexts. 3) There are times when one has some task which really should create some UI components in the backend and then replace them while not locking up the UI with non-user interactive or event based code until those components need hooked into the UI.
So, hopefully this can turn into a discussion. We have to want Swing to be the best it can be less changes which discount all the other real use cases that can apply to different applications. The examples online of a simple little program which shows a window and a table are fine, but they need to be building some NB IDEs or something to really feel the impact of their work; just the reality here. I think this discussion should happen before we start talking about changing how NB instantiates its TopComponents.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org |
|
| Back to top |
|
|
eppleton
Posted via mailing list.
|
|
| Back to top |
|
|
Wade Chandler
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 8:09 pm Post subject: component creation outside EDT |
|
|
Not much of a feature considering it is done on creation versus other times things are painted or other actions. Again, unrealized or unpainted, components are allowed to be created off the EDT. As soon as you tie them to a Swing tree which will interact with folks and painted into the hierarchy, then you start to have threading concerns. Kirill's last comment in that blog entry is incorrect in my opinion. There are plenty of times when multiple UI components need to be created off the EDT, and certainly if Substance is enforcing an invalid threading rule *it* is breaking the commenter's code not Swings threading model.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: Aekold Helbrass <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 2:16:15 PM
Subject: Re: [nbdev] component creation outside EDT
It's not a bug, it's "feature" of substance. Read more here
http://www.pushing-pixels.org/?p=368 The only way to fix it - to path
org/jvnet/substance/utils/SubstanceCoreUtilities.java class,
testComponentCreationThreadingViolation method.
On Sat, Jul 18, 2009 at 8:13 PM, Wade
Chandlerwrote:
| Quote: |
According to the Swing threading page, it is not a bug to create unrealized
|
components off the EDT. Sounds more like a bug to substance to me. The only
problem with threading which should arise is when multiple threads try to access
the swing components as they are not thread safe. So, if you thread is only
accessing them, then you had those objects off to the EDT to show and allow the
user to interact with them only a single thread at a time will be interacting
with them.
| Quote: |
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton
To: address-removed
Sent: Saturday, July 18, 2009 7:07:45 AM
Subject: [nbdev] component creation outside EDT
I'm currently writing a JTabbedPane based replacement for TabbedContainer. It
works nicely with third.party look & feels except substance. Substance > 5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7. I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error messages.
I'm going to file a bug for this (with the log), but currently issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing list
archive at Nabble.com.
|
|
--
Heresylabs code: http://heresylabs.googlecode.com/
Heresylabs blog: http://heresylabs.org/ |
|
|
| Back to top |
|
|
Wade Chandler
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 9:08 pm Post subject: component creation outside EDT |
|
|
I'll be more clear just to get it over with.
Of course if you have a specific component which does something such as calling invokeLater in a constructor or the like, then you could have issues; a bug. Those really should be considered bugs by forcing instantiation down the EDT. Things become unverifiable as to the working of Swing at large at that point, and then things such as large dynamically built UI structures and their models which may use some Swing component have to perform more and more of their work on the EDT versus setting up individual instances etc then moving the display and interaction to the EDT.
Part of the problem too has apparently been the Swing team themselves not putting out consistent information, and surely at the same rate, there may very well be bugs introduced in Swing which were fixed by the latest JDK 6 Swing documentation on creating everything on the EDT...simpler than fixing the incorrect behavior of certain components, but not exactly user experience friendly. That said, there are no calls to invokeLater, thus placing anything on the EDT, in the Swing classes for the latest JDK 1.6 update which would occur outside of realization (revalidate and actually painting in the hierarchy), so bugs would not be a valid explanation.
You can look in JEditPane and will see one thing where the document is
set, but it would not affect something being acted on by another thread
at creation time. In Swing, and outside the constructors there is a
total of 51 calls to invokeLater, but again none of which shoud affect
instantiation.
I have a feeling it might have more to do with general lack of knowledge of many developers in this regard and the introduction of SwingWorker which means changes to the documentation to recommend everyone even create instances on the EDT as a means to guide them around common silly mistakes to reduce user support questions on the forums and lists.
So, some of it seems to have come from the SwingWorker being added to the standard classes and misinformation folks have about threading in general, strange the shift in informaiton at that point with no real changes to the classes usage of the EDT during instantiation, and most likely trying to force folks down that path. I was reading the info which was changed around Java 6.
That said, if you go digging in Swing you'll see there are classes which currently pose no more risk being created on another thread and handed to another one than any other class such as say HashMap. The point is that the two threads can not access those things at the same time, and so once created, and the other thread hands off to the EDT, then it should no longer access those things off the EDT.
I just find this whole thing facinating. I assume it must have come from folks doing something like: 1) create instances 2) show them (maybe even on the EDT) 3) access something from another thread. Then, they just automatically came to the conclusion that was all Swings threading models fault versus their poor programming and assumed it could have strange adverse affects in creation versus possibly showing off the EDT or perhaps external EDT access to fields/properties.
Now, of course depending on the layout you are using on a given component, if you are adding components there might be some bugs in the layout manager that could affect things if you add those components etc and it doesn't use invokeAndWait or computes those on the EDT using invokeLater and isn't waiting until it is requested to actually layout the components. The same could be said for a look and feel depending on what it is doing and how and when it is calculating things; whether it is doing work it should not be doing until realisation or not.
Anyways, that is all I have say about that. Funny topic which has always bothered me when folks bring it up because there is so much misinformation around which seems to come from no where...that or folks buggy custom components.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: Wade Chandler <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 4:08:17 PM
Subject: Re: [nbdev] component creation outside EDT
Not much of a feature considering it is done on creation versus other times
things are painted or other actions. Again, unrealized or unpainted, components
are allowed to be created off the EDT. As soon as you tie them to a Swing tree
which will interact with folks and painted into the hierarchy, then you start to
have threading concerns. Kirill's last comment in that blog entry is incorrect
in my opinion. There are plenty of times when multiple UI components need to be
created off the EDT, and certainly if Substance is enforcing an invalid
threading rule *it* is breaking the commenter's code not Swings threading model.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: Aekold Helbrass
To: address-removed
Sent: Saturday, July 18, 2009 2:16:15 PM
Subject: Re: [nbdev] component creation outside EDT
It's not a bug, it's "feature" of substance. Read more here
http://www.pushing-pixels.org/?p=368 The only way to fix it - to path
org/jvnet/substance/utils/SubstanceCoreUtilities.java class,
testComponentCreationThreadingViolation method.
On Sat, Jul 18, 2009 at 8:13 PM, Wade
Chandlerwrote:
| Quote: |
According to the Swing threading page, it is not a bug to create unrealized
|
components off the EDT. Sounds more like a bug to substance to me. The only
problem with threading which should arise is when multiple threads try to
|
access
| Quote: | the swing components as they are not thread safe. So, if you thread is only
accessing them, then you had those objects off to the EDT to show and allow
|
the
| Quote: | user to interact with them only a single thread at a time will be interacting
with them.
|
It
| Quote: | | Quote: | | Quote: | works nicely with third.party look & feels except substance. Substance >
|
|
|
5.0
| Quote: | | Quote: | | Quote: | checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7. I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error messages.
I'm going to file a bug for this (with the log), but currently issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
|
|
|
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
|
|
|
| Back to top |
|
|
eppleton
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 9:25 pm Post subject: component creation outside EDT |
|
|
Hi Wade,
the rule from Swing documentation, that indicates that it's save to create
unrealized components off the EDT, seems to have changed with 1.5:
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html
http://www.javaworld.com/javaworld/jw-08-2007/jw-08-swingthreading.html?page=5
So it's also not valid anymore to create components off the EDT... it looks
to me like it's really a problem of NetBeans, not of substance.
--Toni
Wade Chandler wrote:
| Quote: |
According to the Swing threading page, it is not a bug to create
unrealized components off the EDT. Sounds more like a bug to substance to
me. The only problem with threading which should arise is when multiple
threads try to access the swing components as they are not thread safe.
So, if you thread is only accessing them, then you had those objects off
to the EDT to show and allow the user to interact with them only a single
thread at a time will be interacting with them.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 7:07:45 AM
Subject: [nbdev] component creation outside EDT
I'm currently writing a JTabbedPane based replacement for
TabbedContainer. It
works nicely with third.party look & feels except substance. Substance >
5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7.
I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error
messages.
I'm going to file a bug for this (with the log), but currently
issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing
list
archive at Nabble.com.
|
|
--
View this message in context: http://www.nabble.com/component-creation-outside-EDT-tp24546811p24551934.html
Sent from the Netbeans Project Developers (not for user help) mailing list archive at Nabble.com. |
|
| Back to top |
|
|
Aekold Helbrass
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 9:39 pm Post subject: component creation outside EDT |
|
|
It's not a bug, it's "feature" of substance. Read more here
http://www.pushing-pixels.org/?p=368 The only way to fix it - to path
org/jvnet/substance/utils/SubstanceCoreUtilities.java class,
testComponentCreationThreadingViolation method.
On Sat, Jul 18, 2009 at 8:13 PM, Wade
Chandler<address-removed> wrote:
| Quote: |
According to the Swing threading page, it is not a bug to create unrealized components off the EDT. Sounds more like a bug to substance to me. The only problem with threading which should arise is when multiple threads try to access the swing components as they are not thread safe. So, if you thread is only accessing them, then you had those objects off to the EDT to show and allow the user to interact with them only a single thread at a time will be interacting with them.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 7:07:45 AM
Subject: [nbdev] component creation outside EDT
I'm currently writing a JTabbedPane based replacement for TabbedContainer. It
works nicely with third.party look & feels except substance. Substance > 5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7. I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error messages.
I'm going to file a bug for this (with the log), but currently issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing list
archive at Nabble.com.
|
|
--
Heresylabs code: http://heresylabs.googlecode.com/
Heresylabs blog: http://heresylabs.org/ |
|
| Back to top |
|
|
Wade Chandler
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 9:40 pm Post subject: component creation outside EDT |
|
|
According to the Swing threading page, it is not a bug to create unrealized components off the EDT. Sounds more like a bug to substance to me. The only problem with threading which should arise is when multiple threads try to access the swing components as they are not thread safe. So, if you thread is only accessing them, then you had those objects off to the EDT to show and allow the user to interact with them only a single thread at a time will be interacting with them.
Wade
==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor
http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
----- Original Message ----
| Quote: | From: eppleton <address-removed>
To: address-removed
Sent: Saturday, July 18, 2009 7:07:45 AM
Subject: [nbdev] component creation outside EDT
I'm currently writing a JTabbedPane based replacement for TabbedContainer. It
works nicely with third.party look & feels except substance. Substance > 5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7. I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error messages.
I'm going to file a bug for this (with the log), but currently issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context:
http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing list
archive at Nabble.com. |
|
|
| Back to top |
|
|
eppleton
Posted via mailing list.
|
| Posted: Sun Jul 19, 2009 9:56 pm Post subject: component creation outside EDT |
|
|
I'm currently writing a JTabbedPane based replacement for TabbedContainer. It
works nicely with third.party look & feels except substance. Substance > 5.0
checks for violations of Swing threading rules, and complains that:
org.jvnet.substance.api.UiThreadingViolationException: Component creation
must be done on Event Dispatch Thread
. The problem also occurs when using substance with NetBeans IDE 6.7. I've
put it in the netbeans.conf:
netbeans_default_options="--laf
org.jvnet.substance.skin.SubstanceBusinessLookAndFeel --cp:p
/path/to/substance.jar
After starting the toolbar vanishes and I'm getting tons of error messages.
I'm going to file a bug for this (with the log), but currently issuetracker
seems to be down.
Is it a known bug that NetBeans creates components of the AWT thread?
--Toni
--
View this message in context: http://www.nabble.com/component-creation-outside-EDT-tp24546811p24546811.html
Sent from the Netbeans Project Developers (not for user help) mailing list archive at Nabble.com. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
