Comments on: JSR296 Swing Application Framework http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/ Living in a state of accord. Fri, 12 Mar 2010 07:41:05 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Thorn Green http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-111127 Thorn Green Fri, 14 Sep 2007 23:32:15 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-111127 I have an alternate framework that the JSR-296 people may want to look at. See: http://verdantium.blogspot.com/ I have an alternate framework that the JSR-296 people may want to look at. See:

http://verdantium.blogspot.com/

]]> By: Steven http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-80835 Steven Tue, 22 May 2007 11:24:06 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-80835 You remark that 'updates are covered by webstart' We use Webstart for a moderately complex application - and we're dumping it as fast as we can for the next release. It is slow, unreliable, and remarkably intrusive! You remark that ‘updates are covered by webstart’

We use Webstart for a moderately complex application – and we’re dumping it as fast as we can for the next release.

It is slow, unreliable, and remarkably intrusive!

]]> By: Pure Danger Tech » Blog Archive » Java 7 Roundup (May 21st) http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-80760 Pure Danger Tech » Blog Archive » Java 7 Roundup (May 21st) Tue, 22 May 2007 03:50:44 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-80760 [...] Sutton posted notes from the JSR 296 Swing Application Framework session at JavaOne. Malcolm Davis posted some requests [...] [...] Sutton posted notes from the JSR 296 Swing Application Framework session at JavaOne. Malcolm Davis posted some requests [...]

]]> By: Adrian Sutton http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-78193 Adrian Sutton Sun, 13 May 2007 02:51:48 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-78193 Having to register for every single event you want is unclean in and of itself. The prototype their working on runs on Java 1.5 and will be useful prior to 1.7 - there's not point in tying this to a JVM that won't be out for at least another year and attempting to use a JSR (closures) that is changing a great deal or it just makes everything harder. Besides, you don't want to use closures to hold the kind of code you'd write in the app framework callback methods and it's annoying to have to register a closure as a listener and go and create a method as well. Much easier to just override a method and be done. Having to register for every single event you want is unclean in and of itself. The prototype their working on runs on Java 1.5 and will be useful prior to 1.7 – there’s not point in tying this to a JVM that won’t be out for at least another year and attempting to use a JSR (closures) that is changing a great deal or it just makes everything harder. Besides, you don’t want to use closures to hold the kind of code you’d write in the app framework callback methods and it’s annoying to have to register a closure as a listener and go and create a method as well. Much easier to just override a method and be done.

]]> By: Ricky Clarkson http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-78190 Ricky Clarkson Sun, 13 May 2007 02:29:31 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-78190 There's nothing conceptually unclean about having a separate interface for each method (see lambda calculus) - and in fact usually the interfaces will all be the same, so they can be one. Runnable works for the basic cases. With closures in Java 7, this becomes more syntactically attractive. There’s nothing conceptually unclean about having a separate interface for each method (see lambda calculus) – and in fact usually the interfaces will all be the same, so they can be one. Runnable works for the basic cases.

With closures in Java 7, this becomes more syntactically attractive.

]]> By: Adrian Sutton http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-78189 Adrian Sutton Sun, 13 May 2007 02:24:02 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-78189 The callback would have to have an interface to call back into which would either require you to implement all the methods or have a separate interface for every method - neither is a very clean solution. Java doesn't use duck typing. As for testing, my point was that you can't test a Swing app in headless mode so there's no point in trying to design frameworks that let you use headless mode for your tests. If your tests run headless, you're not testing your swing code properly. The callback would have to have an interface to call back into which would either require you to implement all the methods or have a separate interface for every method – neither is a very clean solution. Java doesn’t use duck typing.

As for testing, my point was that you can’t test a Swing app in headless mode so there’s no point in trying to design frameworks that let you use headless mode for your tests. If your tests run headless, you’re not testing your swing code properly.

]]> By: Ricky Clarkson http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-78185 Ricky Clarkson Sun, 13 May 2007 01:59:45 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-78185 Au contraire, for the subclass is not the only useful tool in the toolbox. There are ways of doing this without boilerplate - the callback is one such way, in that you only need to provide callbacks for those methods you're interested in. I perform as much separation of 'business logic' from my UI as I like. Typically the more unwieldy I find the combination, the more I separate things. Are you saying that one should not wish to automatically test a JFrame subclass, nor an Application subclass? Au contraire, for the subclass is not the only useful tool in the toolbox. There are ways of doing this without boilerplate – the callback is one such way, in that you only need to provide callbacks for those methods you’re interested in.

I perform as much separation of ‘business logic’ from my UI as I like. Typically the more unwieldy I find the combination, the more I separate things. Are you saying that one should not wish to automatically test a JFrame subclass, nor an Application subclass?

]]> By: Adrian Sutton http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-78183 Adrian Sutton Sun, 13 May 2007 01:48:24 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-78183 Any solution other than subclassing would require the implementation to provide every single method in the life cycle regardless of whether or not it will be used. Since the entire point of the framework is to remove boiler plate code, callbacks or an interface would not be a clean solution. As for automatically testing, if you're testing a Swing app in headless mode, you're not testing your swing app. If you're separating your business logic from your UI and testing the business model in headless mode, then you shouldn't have any business logic for either classes that work with JFrames or classes that extend Application. The swing app framework and the Application class is all about the life cycle of your applications UI, business logic should not be mixed in there. Any solution other than subclassing would require the implementation to provide every single method in the life cycle regardless of whether or not it will be used. Since the entire point of the framework is to remove boiler plate code, callbacks or an interface would not be a clean solution.

As for automatically testing, if you’re testing a Swing app in headless mode, you’re not testing your swing app. If you’re separating your business logic from your UI and testing the business model in headless mode, then you shouldn’t have any business logic for either classes that work with JFrames or classes that extend Application. The swing app framework and the Application class is all about the life cycle of your applications UI, business logic should not be mixed in there.

]]> By: Ricky Clarkson http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-77967 Ricky Clarkson Sat, 12 May 2007 09:40:32 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-77967 A clean way would be for Application to be an interface, and to provide those methods via some other object. Another clean way would be for Application to be a final class, and to provide implementations as callbacks. Subclassing tends to lead to big complex classes, partially because of the convenience of accessing the superclass methods - you pay a price if you split your work into more than one class. Also, it seems like it might be hard to automatically test an Application subclass, as you're depending on whatever behaviour is inherited from above. In the same way, you cannot test a JFrame subclass in headless mode, because instantiating a JFrame requires a GUI (even if you don't display it). A clean way would be for Application to be an interface, and to provide those methods via some other object. Another clean way would be for Application to be a final class, and to provide implementations as callbacks.

Subclassing tends to lead to big complex classes, partially because of the convenience of accessing the superclass methods – you pay a price if you split your work into more than one class.

Also, it seems like it might be hard to automatically test an Application subclass, as you’re depending on whatever behaviour is inherited from above.

In the same way, you cannot test a JFrame subclass in headless mode, because instantiating a JFrame requires a GUI (even if you don’t display it).

]]> By: Anonymous http://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/comment-page-1/#comment-77759 Anonymous Fri, 11 May 2007 18:52:05 +0000 https://www.symphonious.net/2007/05/10/jsr296-swing-application-framework/#comment-77759 Hi Ricky, Extending from Application makes logical sense - your application is the Application and it extends the functionality of the startup and quit immediately application that you get by default. It also means you have much simpler access to the methods exposed by Application instead of having to delegate to another class all the time. Basically, I can't imagine a clean way to it that doesn't use sublcassing. Also, thanks for pointing out the atom link was broken, it's fixed now. Hi Ricky,
Extending from Application makes logical sense – your application is the Application and it extends the functionality of the startup and quit immediately application that you get by default. It also means you have much simpler access to the methods exposed by Application instead of having to delegate to another class all the time. Basically, I can’t imagine a clean way to it that doesn’t use sublcassing.

Also, thanks for pointing out the atom link was broken, it’s fixed now.

]]>