Thursday at Java One
James Gosling's keynote
More a collection of demos than a keynote. Included some Netbeans stuff, the Boeing drone piloted by real-time Java and the Bay Area sea sensor net. John Gage also demoed a GUI that moved apps (threads, stack and all) from a PC to a mac, and miniature ARM devices with wireless and motion sensors that let him "pour" an app from one to the other.
Futures panel
Built somewhat on the demos and Sun's motto since inception that "the network is the computer". Computing devices are getting everywhere, and the limitations on Moore's law will see a trend to multicore devices. The future is in collaborative applications that can move among devices, the huge computing power probably being employed for VR and biocomputing.
Writing secure web apps
Added very little to yesterday's session other than plenty of examples.
Beyond blogging: feed syndication with Java
A good overview of the protocols and Java tools from the architects of Roller, ROME and FeedParser. Why Atom is so much better than RSS and the atom protocol so much better than the blog-publishing XMLRPC protocols.
Extreme reuse in JSF
A good comparison of the advantages and disadvantages of JSP2 .tag files, tiles, webwork and Oracle ADF for re-using visual components with JSF.
The next impedance mismatch: POJOs to XML
ORM is now pretty well understood but OXM is younger. Some problems are shared but XML mapping has some problems of its own, especially around many-many mappings and where objects must be populated from a pre-existing schema. Need an OXM persistence manager to cope with situations like when the namespace is changed – don't want to redo the OXM from scratch.
End-to-end UI objects
Third talk I've been to this week suggesting that building UIs from objects (cf Spring) is the best way (since it's OOP) and looking for a Java solution. This talk from an embedded-UI guy where J2EE is too heavyweight anyway. Suggests composing UIs from object components corresponding to DOM objects, and storing session context in one thread per session (which sounds elegant; do any web containers do it this way?). Good for modelling page flows, good MVC, tiny footprint, bad for bookmarking, separating grahical design and changing rendering.
01 Jul 2005 00:55
| 
Comments (1)
| 
Report a problem
Loading…
Chris May
Intriguing. You'd need a big pool of waiting threads to manage a large application, though – I would think that the OS might be a limiting factor here.
And how would you managed to reassociate the session with it's thread, when your listener receives a new request? You don't want to block the listener whilst you try and identify the session, so you'd probably need one thread to handle the request and identify the session, then suspend that thread and transfer execution to the session thread. Seems a bit fiddly to me, but maybe I've mis-understood how it would work
01 Jul 2005, 11:42
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.