I don't see any reason why this is a problem, I believe in this case specific case is swing leaking.
Mario -- Sent from HTC Desire... pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ ----- Reply message ----- Da: "Clemens Eisserer" <[email protected]> Data: gio, ago 25, 2011 21:20 Oggetto: <Swing Dev> Is the following code supposed to leak? A: <[email protected]> Hi Pavel, So if your SecurityManager denies app closing, then the application should > be alive. It looks that your implementation contradicts javadoc contracts. > The app stays running for as long as the client's browser window is open - and is terminated when the assicioated HttpSession times out. This is when we dispose the AppContexts, which closes this one app "instance". > Besides, I find it a bit weird that addXZYListener() secretly registers >> listener to some sort of internal global object. That sounds very leaky. >> Is it documented that such listeners must always be carefully removed? >> Or am I missing something? >> > As I said normally listeners shouldn't be removed manually, until this > listeners are added to static instances (or delegates). The > JTextComponent#getActions method invoked on non-static object, but it uses > inside static editor kit. So listener removing depends on implementation and > programmers should take such nuances into account. > I think what Roman ment is wether this is documented somewhere - I couldn't find out why the code leaked until I had a look at Swing's source. I find the current API quite unintuitive - I register a listener to a JTextArea's editor, which sends me events just for this one JTextArea, and jet its added to some global state. From what I have seen the editors are mostly a bunch of state-less code, except for the Actions defined. Any compatibility-issues in mind re-working that area, making the actions part of the JComponent's state? Thanks, Clemens
