 |
Application Framework Prototype Bows
Posted by hansmuller on January 30, 2007 at 08:03 AM | Comments (35)
I've made a prototype of the fledgling JSR-296 API available,
it's
https://appframework.dev.java.net/.
There's a quick overview doc and downloads of the source code,
the javadoc, and the AppFramework.jar file. If you're
interested in this API, please take a look at the overview, and
download the code and then take a look at some of the examples
and the javadoc. You can post feedback here or, if you want to
participate in the long-term discussion, subscribe to the
appframework.dev.java.net "users" mailing list:
https://appframework.dev.java.net/servlets/ProjectMailingListList
.
The users alias is the last one listed.
That's all I really wanted to say. I don't want to make too
much of a commotion about this version of the design because
there's still quite a bit that remains to be done. I was hoping
that this would be a sort-of stealth release: not
terribly noticeable, unless you know where to look. On the
other hand, I know there are Swing developers who aren't members
of the JSR-296 expert group, who'd like to take stock of where
this project is going. And I know there are experienced Swing
developers out there, some of whom have built their own
application frameworks, that would like see how this one
measures up. I'd welcome feedback from anyone who's interested
and I'll promise to respond promptly, unless you bring up a
really difficult issue or a really large number of them. That
might take longer.
Note also: the JCP defines a milestone called "Early Draft
Review" that means the expert group thinks the spec is complete
enough to begin fine tuning. We have not reached that milestone
yet.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Excellent news! Thanks for making this available, I'm downloading it right now! :-)
- Chris
Posted by: chris_e_brown on January 30, 2007 at 08:37 AM
-
Thanks for all the hard work Hans and friends! I'll start using it forthwith - in production! :+)
Posted by: michaelbushe on January 30, 2007 at 08:40 AM
-
That's great news, been waiting for this since it was first announced :).
Posted by: mattnathan on January 30, 2007 at 09:15 AM
-
FINALLY! Very excited!!! Congratulations :-)
Posted by: vprise on January 30, 2007 at 09:17 AM
-
can't wait to lay may hands on it --- but first have to install Subversion in Eclipse, so it'll has to wait until tomorrow ;-)
Cheers, Jeanette
Posted by: kleopatra on January 30, 2007 at 09:27 AM
-
I ran into the following problems (compiling with JDK 6, which I what I
assume is meant to be used) with the project I downloaded from the site:
An extraneous swing-worker.jar library reference
application.Task imports org.jdesktop.swingworker.SwingWorker
instead of javax.swing.SwingWorker
application.TaskMonitorimports
org.jdesktop.swingworker.SwingWorker.StateValue instead of
javax.swing.SwingWorker.StateValue.
I was able to compile the project and run some examples after removing
the swing-worker.jar library reference and fixing the imports in the classes mentioned above against the release version of JDK 6.
Posted by: wwwjames on January 30, 2007 at 09:41 AM
-
Isn't it supposed to target earlier versions of Java? I think that's why it has the dependence on swing-worker.jar.
Posted by: kirillcool on January 30, 2007 at 09:51 AM
-
[response to wwwjames]
Sorry about the SwingWorker problem, I've been testing against Java SE
5, although I believe the code should work on either release. So far,
I haven't figured out a simple way to change build.xml so that
Java SE 6 builds will exclude swing-worker.jar and rewrite the two
SwingWorker imports:
Task.java:14:import org.jdesktop.swingworker.SwingWorker;
TaskMonitor.java:12:import org.jdesktop.swingworker.SwingWorker.StateValue;
The Task class and the read-only Task pending, started, and
(inherited) done properties make it possible for AppFramework
applications to avoid the problem with SwingWorker.
Posted by: hansmuller on January 30, 2007 at 10:12 AM
-
woo hoo!!!
For other readers: I will be posting more screenshots of our NetBeans support for JSR 296 shortly (at least the parts that I'm working on).
Posted by: joshy on January 30, 2007 at 10:32 AM
-
Mea Culpa on JDK 1.6, I missed the part in the JSR which mentioned backward compatibility with older VMs.
However, ... just to throw out a thought ... is it worth the extra effort to support JDK 5 ?
Posted by: wwwjames on January 30, 2007 at 10:35 AM
-
'However, ... just to throw out a thought ... is it worth the extra effort to support JDK 5 ?'
You're probably kidding. But just in case: yes. I'll help, if need be.
Posted by: ktm on January 30, 2007 at 11:08 AM
-
However, ... just to throw out a thought ... is it worth the extra effort to support JDK 5 ?
Because JDK 6 has been released something like, ages ago?
Posted by: kirillcool on January 30, 2007 at 11:13 AM
-
Excellent News.
I will consider using this in our new development.
Thanks a lot for your hard work.
Posted by: hgohil on January 30, 2007 at 12:22 PM
-
Compiled with JDK6 under nb 5.5 OK, just had to resolve swing-worker.jar reference. Very nice examples !.
Posted by: dags on January 30, 2007 at 12:22 PM
-
[per supporting Java SE 5]
The requirement that we support Java SE 5 was strongly supported
by the expert group, it's a practical consideration. I'd certainly
prefer to just deal with Java SE 6!
Posted by: hansmuller on January 30, 2007 at 02:07 PM
-
OK it looks good, it certainly looks easy to use :)
Some first thoughts on the API:
SessionStorage, it would be good if this could be done via streams, I would like my users session information to be able to follow them to different machines - hence local storage is no good to me. I currently do something similar to this using the Preferences class which I then persist to a remote database.
Resource maps, similar to the above - support for stream based properties would be good.
Its very tempting to move my latest app over to this framework...
Rob
Posted by: rasto1968 on January 30, 2007 at 02:43 PM
-
Hi, Hans; what's the JSR group's position on Actions that are found at runtime (i.e. a new component with some Actions in it gets added)?
Also, is there any chance that the various Storage bits could get refactored or subsumed into Preferences?
Thanks for your work on this; we need it.
Laird
Posted by: ljnelson on January 30, 2007 at 07:29 PM
-
This is something that should have been part of swing way back.
One quick question. Just interested how to use this framework within a splash screen start squence. Juring the start sequence we normally display a splash screen which would load the resource bundles, display what data is loading from a db etc. If the application framework is loading the resource bundles, would there be a case to inject a splash screen process before loading the main application frame?
Chris
Posted by: cforker on January 31, 2007 at 03:34 AM
-
Good news!!
I have a question. Will the action framework recognize action methods defined inside a class that has not extended from application.Application? The reason is that I normally define my action methods in controller classes that do not extend from any Swing class. Example:
public class DocumentManager {
@Action(name="DocOpenAction")
public void open() {
...
}
}
In the above example, I have not extended DocumentManager from Application class. In this case, will the framework automatically map the DocumentManager.open method to an action that can be used inside a Swing component?
I would really like to have such a feature, so that my controller classes are separated from Swing classes. Otherwise, the developers will be forced to declare all actions within the application class itself, which would make it very unflexible.
Another question is whether there are any plans to have some XML configuration for those of us who do not want to add @Action notation (as it ties my controller classes to Swing application framework unnecessarily).
Posted by: vhi on January 31, 2007 at 07:16 AM
-
Is in the spec scope to facilitate easy creation of menus and toolbars from the action definitions?
Posted by: wsnyder6 on January 31, 2007 at 07:35 AM
-
vhi: yes, you can do this. I believe Hans has some examples that covers it. You have to tell the application infrastructure which classes you want it to scan for actions. It does your Application subclass by default, but you can also have it scan any other classes. We do this in NetBeans when you define an @Action in one of your form classes. You'll notice in the screenshots on my blog that I have actions defined in about five different classes.
http://weblogs.java.net/blog/joshy/archive/2007/01/first_release_o.html
Posted by: joshy on January 31, 2007 at 08:35 AM
-
Nice work Hans, you rock. Regarding jdk5.0 support I selflishly say drop it because I want everyone else on 6.0 along with me ASAP :-)
Posted by: aronsmith on January 31, 2007 at 08:48 AM
-
[response to Rob - rasto1968]
The backing store for SessionStorage is provided by the LocalStorage
class, which just maps string names to streams. LocalStorage is
intended to be replaceable (see ApplicationContext.setLocalStorage()),
however the current API and implementation lack some things that would
make doing so straightforward:
LocalStorage isn't documented or finished. Finishing it means
providing support for unsigned web started apps based on the
PersistenceService, and for unsigned applets using a TBD
mechanism.
The plan for supporting using your own ApplicationContext subclass is
to lookup the ApplicationContext class with (Java SE 6 only)
ServiceLoader. That hasn't been implemented yet either.
The backing store for ResourceMaps is the (longstanding)
ResourceBundle class. Although developers typically use property
files to encode ResourceBundles, one can also define them with
classes. Although I've never tried, I assume that's enough
flexibility to define the backing store for resources in any way you'd
like. Since ResourceBundles (ResourceMaps) are usually application
specific, not user-specific, perhaps this isn't as important for the
situation you described.
Posted by: hansmuller on January 31, 2007 at 11:08 AM
-
[response to ljnelson]
Actions in the framework are managed with javax.swing.ActionMaps, so
it's nominally straightforward to dynamically configure the
application's actions at runtime by adding actions to an existing ActionMap,
or by inserting a new ActionMap into an existing ActionMap chain. That said,
I haven't tried building an application that does this. It seems like a
reasonable idea; I know larger more ambitious frameworks do this.
It's possible that one could write a LocalStorage subclass that used the
Preferences API for backing store. The reasons for not using
java.util.Preferences directly are probably worth a separate blog entry.
Among them is the fact that the Preferences API can only be used by
privileged applications.
Posted by: hansmuller on January 31, 2007 at 11:16 AM
-
Great news!
Can you make sure that XML Encoder/Decoder (Long term persistence 1.4+) is supported by providing PersistenceDelegates where needed. This might not be an issue but something that is often forgotten..
Cheers,
Mikael
Posted by: mikaelgrev on January 31, 2007 at 11:24 AM
-
[response to cforker]
Integrating splash screen processing with an Application subclass,
including doing the right thing if the application is web started, is
a good idea. I think it would be useful to simplify this to just
specifying an Application resource that names the splash screen image.
One tricky aspect of doing splash screens well is that it's often
quite difficult for startup code to advertise (to the splash screen)
how much progress has been made so far. Not because such an API would
be tricky, but because it's unlikely that your startup code has some
simple way to gauge its progress. Still, integrating splash screen
processing is a good idea, will make sure it's on the list of
outstanding issues.
Posted by: hansmuller on January 31, 2007 at 11:25 AM
-
[response to wsnyder6]
Although general purpose GUI markup specifically not in scope for this
JSR, resources whose values are lists of action names would facilitate
creation of toolbars, menubars, and menus. That plus an Application
subclass that automatically created a toolbar and menubar given
those resources might make things easier.
Posted by: hansmuller on January 31, 2007 at 12:37 PM
-
The timing couldn't be better as I am on the lookout for an app framework myself.
ovisvana
Posted by: ovisvana on February 01, 2007 at 04:24 AM
-
@Hans: regarding Preferences being usable only by privileged applications--I did not know that! Very useful to know. At the risk of sounding stupid, surely...surely an applet, say, or some other untrusted application running in webstart or something could provide a suitable PreferencesFactory to work around this? Surely that's what was intended? Or is there some other aspect of the library that prevents its use by untrusted applications?
Posted by: ljnelson on February 01, 2007 at 05:23 AM
-
I'm with Michael Bushe, I'll put it into production first thing tomorrow on the Kepler project (http://kepler.nasa.gov/).
Michael, your EventBus is already in production ;-). Many thanks. Wondering how your EventBusAction and @Action will marry...
Thanks Hans and Ben!
--Bill
Posted by: wohler on February 05, 2007 at 09:08 PM
-
[response to ljnelson]
I'm not really sure what the designer of the Preferences API intended
(he's no longer at Sun or answering questions about it) or what the
field of use was supposed to be. Given the importance of running
desktop web applications in the sandbox, I can only wonder. As far
as finding a way to sneak into the API without privileges, for example
by installing a PreferencesFactor ... All of the entry points that
yield preferences nodes are static and require privileges. I put a
slightly more detailed writeup of the issue here:
https://appframework.dev.java.net/faq.html
Posted by: hansmuller on February 08, 2007 at 03:16 PM
-
I wonder why this framework depends on extending classes. Many Java developers have recognised that subclassing isn't generally a good idea, so it surprises and disappoints me to see new frameworks appear that rely on subclassing.
If this were interface-based, it'd be easier to mock the framework for testing. As things stand, subclasses are either not able to be tested standalone or the superclass needs to explicitly support that.
Consider an example that's already in Java - it's not possible to instantiate a subclass of JDialog in headless mode, making it tricky to automatically test code.
Posted by: ricky_clarkson on February 14, 2007 at 06:53 AM
-
Hi Hans, nice to see that JSR 296 is moving along. We have a nice Swing app framework but we are in the process of coming up with a long term roadmap and are evaluating other Swing frameworks. We'll be checking out the progress on this project. Good luck!
Posted by: davidson1 on February 15, 2007 at 12:31 PM
-
From the examples you gave, I think that there are a lot of downsides of using resource bundle to specify gui components like menu and layouts.
1) not hierarchical and verbose (note how your specify button.title, button.icon, etc)
2) difficult to internationalize
3) difficult to localize
Either CookSwing and SwiXml are a lot better for the task. I know that you did a review on XML->Swing toolkits. I am curious why you go with this approach? I doubt performance is an issue, since displaying GUI on screen for the first time actually takes much longer.
Posted by: coconut99_99 on May 30, 2007 at 06:55 PM
-
I'm so grateful for all that you've done. Thanks again for that nice essay and I would be most grateful if you would send me the latter ones....
mirc
mırc
mirç
mırç
mirc indir
chat yap
islami sohbet
dini sohbet
kelebek
kelebek sohbet
kelebek mirc
kameralı mirc
kameralı sohbet
chat yap
çet
çet odaları
sohbet kanalları
sohbet odaları
yarışma
sevgili
arkadaş
arkadaş ara
arkadaşlık
Posted by: jklmno on June 19, 2008 at 09:16 AM
|
java.net RSS Feeds
