July 01, 2005

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.


- One comment Not publicly viewable

  1. Chris May

    storing session context in one thread per session

    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.

Trackbacks

July 2005

Mo Tu We Th Fr Sa Su
Jun |  Today  | Aug
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Search this blog

Tags

Galleries

Most recent comments

  • Good luck, Jon. Thanks for your helps in the past 3 years. by Hongfeng Sun on this entry
  • Good luck in the future by Mathew Mannion on this entry
  • It is indeed. And when I look out of the nearest window at work, I see Charter Avenue, where parking… by on this entry
  • There's very little free parking on the rest of campus, so why should westwood be treated favourably… by on this entry
  • I live in Earlsdon. I can drive, but haven't since I came to University here in 1990 (I never left –… by on this entry

Blog archive

Loading…
Not signed in
Sign in

Powered by BlogBuilder
© MMXIV