Wednesday. I have an absolute full day from 8.30 till 11pm. I miss Oracle's keynote on 10g because I keep talking with a friend of mine at the breakfast about Java development on a mobile platform. My first techinal session is "Web Beans update", purely chosen because of the speakers, Gavin King and Bob Lee (if you don't know who these guys are, you are probably not developing Java web apps). It's an interesting session on this effort of unifying the IoC models to make the beans available to various web application frameworks in a standard EE way. I'm sure both of these guys are more than capable of making impact and creating better, practical solutions, but getting the mechanism standardized between all the invested parties... well let's just say my confidence on Java "standards" has taken some hits over the past few years.
I'm also checking out Java Persistence API 2.0. They contain a lot of low-level details of what going to be added, but mostly things that vendors/fore-runners, such as Hibernate, have already added (e.g. persistent lists), so the standard is just keepin up with the implementation extensions. I think that's the only way to make the standars really.
In the afternoon, I'm attending the location API 2.0 JSR update since a friend of mine is working on that; pretty different from my field but interesting stuff. The rest of my sessions are however focused on desktop Java and especially on Eclipse RCP. The RCP session is cool: the guy just goes through a lot of code showing how to implement a complete standalone RCP app. This will hopefully come in handy in a relatively short timeframe. I also go to "project Darkstar", which is Sun's new framework for "massive online" games. Obviously the idea is to strengthen Java's position as a gaming platform, and if I were to guess, mostly in mobile space. Nevertheless, Darkstar's core idea is this persistent storage capable of handling high volume of simultaneous write operations and synchronizing the data on multiple clients. So no relational database there. While targeted as a gaming platform, an "unnamed" vendor had re-implemented their auction system in Darkstart and claimed 15 times better through-put compared to their existing relational db implementation. Not bad at all.
In the evening, I happily skip both Eclipse and Google parties, and go for Howard Lewis Ship's Tapestry 5. I have no notes of the session because Howard simply demoes T5 by writing code with it and the slides he has go through the benefits of the framework which I knew already. While still in development, it's *the* most impressing web application development framework for Java at the moment. There are plenty of other frameworks that may have the wow effect, but none of them are as comprehensive as Tapestry as a whole. The late-night session, starting at 10pm is about Grails, so I don't have a choice but to go there as well. It's interesting to compare Grails to Tapestry. Grails guys openly say the are not a component-oriented framework like Tapestry, which is a immediate turn-off for me, but in comparison, Grails has a much deeper integration to Spring and Hibernate as well as I had expected. Their approach to persistent entities and domain-driven development is very similar to Trails albeit they don't generate the UI for you automatically. Any domain object can be immediately stored as persistent entity and associated rely on Hibernate, just like in Trails.
Day two raw notes:
---
Missed GS Oracle 10g
TS-4089 Web beans update
JSR 299: web beans
web beans address
- need for a unified component model
- managing state, scoping, conversation management
- finding compoennts
- configuration, minimize external configuration via use of annotations
relationship to Java EE
- web beans may be used seamlessley as JSF managed beans
- EJB 3.x components may be web beans
- the core of web beans is being architecte to have no hard dependency on JSF or EJB
all about loose coupling: decouple implementations, lifecycles of collaborationg components, orthogonal concerns
ingredients: API, implementation, scope, name, binding annotations, priority
kinds of components
- stateful and stateless session ends, including webservice endpoints
- entity beans
- any Java class
legal to have multiple implementations of the same compoennts
components have priorities
@Component(type=Greeting.class)
// Specify a unique identifier as Hello is known
@Component(type=Greeting.class, priority=MOCK)
// Moch has a higher priority, so if it exists, it's the preferred implementation
ejb 3.0 spec defined a nice interceptor model that is to be extended to web beans
web beans scopes: no scope, request, session, conversation, application
custom extensions to scope: business process, cluster, method
pico, spring, guice, ejb 3.0 all enject at component instantiation time
seam injects at method invocation time
- via setter or direct field access
- extreme loose coupling
- benefit is that you can define a bean in application scope that has a dependency to a bean in narrower scope (not possible in Spring, JSF, Guice...)
specifying component scope
@SessionScoped @Stateful @Component
custom scopieng
@Dcoumented
@Target(TYPE)
@Retention(RUNTIME)
@ScopeType
use context API to manage the lifecycle
@AroundInvoke
components with multiple roles
@Compoennt(name="user")
@Roles(LoggedIn.class)
... hmm this is interesting take on instance-based security implemented with ORLE
@Comopnent(name="loggedInUser")
using both roles together
@Component class BanUser
finding compoennt by type - used exclusively in Guice
binding annotations
- used to find componets by type
- describ the component
- reusable across types
- not just markes, can have attribute value, e.g. @Named("Gavin")
find by type
@In Service service
TS-4945 Java Persistence 2.0
introduced in JSR 220
surprisingly good response
but some problems in 1.0
2.0 goals
- solidify the standard
- clarifgy open issues
- reduce non-portability aspects
- standardize optional functionality
proposed functionality
- more flexible modeling capabilities (ordered lists, collections of string... mostly implemented in Hibernate already)
- expand ORM
- mapped superclass for embeddables
- in JPA 1.0 @OrderBy sort order when a collection is retrieved, but developers want persistent ordering
- persistent ordering with @Ordered @OrderColumn...
- AccessType(PROPERTY) for ambiguous cases (both field and property level access available)
- unidirectional one-to-many relationships using foreign key mappings current not supported (always using join table)
- add unidirectional one-to-many
inheritance mappings
- currently support single table per class or joined subclass strategy
Java persistence query language
- select still too constrained
- queries are always polymorphic - get that type and all subtypes even if that's not what you intended
- criteria queries: allow "node-wiase" query construction (i.e. "address.city") doens't work in Hib3 currently, I wish it did
unfetched state
- detached entities often have unfetched state and/or relationships
- what happens on access to unfetched state is currently undefined, implementations place different burdens on clients
- entitymanager needs to about the open transaction, either get em while transaction is open or em.joinTranscation()
container-managed extended persistence contexts
- becoming increasingly important to support conversations
- issue: stateful session bean "passivation" - for scaling, failover/replication
validation
@REquired, @Max(240)
user defined
@AdequatelyCompensated
TS-5345 Location based services
80% of wireless subscribers are interested in one of more LBS apps
80% of respondents would leverage personal navigation and LBS content
25% of WCDMA handsets will have GPS by end of 2008
development challenges
- privacy concerns
- slow implemntation of locatoin technologies
- hard to develop applications
JSR 179 standardizing location retrieval on Java ME
JSR 293 standardizing access to location-based services from Java ME
- mapping
- navigation
- geocoding and reverse geocoding
- landmark exchange
sample use case
- route planner
- restaurant locator
- service search
- hikiing trails service
API design details
- defines separate java.microedition.location.services
- provides mechanism to discover and select different service proivders
- allows service request in two modes: provider takes control and handles all communication, or the application is in control
geocoding service provider
- applications control the dialogs shown to the user by the gecodoing service
map service porvider
- applicaiton can request map image with selected items from the map service provider
navigation service
landmark exchange
- the format hasn't been agreed
- also defines a set of global landmark categories
what's the default set of categories?
improves on JSR 179
TS: JSR-3938 The last mile of Java desktop
2GB Heap limit
- actually even less ~1.5GB on Widnows
file chososers - users spend a lot of time with these
JFileChooser just has way less functionality
java.awt.FileDialog native, but restrictive
Licensing
has to use native code
bytecode is readable (and modifiable)
don't force the license check in Java, because it can be bypassed
obfuscation - see progaurd. Cool but a hassle if you like stack traces
digital signing: sign you jars, obfuscate the verification - more native code
desktop GC
useful option: -XX:+UseParallelGC
problems: GC fails to keep up with the user, GC blocks the app intermittently
standard APIs replaced
- printing (can't have sticky printer options)
- imageIO (it's good, but not fast enough, no full image data)
- color management (needed thread-safe color space conversions)
- JavaHelp tool (its HTML renderer is non-standard)
Standard API we replaced
- JOptionPane (accelerator keys don't work, close to Windows default, but not user-friendly)
tips and tricks
- my documents (it's localized)
- find the color profile of a display device
- resovle file "shortcuts" and "aliases"
- bring a window ot the front
mac-specific tips and tricks
- screen menu bar with -Dapple.laf.useScreenMenuBar=true
- application menu - use a native launcher to control the meenu
- sheets
- specialized system properties: showGrowBox, fileDialogForDirectories, brushMetalLook, etc.
- use Quaqua, not Aqua
why LightZone chose Java
- almost all the code is cross-platform
- JAI API works great
- easily integrate third-party libraries wehn needed
- easily integrate native code when needed
Good presentation, check out the slides
TS-3774 Anatomy of an Eclipse RCP Application
Equinox is an OSGi implementation
possible to impelement an RCP stand-alone but one that can be run in other contexts, e.g. as a Eclipse plugin
workspace back end: not intended for RCP applciation, but ties directly into "IDE" behavior
check out Eclipse Mylar - only shows you things you are interested in in Eclipse (only those methods you frequently work on etc.)
Nebula - Eclipse project that provides widgets for Eclipse apps
TS-1786 Writing Games with Project Darkstar
BOF-6563 Tapestry 5
fix for the frustration...
BOF-6133 Grails
custom view technology with GSP and dynamic tag libraries
an extensible plug-in system
used in real projects even currently
API integration
- groovy doesn't introduce new classes that would replace Java classes
uses Spring underneath
clean error reporting
Posted by thoughts at May 11, 2007 01:21 PM | TrackBack