Bloggess

JavaOne 2011 - Tuesday

2011-10-16T16:04:00.000-07:00

Keynote

They are moving performance improvements from the JRockit JVM to the official, common JVM. But, I talked to an Oracle guy in the Exhibition Hall later about this, and he said that JRockit will remain a separate product. Most of the core features will remain in JRockit. The official JVM will get bits and pieces of it.

Twitter is joining JCP and the contributing to OpenJDK, specifically the nextgen GC.

JNI was "intentionally difficult" because they wanted to encourage developers to stick with Java and avoid native code. There are plans on making native code this easier, but probably not until Java 9.

JavaFX again?! Oh, wait. They are running it on an iPad and a Sumsung Galaxy tablet! They found a way to bundle a mini-JVM along with a downloadable app! But, it is a very early alpha version, and JIT wasn't working yet. That would explain why performance didn't look great. If they can get this working, I'll be able to write Java apps and package them up as apps for iOS and Android without learning screwy APIs.

An ESPN guy was talking about Glassfish's scalability, processing 3,000 requests per second.

Project Avatar is about tighter HTML 5 support with Java, whatever that means. This includes support for HTML 5 as the UI talking to a JVM... perhaps a new "hybrid" JVM running on iOS.

Data Parallelism with Fork/Join in Java 7 - David Holmes

A good, focused, detailed presentation.

Threads are coarse-grained, designed more for multiple processors than multiple cores or hardware threads (as in Intel's HyperThreading). Hmm... I remember an oddity from the Win32 API called "fibers" that act as lightweight threads that cuts down on the overhead of context switching at the expense of the app developer handling more of the scheduling. (A remnant of the days of slow single-core CPUs.)

The challenge is finding problems that match the Fork/Join framework; only certain algorithms can be expressed efficiently in divide and conquer form.
A good design pattern to is check a sequential threshold to see if it's even worth the overhead of splitting up the task. In other words, doing a parallel MergeSort on 10 times is ridiculous.
Need to have a thread pool that is ready to handle tasks. Could use ThreadPoolExecutor, but we want to avoid the overhead of FutureTask. So, we have optimized classes for F/J, like ForkJoinTask, ForkJoinThread, ForkJoinPool. This uses a specialized thread pool for CPU intensive tasks with little blocking.
F/J has a concept of "work-stealing," where threads with empty work queues steal work from the end of other threads queues. Makes sense.

David showed some API use cases, merging the left / right pieces into the final result, using shortcuts like invokeAll(left, right).

A key dilemma with F/J... how do you figure out what the magic threshold is, where you decide to advance from a sequential implementation to a parallel implementation?

Magic threshold = N / (loadBalanceFactor * numberOfCores)

...where N is the size of the problem (not sure exactly how this is defined), and a loadBalanceFactor of 8 usually creates enough subtasks to keep multiple cores happy. Of course, don't overburden the CPU(s) with your many subtasks... it has other work to do.

Java 8 will have more parallel algorithms built-in for default collection operations such array sorting.

As other presentations showed, processing a lot of work in parallel on a beastly machine does not scale linearly; it dramatically tapers off at some point. The difference in performance between 16 vs. 32 vs. 64 cores is disappointing.

What's New in Grails 1.4 (2.0)? - Graeme Rocher

All right! Mr. Grails himself at JavaOne! Wait... where is everybody? The session is about to start. Are JavaOne attendees really dozing off in Jurassic Server Faces sessions at this time?

There are over 700 Grails plugins. Graeme admitted that you have to sort through the... umm... rough to find the diamonds in the rough.

New in Grails 2.0

Sexy console UI with interactive mode and tab auto-completion.
Better unit testing.
Much better error reporting, which highlights the code where the error occurred, both in the controller and the service. Wow, I don't think JCP members would ever approve of something like this. It's too useful and pragmatic.
Shipping with H2 console for testing against in-memory db. Nice, but most projects in my group have at least a bit of Oracle-specific SQL.
Groovy 1.8.
Probably Spring 3.1; likely to leverage its cache annotations and environment profiles.
Hibernate 3.6. It's about time. I hope this doesn't break our weird mix of Hibernate and JPA annotations, along with Hibernate XML in the current project I'm working on.
Tomcat 7 (with Servlet 3.0 support) is the default. Tomcat 6 still supported. Target servlet container can be specified in config.
New runtime auto-class-reloading agent in "grails run-app" that handles services and domain classes! So, less need for "grails clean." This JVM agent proxies the reflection API; it adds slight overhead in dev mode. The reloading agent can be activated with other Grails commands with "-reloading" switch.
Plugins are finally pre-compiled into JARs (instead of getting splattered throughout the WAR archive). Grails plugin handling is weird; this sounds like a welcome change. Dependencies are declared more like standalone Grails projects. Thank you.
Mostly for testing purposes, can render GSPs without actual request object.
Resource management plugin integrated into core Grails. Separate cache and zip plugins. Separate client side resource files like CSS are bundled into a single file. Nice!
GORM is a separate project with different implementations like JPA (not tied to Hibernate), Redis, MongoDB, etc.
New compile-time type-checked query DSL, using AST. Yes, this is like JPA 2.0's new criteria API, without the ridiculous syntax.

... more to come.

over

JavaOne 2011 - Monday

2011-10-10T21:54:00.000-07:00

Keynote

JDK 7 features

Fancy multi-catch exceptions with better resource handling. Yeah, I kind of wanted a feature like this. But, I seldom have to deal with that many different checked exceptions at once. I admit... when I come across tons of annoying checked exceptions, I usually just catch a common superclass of them and wrap it in a RuntimeException and re-throw it.
AutoCloseable... to help with resource cleanup when exceptions are thrown. Makes sense.
Safe varargs. Not a big deal.
InvokeDynamic (JSR-292)... the first new JDK bytecode in many years. Allows for native-like optimization of method calls in JVM implementations of scripting languages. Uses a function pointer API to wire-up (bootstrap) methods. In other words, the scripting language implementation tells the JVM how to make the calls. Sounds like Groovy 1.9 is going to leverage this. Sweet.
Fork/Join framework. Gives you a nice API for divide-and-conquer algorithms like MergeSort that can be split into subtasks, run on different threads, and merged together into a result. Takes care of the difficult subtask synchronization for you.

JDK 8 features

Lamb-duh expressions. At last! Closures! Why didn't this make it into JDK 7? Maybe because there is still much work remaining to extend the Collection API and other core Java APIs to benefit from them. Without decent core API support, this feature would no doubt irritate Java developers who haven't yet discovered Groovy. Not surprisingly, lamb-duh looks almost exactly like Groovy closures.

"Duuuh..."
Default methods on an interface. Allows you to extend interfaces without breaking them. It's about time. Hopefully, this will cut down on the need for "adapter" classes, which provide default implementations for cumbersome interfaces. Of course, you can only extend one class, so you can't always take advantage of adapter classes when you are implementing multiple interfaces... or when the annoying interface is orthogonal to your object hierarchy.
Jigsaw. Declaring components in Java code and resolving dependencies, kind of like Maven, Ivy, etc. There is supposed to be some kind of support for Maven POMs and OSGi. Yes, the same stuff they talked about 2 years ago with modular JVM pieces.
A new Date/Time API (JSR-310). Looking forward to this. They botched this API in Java 1.0, and they've been dragging around deprecated baggage ever since.

JDK 9 features

Self-tuning JVM, more native integration, better support for big data. Although there are 64-bit JVMs, many JVM internals are still 32-bit. If you have tons of gigs of RAM to spare with your 64-bit JVM, you still need to deal with 2GB array and string limitations.
Tail calls / continuations. Hmm... something that has to do with closures and stack handling?
Better support for multi-tenancy per JVM.
Better resource management.

JavaFX 2.0

The keynote moved into the JavaFX territory, and immediately, the crowd thinned out.
Something about "FXML" for defining the UI.
Importing Maya files for 3D. Don't get me started about expensive, awkward, overblown 3D software. Ok, I'll try to keep an open mind about this API...

They kicked around some ideas about PaaS and cloud, like metadata that defines DataSources, QoS, elasticity, etc. It is getting gloomy and overcast here in SF....

The Future of Java and Continuous Integration

This focused on Hudson, which is used by the Eclipse project. A weird morning "open panel" discussion about CI that didn't have much of a purpose. Some points...

Even with small teams, it's important to have a repeatable build/test process. Don't rely on one developer building everything from his workstation.
Pre-flight... developer runs CI tests before check-in, to avoid broken builds.
How do you run CI in the cloud? Oh, come on! Could you leave cloud talk out of at least one session?! Yes, you run CI in the cloud just like you would outside of the cloud. If you've done CI correctly, you would have separated what needs to run from where it needs to be run.
Anti-patterns. Don't overload to servers with too many build processes. Use multiple instances. Careful with unstable plugins.
It would be nice to have a single meta-data model for Maven, CI, SCM, your favorite IDE, etc. that describes environment-specific properties.

Extending Java's Reach with Groovy -- Dierk König

Some creative analogies presented here, aimed toward those unfamiliar with Groovy. Not much Groovy meat.

Super Glue. Combining different JDK features with Groovy. Um, ok.
Liquid Heart. Keeping entities, relationships flexible by evaluating scripts. For instance, GroovyShell.evaluate().
Lipstick (on a pig). Move ugly APIs into a more natural-looking DSL.
New in Groovy 1.8, @TupleConstructor is a handy way to automatically create constructors out of properties. But, this is based on the order in which you define properties, so you have to keep that in mind. I like the map-looking approach, where you specify whatever properties you'd like to set by calling a pseudo-constructor:
new Conference(name:'JavaOne', year:2011)
Keyhole Surgery. (Where does he come up with these analogies?) Send Groovy code to live apps for diagnostic runtime evaluation. Building something like a Grails console into your web app that evaluates posted Groovy code? Hmm... useful, but a bit of a security hazard!
Unlimited Openness. Easy code changes and reuse of existing code.
Ghostwriter. Hook into the compiler to produce bytecode... making use of AST transformations, maybe? He was a big vague about this, but he has an entire talk devoted to this, so maybe he was trying to generate interest.
House Elf. Using Groovy to help with build automation, CI, deployments, etc. Is Gradle worth looking into? The speaker seems to think so. I'm not that interested right now.

"House Elf? I find that offensive."

State Management

This is the first of many annoying sessions that can be summarized as: "This proposed standard has a lot of work remaining. I'll talk about the ideas that we're kicking around. By the time the standard is ratified... it may look totally different."

So, this is JSR-350. What's the first topic they'll bring up? Take a wild guess.

"We need a file system for the cloud."

Aren't there wrappers around Amazon S3 that do this? I don't know... I haven't looked at that in a while.

We need a standards based state management system with pluggable state providers... an ecosystem where applications declare their state management needs, and the state management system finds a set of best-fit providers. Much easier said than done.
Some kind of State wrapper to be used with a state manager singleton instance.
Make copies of state data to avoid sync issues on live objects. Sounds inefficient.
The biggest challenge is adoption. How do you get other specs like Servlets to accept this? Hopefully, the JSR-107 and JSR-354 guys are keeping this in mind.
Maybe end of 2012 final release.

Pro Groovy

This was an odd session with no agenda other than "let's blab about Groovy." About the only interesting item mentioned was GPars, a library for parallel processing, like Fork/Join in JDK 7.
GParsPool.withPool { ... } and collectParallel { ... }.

JVM Bytecode for Dummies - Oliver Nutter (JRuby guy)

This was a very interesting, in-the-guts look at tools for generating bytecode.

Some things are possible through raw bytecode that are not possible in Java. These tricks are used as optimizations in scripting language implementations like JRuby and Groovy. Trying to disassemble a JRuby class file with javap will result in some weirdness.
If interested in ASM for bytecode generation, try ASMifierClassVisitor. This creates the ASM code that would generate bytecode for your Java code.
BiteScript is a JRuby library for generating JVM bytecode. Most of his bytecode generation examples were in BiteScript. It has macro support (like the old Microsoft Macro Assembler) to help generate frequently used blocks of bytecode. JiteScript is a Java bytecode generator that mimics BiteScript, but it's not quite as flexible.
Mirah is a Ruby-like language that directly targets the JVM.
Oliver gave a whirlwind tour through the entire set of JVM bytecodes and gave examples of the how the pseudo-registers and stack get set up when executing your code.
The stack is really designed to handle 32-bit integers. Bytes, shorts, chars all treated as integers.
There is a GOTO bytecode (to implement branching), even though there is no goto keyword implemented in Java.
Of course, there's the new invokedynamic bytecode... something about method handles, CallSites, and generating a bootstrap that gets called for future method invocations. Doesn't sound like something I'll be implementing without a tool like BiteScript or ASM.

JavaOne 2011 - Overall Impressions

2011-10-10T20:26:00.000-07:00

"JavaOne 2011: Moving Java Forward" (...one agonizing inch at a time.) It seems I went straight from JavaOne 2009 to 2011 to see a few projects slowly advancing and... THE CLOUD. Everyone has a cloud solution.

"You're seeing the cloud in commercials, so it must be a big deal, right?" You mean that commercial where some couple is stuck at the airport and the guy has a could epiphany that brings them perfect HD streaming of their favorite stupid TV shows to the airport?! "To the cloud!" Thanks, Microsoft.

So, all the fancy Java 7 features they were bragging about from 2009 are finally available. And let's start hyping all the upcoming Java 8 features so we'll have something to look forward to in 2013. Yes, features that the Groovy community has been enjoying for years.

Hey, a pinball arcade! Too bad Twilight Zone was in bad shape; it's regarded as one of the best.

I'll go over the sessions next...

JavaOne 2009 - Wrap Up and General Sessions

2009-06-12T06:00:00.000-07:00

Wrap Up

Forecast: cloudy. I'm not just talking about the cloud hype. I mean that a dark cloud was cast over the conference by Oracle's Sun acquisition. No one seemed to talk about it much, but the gloom was there. Should we be worried? Much of the "Java innovation" going on now is happening outside of Sun, anyway. Here's what Rod Johnson thinks about it.

JEE6 will have some nice features for web apps like bean validation (see Thursday's notes) and dynamic servlet registration with Servlet 3.0.

Groovy and Grails is immensely popular, although there weren't too many sessions on it.

JSF 2.0 integrates many community developed features like Facelets into the standard and provides easier custom component development and nice resource handling. But does it go far enough to support Web 2.0 apps?

I was surprised and a bit annoyed by all the JavaFX hype. They really want to see this running everywhere, even on TV sets.

I didn't spend much time at the Pavillion, but I did get some photos of Neil Young's Java car and the Qualcomm Plaza booth. For the rest of this blog, I'll put my commentary in green to separate it from my notes on the sessions.

General Sessions

Video from the general sessions is available here. Chapter 2 of "Your Java Lifestyle" features a Qualcomm presentation on Snapdragon-based smartbooks; wait for it to load and skip forward to 19:30.

There was an IBM-heavy general session. There's now a free version of WAS for developers, and IBM is getting cloudy with the "WebSphere CloudBurst Appliance," an expensive purple slab that dispenses WebSphere VMs.

Tuesday's technical general session was interesting. The JDK was getting too fat, so they modularized it in JDK 7. Modularity is acheived through JSR 294 and Project Jigsaw. You can express dependencies in a module-info file, kind of like Maven's POMs, without verbose XML. The base Java 7 module is 1.3MB, requiring a "boot" module of 4MB. I remember hearing from the previous JavaOne that modularity will be supported both the "official Java way" and through OSGi. Is it worth looking into OSGi now or should we wait for Java 7? It might be worth looking into for large projects. Also, GlassFish 3 is OSGi-based and is aware of OSGi modules in your app.

Also in JDK 7 is improved support for scripting languages, including a new JVM bytecode instruction: invokedynamic (JSR 292). There are some minor language enhancements, like the diamond operator <> to make generics more concise. Other new things include parallel class loaders, the G1 garbage collector, and compressed 64-bit pointers. G1 is available now with JDK 1.6.0_14. Here's how to enable it. But, they don't recommend it for production yet.

JDK 7 Milestone 3 is available now, with a RC slated for Feb 2010.

JEE6 (release planned for September) provides profiles, so you can choose which modules to use. This should include JSF 2.0, async servlets, dynamic servlet registration, and JAX-RS for RESTful web services, EJB 3.1, and bean validation (JSR 303).

JavaOne 2009 - Friday

2009-06-12T04:05:00.000-07:00

JPA Mapping Magical Mystery Tour - Michael Keith

This session's description sounded interesting, but the speaker only covered basic JPA stuff, even after surveying the audience about JPA expertise. Looks like I wasn't the only one in the audience looking for something more advanced. What I liked about Monday's JPA 2.0 Java University talk is that the speaker surveyed the audience for various areas of JPA / SQL expertise, then she adjusted her talk accordingly.

In JPA 2.0, embeddables can now override fields of the container entity, allowing for greater reuse across entities. For instance, your embeddable class may have an "address" field, but container entities may have "userAddress" or "addressLine" or whatever. Yeah, that's about all I learned from that talk.

Building Next-Generation Web Apps with the Spring 3.0 Web Stack - Keith Donald and Jeremy Grelle

Spring 3.0 Web Stack supports: Spring Faces (JSF support), Spring Blaze DS (Flex), Spring Web Flow (for stateful conversations), Spring JS (for Ajax and JS / JSON integration).

RESTful @MVC is the preferred controller model for Spring MVC 3.0. This organizes services around logical resources, as "domain-driven design for web apps". Sounds Groovy.

@Controller - controls access to resources, delegates to views to render resources.

Supports content negotiation (through ContentNegotiatingViewResolver), so that the right content is rendered for the client... either by the HTTP Accepts header or by file extension.

@RequestMapping annotation maps pieces of the URL request path to your method parameters. Refer to Rod Johnson's Spring 3.0 Framework talk from my Tuesday notes.

Spring JS Abstraction

Integrates Dojo, served out of a JAR. Why did they choose Dojo? Seems like a vapid framework next to jQuery and Prototype. IBM also chose Dojo for their Google Gadgets support in WebSphere Portal. Probably not a good sign. And where did the word "vapid" come from? I haven't used that word in years!
JSON support is provided through Jackson.
The goal here is to support Ajax, rich widgets, client-side validation... to take content and add behavior to it through "decorations." These decorations can be added from the client-side, through JS: Script.addDecoration(new Spring.AjaxEventDecoration(...)), where you specify the DOM elements to re-render through the Ajax call. Also useful for form validation. This looks similar to what JSF 2.0 is trying to do, borrowing from RichFaces.

Spring Web Flow - Useful for controlled web navigation that goes through multiple steps, like a "wizard" type of interface. Supports Ajax partial page re-rendering as part of the flow. The flow is declared through annotations; @Flow extends @Controller.

Expect Spring 3.0 RC1 later this month. 3.0 final maybe late July / early August.

JDBC? We Don’t Need No Stinkin’ JDBC. Scalability at LinkedIn. – David Raccah and Dhananjay Ragade.

This talk was very interesting, and many of the ideas here are useful for high traffic sites.

The 3 keys: performance, availability, and reliability. People confuse availability and reliability. Availability means: it’s there; it’s running. Reliability means: it’s performing its function.

Secondary keys: scalability, manageability, serviceability.

Simple dbs (KVSS = Key/Value Storage Systems) are making a comeback. Complex systems that implement ACID, use stored procedures, etc. don’t scale well.

The opposite of ACID systems = BASE. That’s about all I remember from chemistry class. They go against traditional db rules…
-Basically Available
-Soft state (where data may be out-of-sync for some time)
-Eventually consistent.

Traditional db constraints don’t work well with partitioning. KVSSes are more scalable, with limited ACIDity. It’s hard to get transactional AND scalable behavior.

Best Practices:

available, reliable data storage.
Ideally, front-end your data layer with a service for abstraction. (Companies like Amazon helped put SOA back on the map. SOA is good, but don’t go crazy with it.)
Create a bus to route replicated data to consumers for search, etc. (This is not necessarily an ESB; that’s more for the business side of things.)
Parallelize this bus through scatter / gather, etc.
Keep system stateless. Having to deal with session affinity stinks.

The trick is to get BASE to work like ACID. About 98% of LinkedIn is served from a cache. Determine how important data consistency is for your site. If you can deal with some inconsistency, try BASE. If you need immediate replication of changed data across your cache instances, consider something like a Paxos implementation that guarantees consistentcy. Google uses this in something called Chubby. Apache ZooKeeper is another Paxos-like implementation.

There is usually just some core data that needs to be ACID (usually for writes), and the rest can be BASE. For instance, when you update your profile in LinkedIn, you will see your changes right away because you're looking at the core data. Other users are hitting the cache and may not see your update right away. LinkedIn has a "CoreDS" service to handle the CRUD operations and store the master data. The "RepDS" services receives updates via a bus and updates the replicated caches. "ReaderDS" reads from the cached data only. If a read request comes in for something that is not in the cache (or expired in the cache), it will pass along the request to RepDS, which in turn may call CoreDS. Or course, all this works well for systems that are largely read-only.

Their implementation started out as many tables in 1 db, and the queries resulted in too many joins. They moved the data to XML that is split up between tables and kept track of versioning using an XML Schema for each version. Oracle 11g is more efficient with XML than 10g, but they were just storing it as unstructured XML, Oracle didn't do any interpretation of it. StAX was used for XML parsing; it's very fast, but a bit unfriendly.

Conversations and Page Flows for JSF - Dan Allen

JSF's idea of state is something that goes on in the UI (component tree); it lacks a stateful model to back the UI.

By default, a conversation only lasts for the request scope. There are 2 types:

Ad-hoc - a user goes wherever in the app, the goal of the conversation is vague. This is only supported in Seam.
Constrained - user is guided by page flow.

A page flow is a progressive series of states (pages) with constrained transitions. It must have a clear start and end.

Conversations in Seam are controlled declaratively; no extra setup is needed. jBPM and jPDL drives Seam page flows, which are registered in an XML file. Conversations may be nested (sub-conversations) and "workspaces" handle multiple conversations per session.

In Spring Web Flow, conversations must have a constrained flow. (Grails uses Spring Web Flow.) You can have sub-conversations, like in Seam. Flow names and flow tokens are passed in the URL: /app-path/mvc-handler/myFlow?token=1. Partial page updates are defined in the flow's xml.

You'll probably need to extend the persistence context for the conversation, or else you'll get LazyInitializationExceptions from Hibernate.

Buliding Enterprise Java Web Apps with Google Open-Source Technology - Dhanji R. Prasanna

Google Guice is a Dependency Injection framework that supports AOP and annotations. Why on earth use this instead of Spring? Sounds like yet another weird mostly in-house Google thing. That's kind of interesting is that they use Java code to bind the interface with the implementation, like bind(a.class).to(b.class). Different syntax from Spring Java Configuration, but a similar idea.

GWT (pronounced "gwit") includes an optimizing Java to JS compiler. "Hosted" mode runs on the server as Java, and "compiled" mode runs on the browser as JS. The UI is decomposed into modules; each must act as a good citizen.

iGoogle uses GWT.runAsync() to pull down the individual components after the initial page loads.

Google Gin is Guice for GWT... so your DI stuff can be done on the client-side, too. Server modules can also be leveraged on the client-side, and the generated JS can take advantage of Java-like features like type safety.

WebDriver is a browser driver for acceptance testing; it uses a Java API (looks easy to use) and a browser plugin instead of driving the browser through JS. It has some advatages over other web-driving tools like Selenium:

Fast DOM interaction
Native keyboard and mouse emulation
Not restricted to the same frameset, like you are in JS.

Google Sitebricks (pre-release coming soon) is a RESTful web framework. It has templating that is tightly coupled with POJOs. MyPage.Java backs MyPage.html. Java-like annotations actually appear in the HTML to control the output, like JSTL tags. Planned support for Ajax Push.

There's a lot of hype about Google Wave, a collaboration tool that's a marriage of e-mail and instant messaging.

JavaOne 2009 - Thursday

2009-06-10T02:25:00.000-07:00

Unit Testing that Sucks Less - Neal Ford

Probably the best presentation I attended at JavaOne 2009.

Hamcrest is syntactic sugar for unit testing... less you express your assertions with less verbiage through the use of static imports, like assertThat(a, b) and is(anyOf(item1, item2)).

Infinitest is a continuous test runner for JUnit tests. Whenever you change a class, it runs the test for you. Wouldn't this get annoying and slow down your IDE? Supports Eclipse and InhelliJ.

Jester is a test tester! It helps ensure that you don't write crummy tests. It's a test permutation framework that screws around with constants, operators, etc. in your assertions to break them. The thought is that if your tests are well written and check for very specific conditions, then changing them slightly will break them. Make sure you run this on a copy of your code, because it will hork around with it! It includes a Phython script that outputs an HTML report about the suckiness of your tests.

Unitils.org - for making mock test data; integrates well will Hibernate / JPA / Spring. Also has nifty assertion utilities like assertReflectionEquals, which uses reflection to check each check each field of your object. Integrates with dbUnit to feed fake data to Hibernate from xml docs.

Spock - A test and specification framework for Java and Groovy. Almost an alternative to JUnit, but it integrates with JUnit through a plugin called Sputnik. Your tests follow the pattern: setup - stimulus - response - cleanup. Leverages Groovy to make your test code more concise. Gives you very pretty test failure messages, showing you the expected value and the actual value. Highly logical.

So, how do you test private methods? Either use crazy reflection helper methods, or just use Groovy! Supposedly, Groovy's ability to access private methods / fields is actually a bug. But, people love it so much that it's been tacitly accepted as a language feature.

JMock - helps you create mock objects for your code. Integrates well with Groovy; you can do things like create a map of method names to call for your test. They do something really clever as a shortcut for simulating closures in Java:

context.checking(new Expectations() {{
// check stuff here...
}})

So, they're using an anonymous inner class (the outer set of braces) with a static initializer block (the inner set of braces) to pass in a block of code to execute.

Neal ended the talk by saying that one of the worst ways to test Java is with Java! Use Groovy and check out Spock!

Writing Killer JSF 2.0 UI Components - Kito Mann

There wasn't much here that wasn't covered in the Java University talk. The speaker was late and not very well prepared; several of his demos didn't work. His talk last year was better.

Navigation rules are simpler than the old JSF; if you return a string from an action ("saveItem"), it will navigate to a page named like that action ("saveItem.xhtml"). You don't need to set up all those verbose navigation rules in faces-config.xml.

There are more opportunities to leverage EL in your backing bean, like when returning new SelectItems to back listboxes.

There are shortcuts to get at components attributes in Facelet UI code: like #{cc.attrs.value.selectedCommandValue}

Custom JSF logic (decoders, listeners, etc.) can be done through scripting. This is a WIP in myFaces. I haven't seen any useful examples of JSF's scripting support.

Resource handling is extensible... it can be versioned and localized. EL can be used inside CSS and JS. This could be useful for reducing some CSS redundancy through EL expressions that refer to repeated values like #{backgroundColor}. I've used Facelets to do this with JSF 1.x.

Many of the familiar JSF tags have been extended to refer to resource libraries, like:

<h:graphicImage name="face.gif" library="images" />

...or I think you can use something like
<h:graphicImage name="#{resource['images:face.gif']}" />

javax.faces.PROJECT_STAGE provides some support for environment specific settings... so you can control logging levels, etc.

Ajax Support - there is a low level JS API that mostly deals with updating the ViewState when making an Ajax call. The new <f:ajax /> tag specifies which action to fire and which components to update as a result of the call.

Ryan Lubke's Blog has a lot of detail about the JSF 2.0 spec as it progressed.

Bean Validation: Declare Once, Validate Everywhere - Emmanuel Bernard

This is about JSR 303 - in final draft. Check out his blog entries. The spec writers are supposedly working with JSF 2.0 and JPA 2.0 guys for seamless integration. This reminded me of old talk about annotation-based validation from the Server Side NFJS conference, where the speaker complained, "This stuff isn't ready! Why do they want me to talk about it?" Unlike the old talk, though... looks like JSR 303 is just about final and has a lot of backing.

Where do constraints need to be applied? At presentation layer (through JS), at business layer, and data layer.

Annotations like these are proposed:
@Size(max=30, message="longer than {max}")

You can also get validation messages out of a resource bundle, useful for i18n.

The @Valid annotation lets you cascade validation to other objects in the graph. For instance, for an Order class to be valid, its field of type Address must also be valid.

You can group validations together into a sequence, specifying multiple interfaces (Default and Heavy in the example below) that are processed in the order specified:

@GroupSequence(sequence={Default.class, Heavy.class})

You can create your own validators:

@Constraint(validateBy={ZipCodeValidator.class})

TraversableResolver is used to ignore lazy properties and associations during validation, useful in JPA so you don't trigger the data load on lazy properties. So, does it hook into JPA somehow to validate the data once it's loaded?

Constraint violations are returned as a Set of ConstraintViolation objects: Set errors = validator.validate(user);

Hibernate Validator 4.0 (in beta) is based on a Reference Implemetation of JSR 303. There is also a RI that comes with GlassFish 3, in a sample app.

Keeping a Relational Perspective for Optimizing JPA - Debu Panda, Reza Rahman

Denormalization can improve performance! Yes, it's true in some cases, especially when the data is mostly read-only, because you reduce the number of joins. But, this of course can lead to maintenance problems.

In JPA, consider using @Embedded instead of @OneToOne to reduce joins.

What to index:

frequently used foreign keys in large tables
heavily used keys in joins
heavily used columns in query params and order by clauses.

The single-table inheritence scheme is the fastest; try to use it when possible.

Using the native SQL "on delete cascade" in DDL is faster than JPA's CascadeType.REMOVE.

Eagerly load data that is used often, including relationships. Usually, you want to lazy-load BLOBs, using @Basic(fetch=FetchType.LAZY). A "fetch join" in your query can override the lazy JPA annotations where needed.

Using "update set ... where ..." is faster than looping through a collection and performing an update on each individual object.

Keep in mind native SQL hints like /*+ FULL(...) */ in Oracle when you know something about the data that Oracle isn't using in its query processor. Sometimes, an index will actually slow the query down; a full table scan will be faster because it avoids the index. For instance, if you want to query for the active users, and you know that most users in your USERS table are active='Y', the index may just be extra overhead (versus scanning the table directly). Strange, but true. I've used SQL hints when Oracle was acting stupid. I think a bitmap index may be useful in this case.

Keep JBDC in mind. Use @NamedQuery to reduce parsing overhead. Eliminate txn overhead for read-only queries with @TxnAttribute(NOT_SUPPORTED).

Second level caching can really speed things up. This was added in JPA 2.0. For now, use Hibernate's annotations to declare caching. Consider using Coherence for replicated cache. This used to be Tangosol Coherence, now it's Oracle Coherence. How does this compare with Terracotta? Does it operate closer to the database tier?

Tuning tools - enable hibernate.show_sql, format_sql, and use_sql_comments. And of course, use EXPLAIN PLAN. There is also SQL Navigator Xpert Edition, which includes a SQL tuning wizard that runs many permutations of your SQL to find the fastest version and also gives you advice about your indexes.

BOF: Grails Integration Strategies - Dave Klein

How do you sneak Groovy into a stodgy, Java-centric Enterprise environment? Start with little things like unit testing, utility scripts, small internal web apps, prototypes, using GSQL as a replacement for JDBC, and XML processing.

Dave talked about a large JSF project that was way behind. Grails came to the rescue, and they finished ahead of schedule. Plus, Grails gave grumpy programmers (who were ready to quit the project) a big morale boost. Since they had some extra time, they went through and converted all the old JSF code to Grails. He said, "JSF 1.x was like a cancer that had to be removed." He joked about JSF 2.0 looking somewhat usable.

For integration with legacy dbs, use:

static mapping = { table '...' columns { ... } id generator ... }

GRAG generates Groovy classes from an existing db.

How do you call Grails from non-Grails code?

Use REST and the URL Mapping DSL
...or, use SOAP calls. There are Grails plugins for XFire (CXF), Spring WS, etc.
...or just make a plain HTTP call, and return data in HTML, XML, or JSON, making use of Grails' converters.

When adding Grails to a JSF app, Ajax4JSF helps integration at the UI level. Keep in mind that most other non-UI things in your app like Spring beans and Hibernate entities can be used by both Grails and JSF.

Burt Beckwith's Blog has interesting Grails stuff.

BOF: Groovy & Grails - the Groovy Podcast Guys

Some Groovy Podcast Guys were addressing a panel of Groovy experts: Dierk Koenig, Scott Davis, Andres Almiray, Danno Ferrin and James Williams.

In Groovy 1.7, you'll have more powerful assertions to use in your testing; they will show you where the expected and actual values didn't match. Sounds like Spock!

There was a lot of talk about Griffon: based on Grails 1.1, it lets you build a UI with a declarative layout for Swing. How about a declarative layout engine for friggin' web apps?! You can kind of do that with Ext JS.

"Hey, Groovy panel, when are we going to see a decent Eclipse plugin?!" Ummm... sometime this year. The audience was full of InhelliJ users.

Running Grails in the cloud? Consider a hybrid approach to begin with, maybe just start with your data, using S3.

JavaOne 2009 - Wednesday

2009-06-08T01:54:00.001-07:00

Full-Text Search: Human Heaven and Database Savior in the Cloud - Emmanuel Bernard & Aaron Walker

Users think in terms of words, and the SQL like operator doesn't respect word boundaries. Databases can't handle synonyms, proximity, relevance (result scoring). RDBMSs have some support for text search, but as proprietary SQL extensions that vary bewteen DB vendors. There are also issues with flexibility and scalability.

Hibernate Search extends the familiar Hibernate/JPA Query APIs and provides full-text search in your app with minimal intrusion. Full-text indexing is done through Lucene, using a thread pool. Lucene is very fast and scales well. Search can be run against multiple shards and the results are merged together. (Kind of like searching across multiple collections in UltraSeek.)

It "feels like Hibernate, searches like Lucene." You just need to add annotations to your model objects, like @Indexed, @DocumentId, and @Field(name="...", index=Index.TOKENIZED, store=Store.YES).

A custom Hibernate EntityManager extends the familiar Hibernate session and query objects and supports the usual features like pagination.

Search.getFullTextEntityManager(...);
session.createFullTextQuery();

With careful use of the full-text query API, you can avoid database hits through projection. If you only specify fields from the full-text index in the query's projection, it will retrieve it directly from the full-text index, avoiding the database. This uses StaticAliasToBeanResultTransformer.

Of course, this stuff runs on the cloud. They used Amazon EC2, EBS (Elastic Block Storage), S3 and CloudFront. EBS is like a storage device that you can mount as part of the file system... snapshots of this are backed up to S3 storage. CloudFront is a content delivery network for static content, like images and video. They have edge servers around the globe, like Akamai.

The app server was JBoss running on CentOS. JOPR is a JBoss monitoring tools that can also be used to monitor the OS, app servers, and databases. For load balancing, httpd with mod_cluster and DNS round-robin.

Ajax Performance Tuning and Best Practices - Greg Murray (Netflix), Doris Chen (Sun)

This presentation was all about general web performance tuning, very little had to do specifically with Ajax. Some of the speakers here like to "beef up" their titles with buzzwords to draw in a crowd. (It's Ajaxy! It's cloudy!) But, they just end up disappointing the audience. There was some good advice here, but I've heard a lot of it before.

Place CSS and JS in separate files. Some inline JS and CSS are ok in the initial page, but after that has loaded, start loading in the external JS files that are used by the following pages.

After you're done with objects in JS, de-reference them (using delete) and detach listeners (element.removeEventListener, element.detachEvent in IE). Use removeChild to remove unused DOM elements. Make use of window.onunload() as a clean-up function. Hmmm... I always expected the browser to clean up after me after the page loads. Does this really improve performance? Is this part of the reason why browsers eat up tons of memory when you keep them open for hours?

Think async. Avoid making function calls that block the browser's JS execution. Instead, use setTimeout() with a callback.

When working with objects, try to reduce dot operator use. So, do something like this...

var ds = divs[i].style
ds.color = ...
ds.padding = ...

...instead of repeating divs[i].style. This makes your code more consise, too.

Instead of using string concatenation, use an array, then use array.join() to merge the array elements into a string. Kind of like using Java's StringBuilder. Most browsers are optimized for parsing the innerHtml property, so make use of it.

Use YSlow to time your site... use CSS Sprites... combine CSS, scripts, etc. for fewer requests. (*Yawn*)

Try to put CSS within the in HEAD element of your page if possible... this may help avoid the visual flash of unstyled content as your page loads. Especially in smart browsers like FireFox that are better at incrementally rendering your page than IE.

Move JS to the bottom of the page, because the browser must render it serially, and it blocks the browser's execution.

Use tools like JSMin and Dean Edwards' Packer to compress JS. Even if you are using GZip compression (supported by all modern browsers), JSMin can help a bit in production environments by stripping out comments. Run JSLint on your code to check for errors before you minify.

Make use of obvious things like the expires header and ETags if they are honored by the web server and browser.

What's new in Groovy 1.6? - Guillaume LaForge

New in 1.6... groovyc compiler is about 3x to 5x faster, thanks to a clever class lookup cache. Overall, there is a runtime performance increase of about 150% - 460%.

New language features include mutiple assignments, like def (a, b) = [1, 2]. Very Perly. This is useful for utility functions like swap: (a, b) = [b, a]. The "return clauses" don't have to be explicitly declared in Groovy, they default to the last statement of the method. Again, Perly. But, Groovy is now smarter about picking up the implicit return clause in conditional statements. Same applies to try / catch / finally blocks.

Groovy 1.6 now has complete support of Java 5 annotations. Annotations aren't leveraged quite as much in Groovy as they are in Java code (mostly because Groovy is more runtime-oriented), but this is useful.

New AST (Abstract Syntax Tree) transformations. AST is "tree representation of your source code"... I guess you can use this to tap into Groovy's language parser. "Local" AST transformations are triggered by annotations:

@Singleton(lazy=true) -- generates boilerplate singleton code like getInstance().
@Immutable -- fields can't change.
@Lazy -- makes an instance only when you first access it.
@Delegate -- designate a class's method to be called on behalf of another class's method. Looks very useful.

This is very framework-like. I'm keeping the Spring 3.0 talk in mind as Guillaume goes over this. Seems like Spring Java Configuration will merge with these Groovy features before long.

Grape is an "advanced packaging engine" for Groovy. Aw, I had plans for "GrAPE"... maybe a certain portal-like framework integrated with Groovy? This is a way of specifying module dependencies through Maven / Ivy. Kind of an alternative to the ugly Maven pom.xml.

GroovyConsole can be customized to display your classes visually, like displaying maps with Swing table components. Why hasn't Swing died?! Will Java FX help kill boring, stodgy, old Swing components? What about SWT (which Eclipse uses)? At least SWT leverages more of the OS's native UI controls.

New Expando MetaClass features: the syntax is a bit easier for overriding operators, so you can do something like...

Number.metaClass {
mutiply { .... }
divide { ... }
}

...kind of like .NET with its getter and setter syntax.

"Runtime Mix-ins" let you inject behavior into types at runtime. So, if you have a boring JamesBondCar class, you can mix-in the FlyingAbility class to give it the fly() method. This reminds me of multiple inheritence from C++, except it happens at runtime.

If you wish to invoke Groovy from plain Java code, you can use java.script.ScriptEngineManager.getEngineByName("groovy").evaluate( "groovy code here"). This is from JSR 223; supported in JDK 6. Like using JS's eval() method.

JMX Builder is a handy way to expose Java / Groovy as MBeans. You can easily create event handlers and broadcasters to be exposed through JMX. May be useful for our Tomcat admins for monitoring application-specific objects through JMX.

OSGi Readiness - Groovy JAR contains OSGi metadata. I haven't heard as much hype about OSGi in this conference versus last year's. This might be because JDK 7 is going to support this type of modularity. In the last conference, they said that JDK 7 would support both OSGi and some new JDK 7 standard. But, not suprisingly, the "official Java standard" has been emphasized lately.

Scott Kessler asked about Groovy 1.7. You can expect more complete support of Java language features, like anonymous inner classes. This is largely handled by closures, but there are come cases where you need Groovy to mimic the genuine anonymous inner classes. Also, expect some concurrency helpers.

HtmlUnit - Daniel Gredler, Ahmed Ashour

Using a tool like HtmlUnit for integration testing is not about trying to prove correctness.... it's about trying to catch errors before more exhaustive tests.

You can use a browser-driving solution.
Pros:

Leverages browser configuration, including plugins.
Easy to create test w/ recorders.

Cons:

Browsers will grab all images, resources, etc. that may not be necessary for testing.
Because of platform dependencies, hard to test multiple browsers on the same machine, like IE 6 and IE 7.
Limited extensibility.
Performance and scalability issues.
Tests tend to be limited and fragile.

HtmlUnit is a browser simulator written in Java. It's a JS parser / executor + a CSS parser + HTML parser. It's been an active project since 2002. It's not just useful for integration testing; other uses include advanced web scraping and monitoring. Browser simulation focuses on FireFox 2 & 3 and IE 6 & 7, with support for other browsers in the works like IE 8 and maybe Chrome and Safari. You can simulate JS and CSS being disabled in the browser and control popup blockers. SSL is supported, but only with test certificates, so it should suffice for internal sites. Ajax is supported, but you may need to work around some threading issues. No built-in support for Flash, but there is support for ActiveX controls through Jacob (the Java-COM bridge). Very basic Java applet support.

There are extention points to simulate user interaction with JS dialogs like alert() and confirm(). There are also JS preprocessors if you are scraping someone else's site and need to mess around with their JS. There are "incorrectness listeners" for HTML, CSS, etc.

Sample test code:

@Test
public void homePage_Firefox() throws Exception {
final WebClient webClient = new WebClient(BrowserVersion.FIREFOX_2);
final HtmlPage page = webClient.getPage("http://htmlunit.sourceforge.net");
assertEquals("HtmlUnit - Welcome to HtmlUnit", page.getTitleText());
}

Mozilla Rhino is used as the JS engine, NekoHtml for the HTML parser, and Apache HTTP Client 3.1 for HTTP requests and cookie support. By default, HTMLUnit will not render images.

There's also a Perl interface to HTMLUnit.

Web 2.0 Security Puzzlers - Ray Lai

Static security analysis tools can give you a lot of false positives.

Watch out for cross-frame attacks. For instance, the parent frame uses JavaScript to get content from the child. Yes, most new browsers won't allow frames from different domains to talk to each other... but especially for external sites, remember that users are running some very old browsers. To prevent this, just check for self != top in JS and use window.open(url, "_top") to break out.

XSS (Cross-Site Scripting): Say a user tricks you into clicking this link:

http://mysite.com/pay.jsp?id=1;<script>alert("hack!")</script>

Is this an issue? Well, it depends on how the server parses the URL and outputs the id in the HTML. The above <script> in the URL could actually do something really naughty like examine your cookies, DOM elements, etc. and POST its findings somewhere.

XSS is easy to defeat using a servlet filter looking for a certain URL pattern with suspicious chars. Yeah, like we need another servlet filter running in our app! Actually, SiteMinder already looks for suspicious chars and kills your request with a "naughty characters" message if it finds them. IE8 has built-in XSS prevention enabled by default.

CSRF - Cross-Site Request Forgery. This forces users to execute unwanted actions on a web site where they are already authenticated. You can use img tags or IFrames to point to a site where the user is already logged in. So, if someone has a browser window open already to their banking site, another site can point an img src to a URL on the banking site that triggers a money transfer or whatever. Cantankerous! This is kind of hard to prevent.

SQL Injection Attacks. *Yawn.* Yeah, use parameterized queries.

Hard-coded passwords in server configuration files. You can't always rely on admins to restrict the file permissions to hide the passwords. At least obfuscate your password. I'm trying to get Oracle's client-side wallets / SSO working so that we don't have to deal with passwords at all in our server config files for sensitive apps, but Oracle's documentation is lacking.

System Info Leakage. Use an error page in web.xml, but certain requests may still generate error messages with revealing stack traces. Use log4j to write errors to a log, and don't output sensitive data to the logs.

Review the OWASP Top 10 Web Security Vulnerabilities.

The Ghost in the Virtual Machine: a Reference to References - Bob Lee (Google)

A lot of things require manual clean-up; you don't want them lingering around in memory, like...

Listeners
File descriptors
Native memory
External State, like using an IdentityHashMap to add fields to objects you don't control. Huh?!

Finalizers stink. If you must use them, be sure to also call super.finalize(). Finalizers are not guaranteed to run, and they aren't timely. You can even resurrect references (unintentionally) in finalizers... so your objects don't get cleaned up. Those who have studied for Java 5 certification may recall that bit of ugliness. Finalizers usually run on the same thread, so be sure to synchronize your finalizers where needed. Since there's just one thread calling finalizers, slow finalizers will defer clean up of other objects.

Since Java 1.2, we've had the Reference API for more flexible reference handling. Reference types:

Soft - useful for caching; these are cleared when the JVM runs low on memory.
Weak - for fast clean-up (pre-finalizer). These are cleared when there are no longer any other references to it.
Phantom - for safe clean-up (post-finalizer). These must be cleared manually, because of some stupid patent. You must use a "reference queue" to get at objects through phantom references.

Keep in mind that these references themselves are objects, and you must have strong references to the reference objects.

Google developed some nifty collections to assist with references, like FinalizableReferenceQueue and FinalizablePhantomReference, where you have your own thread to do the clean-up, instead of relying on the finalizer thread.

WeakHashMap keeps weak references to keys and strong references to values, but like the standard HashMap, this uses equals() instead of ==, so it's a bit inefficient in most cases. Google Collections has a MapMaker, which is a smarter WeakHashMap that uses ==.

Google Collections is currently at 1.0RC2.

There's an old, interesting IBM DeveloperWorks article on using weak references to reduce memory usage.

BOF: Performance Comparisons of Dynamic Languages on the JVM - Michael Galpin (eBay)

Comparing Groovy, JRuby, Jython, Clojure, Scala, and Fan. These "benchmarks" were all about solving silly math puzzles. Not very realistic. He didn't even bother to monitor memory usage.

Overall, Groovy and JRuby performed about the same. Scala and Fan were the fastest, but about twice as slow as Java. Jython was very slow. Someone in the audience said that there has been a lot of activity on Jython, but the team has been busy catching up with new language features and will address performance next. Scala and Fan seem to be fast for string parsing / manipulation.

There are things you can do in Scala that you can't easily do in Groovy. I guess Scala is good for heavily multithreaded apps with complex concurrency problems. Scala looks kind of like Ruby. Clojure focusses on functional programming. It looks like Lisp. Gross!

JavaOne 2009 - Tuesday

2009-06-02T12:03:00.000-07:00

General Session

Java SE 7 JDK available as prerelease... also Java EE 6 SDK w/ Glassfish.

A lot of emphasis on desktops, mobile devices, and JavaFX. JavaFX 1.2 is out. There's some new software that lets you wire playback controls to video controls and work with a timeline without writing any code... kind of like a dumbed down version of Flash's IDE.

"Aren't you guys tired of wrestling with Ajax? Look how cool JavaFX is!"

James Gosling showed off the new store.java.com; developer site at store.java.com/warehouse. This will supposedly help developers get their apps out there on desktops, like RuneScape.

Of course, the session ends with Larry Ellison and Scott McNealy shaking hands and ensuring everyone of a happy future. Larry essentially said that Oracle invested so much money into Java that they might as well buy Sun.

Ajaxifying Legacy Apps - Anas Mughal (Bluenog)

Important to clean up sloppy HTML and CSS before trying to add Ajax to it... it may actually take longer to clean up the sloppy old markup code than implement the new Ajax code. But, without clean HTML, the browser's DOM parser will likely choke on it.

Once you've cleaned up your UI, keep your existing MVC code and incrementally add new controllers that return ModelAndView objects with JSON. Alternative REST implementations include Restlets, DWR, and Jersey (the JAX-RS / JSR 311 reference implementation).

Use jslint to verify your JS and jsonlint to validate your JSON. Spket is supposedly a nice JS editing plugin for Eclipse. I've been looking for a nice, lightweight JS editing plugin. Maybe I'll try it out and see it it's lighter than the Aptana tools.

He's using JSLoader to manage JS includes through the browser. It handles stuff like versioning and debug versus production versions of JS libraries. Somehow, it also handles patching of JS libraries. Might be useful... but that seems like something we can handle on the server-side. And patching JS libraries on the client?! I don't know about that.

He really likes Ext JS... he essentially says that there is no other JS layout manager that even comes close to it. Yes, it's powerful, but the complex API takes some getting used to. Plus, many developers got angry when its author decided to switch its licensing to GPL. There's been some activity in JQuery UI and other client-side component libraries to support basic layout, resizable modal dialogs, etc. But, no... I haven't seen anything quite like Ext JS.

He pointed out a very cool feature of Ext JS: Ext.History.on(), which uses tokens to track Ajax actions and integrates them with the browser's history, so that the user can use the back button to travel back in time through his sequence of Ajax actions.

Also, Ext JS supports GWT components (GXT). This looks nice.

The rest of his presentation was about... portals?! The cool JS / Ajax stuff came to a screeching halt when starting talking about JSR 168 / JSR 286. So, Bluenog has their own portal which sounds like an offshoot of Liferay Portal, and it will soon support JSR 286. How do you handle inter-portlet communication? Use Tibco PageBus or your own Ajax solution. Ah, I see PageBus implements OpenAjax Hub... so maybe this is worth looking into for resolving some Ajax security concerns (apart from JSR 168 / JSR 286, of course).

I asked him why bother with the old portlet standards if all you're doing is getting JSON or simple markup that ends up being rendered in a <div> within Ext JS? Why not just return it from a servlet? He said that if you're doing portlet-like stuff, you should try to make use of the standards that are there... and if using Ajax in your portlets, look for a portlet container that supports JSR 286. Ok, I admire this guy for his client-side knowledge, so I'm going to stop here. If you're unfamiliar with these portlet standards, please refer to my JavaOne 2008 notes.

Architechting Robust Solutions for Amazon EC2 - Chris Richardson

This was a good talk, but it lacked the technical depth of his talk from last year. Seems like he's trying to appeal to a wider audience and get some business. Sometimes it's good to have your head in the clouds. (But horrible puns are never a good idea.)

Both 32-bit and 64-bit Fedora Core 4/6/8 supported. Windows 2003 server and SQL Server supported, but more expensive, of course.

Some new cloud tools have emerged over the past year: SQS to handle messaging between loosely coupled components, and CloudFront to distribute content. SQS is handy for YouTube type sites that do a lot of media transcoding... more instances can be added as needed to process the queue.

Management tools include the familiar ElasticFox with S3 Organizer, plus the web-based AWS Management Console. A new Eclipse plug-in leverages WTP to let the developer deploy directly to the cloud, as if he were deploying to a local app server.

Of course, there are Chris's own Cloud Tools written in Groovy that have matured since last year.

Cloud Foundry is another cloud management / monitoring / autoscaling solution.

For two small EC2 nodes handling a clustered Apache / Tomcat / MySql environment, it's about $216 a month... pretty cheap.

Apps running in the cloud are HIPAA compliant but not PCI compliant, so you'll have trouble processing credit card transactions.

A new Amazon-managed dynamic load balancer service was release about 2 weeks ago; costs $0.025 / hr + $0.008 / GB transfer. Does not yet support sticky sessions for load balancers.

Amazon doesn't support multicast, which may cause trouble for some app servers like Tomcat when doing clustering. Could try using Terracotta.

Amazon does offer some built-in security features in the cloud. You cannot sniff traffic from other instances within the cloud, and diskspace is wiped clean when instances are decommissioned. But, it's still a good idea to encrypt your data just in case.

Overall availablility of cloud instances should be around 99.95%.

Tips and Tricks for Ajax Push and Comet Apps - Jeanfrancois Arcand & Ted Goddard

Don't go crazy with Ajax Push at first. Think through your app's normal synchronous behavior first, then overlay a few features that could benefit from Push like chat, users joining presentations, and other realtime events.

Servlet 3.0 spec (final draft in review) has support for ARP (Async Request Processing): request.startAsync().

ARP support is included in most new app servers like Tomcat 6 and Glassfish, but not standardized. Best choice for portability is Atmosphere. Write your Ajax Push code with the Atmosphere API, and it will transparently make use of your container-specific's ARP implementation. It will also transparently leverage Servlet 3.0's ARP when containers start implementing it. If your app server doesn't support any form of ARP, Atmosphere will use its own implementation.

Method annotations like @Suspend identify your servlet's ARP behavior to Atmosphere.

The 3 Ajax Push methods: polling vs. long polling vs. HTTP streaming. In general, long polling gives the end user a very quick response and is probably the safest because proxy servers can mess up HTTP streaming. (Proxy servers may wait for the end of the response before handing it off to the end user.)

With so many concurrent connections from thousands of users, using a thread to handle each connection is out of the question. Java NIO enables the server to "detach" the connection from the thread, delaying the "commit" of the response until there is data to send. Glassfish (Grizzly), Jetty, and Tomcat support this using NIO / AIO (the new Async IO that will come in JDK 7).

One of the biggest barriers to Ajax Push is dumb browser limitations. A browser can only make so many concurrent connections to the same server. (This has to do with the HTTP 1.1 spec.) You need to make sure 1 of them is reserved for Ajax Push, or else threads may get blocked.

FireFox 3: 6 connections per browser
IE 6/7: 2 connections per browser
IE 8: 6 connections per browser
Safari: 2 connections per window

1 connection is all you really need on the server for pushing messages to a client.

IE, Chrome, and WebKit are flaky with Ajax Push. Send some junk when starting the request, and they'll be happier. Sometimes in long polling, the server's message may get lost with flaky browsers. So, include a "message id" in the message from the server to the client. The client will then send back the last message id it got from the server, and the server will use that to determine the next message to send.

In ICEFaces, the same JSF component tree is re-used for multiple clients, so the same update message can be sent to multiple clients. Weird. ICEFaces also does something creative to work around IE's 2 connection limit. It reserves 1 window for the Push connection, and windows communicate with each other through a cookie. The cookie determines who controls the Push window.

Tomcat 6 comes with a demo that uses just 1 thread to push back results to all clients. This doesn't scale well; you should use a thread pool to do this. Even with a pool, be wary of slow networks that cause your threads to block. Make sure you let your connections timeout to release threads. Also a good idea to aggregate events on the server and push out a multipart message instead of many little messages.

If the app is running on multiple nodes (hopefully with sticky sessions), need to broadcast the push events to all nodes through something like JMS.

Spring Framework 3.0: New and Notable - Rod Johnson

Rod started out with a review of the new features of Spring 2.5, focusing on annotation-based DI. Annotations such as @PostConstruct and @PreDestroy are the now the preferred way to make your beans lifecycle aware (rather than implementing interfaces). Use XML only when you need to externalize something, like DataSources. Spring scans your classes for Spring-related annotations, so use <context:component-scan base-package="..." /> to limit its scanning to your packages and make your app start up faster.

I'm still using XML for bean wiring. I wasn't so sure I liked the idea of mixing the wiring in with the code, but now I see some advantages of this. Type safety is a big one.

Spring Servlet MVC 2.5 has handy annotations like @RequestMapping and @RequestParam for your controllers. Rod reiterated a good rule-of-thumb I heard from Grails training: complex things shouldn't be done in controllers; consider making them a service.

On to Spring 3.0... only Java 5+ is supported, so everything has been genericized. Extended annotation support and EL are big enhancements. We finally have this...

T getBean(String name, Class <T> theType)
Map<T> getBeansOfType(Class<T> theType)

...they have genericized the bean getting methods! This means that you no longer have to do ugly typecasting after getting your bean from the context.

There is a custom expression parser shipped with Spring 3.0, which is compatible with Unified EL but more powerful. EL can be used to navigate bean property paths (like util:property-path for XML configuration), and it can also be used to invoke methods. For instance:

<property name="size" value="#{otherBean.size}" />

This new EL implementation will be the default for Spring Web Flow. EL may be combined with annotations and are resolved at runtime, for instance:

@Value("#{systemProperties.color}")
private String color;

REST-style mappings extract pieces of the URL and map them to method args:
@RequestMapping(value="/show/{id}", method=GET)
Object show(@PathVariable id)

You can also use annotations to pull attributes out of the request with @RequestHeader and @CookieValue... and you can make your own annotations for custom request processing, where Spring will give you the servlet request, context, etc. Could be useful for SiteMinder header processing.

There is Spring Faces for JSF view layer support. (No mention of JSF 2.0 support. Looks like they are working on it. Maybe full support in Spring 3.1.) Also, Spring Blaze DS support for Flex.

Spring Java Configuration: instead of using ugly XML to wire your beans and instead of mixing bean-wiring annotations directly with your application code, you use a separate class that declares the wiring through annotations. In other words, your application code remains untouched. The configuration you would do through XML is now code through annotations in a class that mimics your <beans> elements. Your configuration class is annotated with @Configuration, which has several @Bean methods that describe how to intialize / inject the beans. (Usually, these methods return instances of the objects they depend on.) These bean references are smart about scopes. Does this mean we'll no longer have to use that aop:scoped-proxy when going from a session-scoped bean to a request-scoped bean?

So, Spring Java Configuration is a DSL for configuration, like the Grails Spring Bean Builder. As Rod puts it, it is "Java object creation on steriods" with several advantages over XML:

Type-safe
Allows inheritance of configurations.
Allows easy custom creation of objects using your own methods.
Robust bean-to-bean dependencies, without using strings to refer to class names.

I like this. But, the Grails Spring Bean Builder looks more concise.

Spring Roo: a round-tripping code generator that gives you command line tools like Grails for creating projects, adding entity classes, controllers, etc. There is a free Spring Source Tool Suite set of plugins for Eclipse that includes Roo support, so you won't have to go through the command line to run Roo tasks. So, why use Roo instead of Grails?!

Then, the next slide comes up: When to use Roo versus Grails. Thanks, Rod. This slide wasn't in the version of the slides posted to the JavaOne site. It may have been added at the last minute after realizing the clash between the technologies. Basically, you'd want to use Roo if you are a Java programmer and are unwilling to work with a dynamic language like Groovy. Otherwise, use Grails.

Securing Web and SOA with Axis, WSS4J, Spring, and OpenLDAP.

One of the speakers mentioned Rampart / WSS4J, a WS-Security implementation for Axis that handles creating user tokens for authentication.

This was the worst presentation I've seen at JavaOne (including 2008). It may have well been written 5 years ago. Lots of useless details about old technologies. The speakers tried to keep the audience awake by tossing shirts at us. I was one of many who walked out of this one.

JavaOne 2009 - Monday

2009-06-01T23:20:00.000-07:00

Two 3 1/2 hour sessions today! Thank goodness they served coffee during break time.

Rapid Web Application Development with Grails - Graeme Rocher

Much of this was review for me, but I wanted to hear it from Mr. Grails himself... and get his perspective on a few things.

Interesting how several language proposals in Java 7/8 come from Groovy, including multiline strings and the Elvis operator.

Groovy is very useful for build systems. Sometimes, declarative XML doesn't cut it. Groovy is not only easier to read than XML; it lets you combine the static data with closures to make the process more dynamic. Probably easier than writing a Maven plugin!

I think he said something about instances of class definitions now being thread-specific in Groovy 1.6... I'm sure I'll hear more about this in Wednesday's session.

Someone asked about profiling Groovy code. Well, just use the standard Java tools like JProfiler and YourKit and configure it to exclude the built-in groovy classes.

When not to use Groovy? When little memory is available or high performance is critical. Groovy performs better than most other scripting languages on the JVM because it doesn't create a unique runtime per thread.

Considering all that Grails does for you in gluing together all these technologies by convention, Graeme considers the CRUD generation (scaffolding) to actually be a relatively small value-add.

JPA plugin for Grails should be final within the next few months... mostly because they need it for the Google App Engine. They are kind of waiting for JPA 2.0 to be finalized, but they aren't holding their breath for it. Meanwhile, although Grails uses Hibernate, your domain objects are not tied to it.

Grails leverages a lot from Spring MVC, including its l10n support and data binding / property editors.

Controller logic should be simple. If the logic becomes too complex, consider making it a service.

There's a lot of activity on the GWT and Flex plugins for Grails. The Grails UI project has snazzy components like a datepicker, tabs, panels, accordions... built on YUI.

Tags can be called from controllers, which is useful, because there is often cross-cutting functionality between the controller and the view. Tags are like a bridge between Markup should be separated from the tag library implementation.

New in Grails 1.1: templates may be invoked through a tag, like this:

<template:issueList issue="${myList}" />

...where "issueList" is the name of the template (acutally "_issueList.gsp"), and the model is passed through custom attributes like "issue".

There are over 120 Grails plug-ins available. Grails Success stories include sky.com (over 150 million visitors a month) and wired.com.

After the session, I asked Graeme what he thought of using JSF as the view layer for Grails. Our developers are already familiar with JSF / Facelets, so is it worth it to try to integrate the two? He didn't sound too interested. His focus right now is on enhancing the core parts of Grails, like JPA support... not so much the view layer. He's letting the community drive much of the UI components, and much of the activity has been on GWT and Flex. There are fledgling JSF support projects out there. He mentioned Gracelets, which is Groovy support for JSF 1.2 and Facelets. (Supposedly, Gracelets will support JSF 2.0.) I'll take a look at it. It may at least be a stepping stone for JSF developers to get used to Groovy (and leverage it for certain things like XML and string parsing) without being overwhelmed with a new view layer and the Grails way of doing things.

Developing Java Apps with JPA 2.0 - Linda DeMichiel

This speaker blasted through 186 slides! Whatever you thought of this presentation... you can't say that she wasn't thorough! In short, JPA 2.0 fills in many of the holes from JPA 1.0 with stuff that is either borrowed from Hibernate's API or heavily influenced by it. I'll add the details here later.

JPA 2.0 features

Richer domain modeling
More flexible O/R mapping, including collections of primitives and the ability to use maps instead of tertiary entities to express relationships between two entities.
Additions to JPQL.
Metamodel API, so you can get details on object relationship mappings at runtime.
Criteria API! Vaguely like Hibernate, but different and kind of weird... makes use of the new metamodel API. They're still working out the details of how the data gets returned from the Criteria and how to handle the type checking, etc.
Pessimistic locking.
Support for JSR 303 validation

JavaOne 2009 - Sunday

2009-05-31T19:24:00.000-07:00

This is the beginning of the two-day Java University. One long class today, two long classes tomorrow.

JSF 2.0 - More than Skin Deep (Ed Burns & Imre Oßwald)

Overall, I'm impressed. It's not the old "JSF developed in an ivory tower," and it's not just taking years of JSF hacks and extensions from the Open Source community and rolling them into a standard. They really put some thought into this. Bits and pieces of it look suspiciously like Grails... and maybe Seam. What's new...

Facelets as the default view handler
Much easier custom component creation (I'll be attending a session on this later)
Mapping actions to bookmarkable URLs
Resource management
Ajax support
CoC (Convention over Configuration); more annotations and less XML
Easier navigation rules
Support for Spring... and other IoC frameworks.
New scopes like flash and view.
Better i18n support.
More extention points, like for ELResolver

Facelets is now the default view handler; JSP has been deprecated. Old JSP taglibs will need to be converted. This isn't the exact same implementation of Facelets from Jacob Hookum; it's been refactored into different packages (javax.faces.webapp.pdl.facelets), but it's essentially the same. (Maybe we'll finally get better Facelets documentation, and I'll understand what all those mysterious Meta* classes do.)

Custom component creation in JSF 1.x was hell. Even with Facelets, it involved way too much code. In JSF 2.x, you put markup in the components directory, and it becomes an instance of UIComponent. There was something about declaring an "interface" and an "implementation" for custom tags. This looks like a way of formalizing the ui:params that get passed into a facelet.

Ed gave an example of a custom top level component written in Groovy that extended UINamingContainer. He didn't know much about Groovy, and the example component looked at some properties of the component tree or something... it really didn't do much.

Components from different vendors will supposedly now play together nicely, because of the broader JSF 2.0 spec standardizing resource handling, Ajax calls, etc. We'll see about that. For instance, the ICEFaces team got really carried away utilizing just about every extension point of JSF to the point of practically re-writing it. Good luck getting your custom components working with theirs. Vendors will always find holes in the spec and feel the need to do things their own way, but this is at least a step in the right direction.

Bookmarkable URLs are built-in with tags like h:link and h:button (they result in a GET instead of a POST), much like RestFaces. I wonder if there's a way to get the querystring params on the URL to stay there after POSTing. The old JSF with RestFaces didn't let you do that... I had to write a little custom ViewHandler for that.

Resource handling was one of JSF 1.x's biggest shortfalls; the JSF 2.0 guys added some really nice resource handling functions. Resource loading is now built into the lifecycle. If the FacesServlet detects that it is serving up a resource instead of a JSF page, it will forego the complex lifecycle in favor of a simple resource-serving one. Components get their resources out of a "resources" directory by convention: markup, JS, CSS, images, etc. Components and their resources can be bundled in JARs, so you can easily reuse them in multiple apps without having to write custom resource servers (or use something like Weblets). What's really nice about this is that you can have resources in the web app's WAR override resources in the component's JAR! This is exactly what I wanted to do in APE! Bundle a default, complete portlet implementation in a JAR, then have the web app choose which resources to override. I was about ready to rewrite parts of Facelets to support this!

If you think resource handling in JSF 1.x wasn't a big deal, just take a look at what the poor Tomahawk developers had to go through to implement components like the popup calendar: servlet filters that try to inject JS includes in the of your html and custom resource-serving servlets! Yuck!

BTW, you have more opportunities to use EL expressions outside the markup, including annotations and maybe properties files. This has something to do with JSR-276 "runtime metadata." This looks Seamish.

There wasn't a lot of detail about Ajax support, so I'll have to dig into this later. I'd like to learn more about how this affects the component tree. You can do it declaratively with the f:ajax tag, which tells it what part of the page to re-render, like:

<f:ajax render="@form">

...or you can do it programmatically with JS, like this:

onclick="jsf.ajax.request(this, event, {execute: 'myForm', render: 'myForm'}); return false;"

The above JS looks Grailsish. Nice to see this kind of a bridge between JS and JSF built-in. Without this feature (and just using the standard JSF components), you often have to resort to JS code that manipulates hidden form fields, clicks on commandButtons, etc. to have it interact with JSF.

Rather than JSF managing its own beans through its awful XML, it now has extension points to resolve beans through your favorite IoC container. I've been doing this with Spring 2.0 for a while now... but this should make bean resolution more universal throughout JSF. Hopefully, it will be able to resolve custom validators, converters, etc. through your IoC and not just backing beans.

He didn't talk much about the new scopes. Flash is just like Grails's flash scope... it lives until the next request. There is also support for custom scopes... I assume these work like conversation scopes. Ah, yes... here's a bit about it.

So, what's missing from JSF 2.0? There's still no file upload component! Supposedly, this has something to do with the Servlet 3.0 spec including support for file upload... and the JSF team didn't want to duplicate the effort. The old JSF component tree / view state concepts have always bothered me, and I just don't just see them fitting in well with Web 2.0 apps. Again, I'll have to look into what's going on with Ajax and the view state. What else is missing from JSF 2.0? Momentum. Seems like it's been playing catch-up with more pragmatic frameworks since its introduction in 2004. The JSF 2.0 spec looks impressive, but will the implementation be solid? Will the open source community be compelled to write JSF 2.0 components under the shadow of the Grails juggernaut?

BTW, Ed gave us 2GB USB keys that come with a VM that has a complete JSF 2.0 dev environment set up! It sounded exciting until I realized it was OpenSolaris and NetBeans.

JavaOne 2008

2008-05-20T01:50:00.001-07:00

Overall, a lot of great sessions. This was my first JavaOne, so I was surprised by the crowds and the chaos, especially around the 300-numbered rooms. And the spartan lunches. Wait a minute... 300? Spartan? Chaos?

"This is madness!"
"Madness? This... is... JAVAAAA!"

Here's the hot stuff:

Scripting, especially Groovy

OSGi (I thought so!)

Java 5 Annotations everywhere

VMs, grids, clouds, etc.

Ajax Push

Here are my impressions of the sessions. If you wish to focus on the speaker's points rather than my comments, ignore text in this style.

JSR-286: Java Portlet Spec 2.0

They've been working on this for over 2 years! It just got approved in March, and Pluto 2.0 is being developed as the reference implementation. It features:

Events for inter-portlet communication.

Clunky server-side-only portlet wiring with XML, similar to IBM's proprietary portlet wiring from WPS 5.1.

Serving and caching resources

Limited AJAX support... transparent to the portlet

Portlets can get their render params directly from the page's URL!

Portlets can mess with cookies, headers, and the HTML HEAD element!

Portlet filters, much like servlet filters.

More flexible caching

In summary, to add flexibility to the portlet API, they had to duplicate much of the servlet API to include features like cookie handing and filters. Here's an idea... instead, why not base your portlets on the servlet API?! The server-side "portlet prison cells" are still there; they just tried to make them a bit more comfortable. And they failed.

What I really wanted to know to how all this newfangled portlet wiring / event processing works on the client side with AJAX.

"Umm... the group couldn't come to an agreement about that, so we left it out of the spec."

Oh, you've got to be kidding. Then, the speaker refered to the OpenAjax project as a possible solution. More on that later...

Here's the 1st bullet of the summary slide:

JSR 286 is a large step forward -- The size of the specification and the API more than doubled
compared to V 1.0

In other words, "My foot got fatter, therefore it's a large step forward!"

The Many Moons of Eclipse

Eclipse 3.4 (Ganymede) -- will have better provisioning support that replaces the clunky Update Manager. You can easily share bundles between multiple Eclipse installations.

WTP 3.0 (Web Tools Platform) -- Lots of new wizards for servlet filters, etc. Web service wizards that can create new services from POJOs. Support for more app servers.

RAP -- Rich AJAX Platform. Can use the Eclipse development model and deploy an app as an AJAX-driven, Eclipse-looking, Eclipse-feeling web app. Not too useful; this means we'd have to learn the weird Eclipse APIs and widgets. But, there may be some cases (such as making developer tools) where it may be nice to have both an Eclipse plug-in and and Web UI.

Eclipse itself is built with OSGi components, package explorer has some improvements for OSGi support.

General Session

JEE is getting too fat. JEE6 will have:

Profiles, which will let you choose a profile like Web Dev, and much of the unused EJB stuff gets pruned.

Scripting support.

Extensibility, better integration with popular Open Source packages.

Servlet 3.0 spec; more on that later.

RESTful web services with JAX-RS and annotations.

New Glassfish app server (3.0 tech preview 2) has a tiny kernel and fast startup, all OSGi-based. Has a nice, new app server interface written in JSF.

Java SE 7 expected next summer. JDK 7 will focus on performance improvements, modules / bundles, similar to OSGi. It will support both JSR-294 / JSR-277 ("JAM" modules) and OSGi bundles, interoperably. Another big deal in JDK 7 is to make the JVM more language-neutral by supporting dynamically typed languages (JSR-292), starting with JRuby.

Newest JRE 6u10 is the streamlined, consumer version with fast startup, and support for... uh-oh... here comes the hype...

When several thousand developers cringe at the same time, does it make a sound? Yes, I heard it when these bold words appeared on the screen:

APPLETS ARE BACK!

Oh, but these aren't your grandfather's boring, gray AWT applets! These are JavaFX applets! They can show thousands of videos spinning around in 3D! And you can drag them right off your browser and onto your desktop! And they look so slick!

They're trying to compete with Flash. Good luck. Reminds me of Microsoft Silverlight. Flash is just about everywhere; do you really expect end users to install the lastest JRE just to see your JavaFX-based page?

At least they showed a cool site where Java guys like to publish their talks: http://www.parleys.com.

Spring 2.5

OSGi and annotations galore! Spring 2.5 JARs are now OSGi bundles. Classloaders were changed to be compatible with OSGi and the Java Modules in the upcoming Java 7. You have one ApplicationContext per OSGi bundle. Spring integrates with OSGi's service registry.

Support for JSR-250 annotations that fit into an object's lifecycle. @Resource looks useful... by default, it will lookup a resource (such as a DataSource) through Spring beans, and then failover to use JNDI. But, you can already do this "failover" with DataSources in Spring with XML.

Support for servlet 2.5, JSF 1.2, JAX-WS 2.

Annotations for DI. I'm not entirely sold on using annotations for injection. As Rod pointed out, the big drawback is that annotations are per type, not per instance. With XML DI, you can have multiple instances of the same type wired to different components. Not so with annotations. And of course you don't have the same separation of code and wiring like you do with XML. In XML, you can be more precise in your wiring and use tools like Spring IDE to figure out how the components are wired... useful for those who are new to the project.

Anyway, if using annotations for DI, @Qualifier provides hints for resolving the wiring, using meta-annotations, which are annotations that annotate annotations. Qualifiers can also be used in XML to declare auto-wiring hints.

If tapping into the Spring lifecycle, Rod says that the preferred way is now to use @PreConstruct and @PreDestroy. The best practice is to avoid Spring specific stuff in favor of standards... that's what he said, and that's a big part of what has made Spring so successful... adhering to standards and popular Open Source projects, while building upon them and making them easier to use.

Something that makes these annotations more appealing is Spring's component scanning feature. It will scan the class path for Spring-annotated classes, and get this... it examines these classes by reading in the classes in binary form and examining the annotations through the bytecode rather than loading them in through a classloader, which can cause problems.

With Spring MVC 2.5, you can declare request mappings and parameters and other controller details in the annotations. For instance:

@RequestMapping(method = RequestMethod.GET)
public String setupForm(@RequestParam("petId") int petId, ModelMap model) {          
 Pet pet = this.clinic.loadPet(petId);
 model.addAttribute("pet", pet);          
 return "petForm";     
}

Looks sweet.

You can do similar stuff in JSF with RESTFaces and annotations.

Spring Security 2.0 was just released in April. It replaces the old "Acegi Security" and has much simplified configuration. We need that!

Spring 3.0 will focus on more MVC improvements, REST, and web services.

OpenAjax

(For some reason, AJAX isn't always in all caps.) The OpenAjax project has been around for a couple years. This provides a hub that enables multiple Ajax runtimes to publish and subscribe to events so that they talk to each other. The OpenAjax core JavaScript is under 2K.

15 companies and 20 Ajax toolkits are involved in OpenAjax, including Tibco GI.

Given the number of JavaScript frameworks and libraries out there, this could be very useful, especially in mashups. Interesting how when they demo mashups, they are careful to avoid words like "portal" and "portlets." They are SOA-based "widgets" or "gadgets."

Google Gadgets is the most popular widget API. The speaker demoed a Google Gadgets "transcoder" (available now) that uses the OpenAjax hub to enable trusted widgets to talk to untrusted widgets, such as an intranet gadget sending events to a Google Maps gadget to display a map for an address.

Security is often overlooked in mashups. When you've got sensitive intranet widgets running in the same browser as some guy's goofy Google Gadget, the sensitive intranet stuff is exposed through the DOM! That's why you need to run them in an IFrame, because that's the best sandbox a browser provides... until something called HTML 5.0 Cross-Document Messaging (postMessage) becomes a reality... in IE 8!

Hub 1.1 focuses on security, using IFrames and a protocol called SMash, developed by IBM!!! Hey, you JSR-286 Portlet API astrophysicists! Your own guys at IBM figured out how to do inter-portlet communcation with AJAX! Maybe you should talk to them! The hub handles event publish/subscribe across IFrames and also between client and server, all events go through the hub's security manager, which looks at who is talking to who and ensures that events are sent securely.

Widget interoperability is declared in XML metadata, which describes the publish/subscribe properties and where to get the widget content from... which can simply be a URL that generates HTML for the widget's view mode.

But, when end-users drag widgets to their page, how do they know which widgets can talk to each other? Maybe have "bundles" of widgets that are pre-wired to talk to each other... or widgets auto-discover each other's compatible events and respond to them.

Someone in the audience mentioned Intel's Mashmaker (beta), which you can use to add floating widgets to static pages, and it will remember their positions and settings when you revisit the page. Supposedly, you can have it extract bits of data from the page that match a pattern and feed them to other widgets. Video demo here. After you sign up, you'll get a username and password that you'll need to set in the toolbar before it displays the widgets. Not suprisingly, many of these are Google Gadgets.

Virtualizing a VM

Hypervisor-based virtualization, used in VMWare ESX and Xen, is much more efficient than traditional virtualization because it provides a thin layer of software on which to run the guest OSes. AMD-V assists in mapping virtual to physical address mapping at the hardware level.

The JVM itself is... well... a VM! Why do you need the extra guest OS layer when you can go directly from JVM -> hypervisor -> hardware? JRockit Liquid can interact directly with the hypervisor, without the need for an intermediary guest OS. Running JVMs directly on the hypervisor allows the hypervisor to more intelligently manage Java heaps across multiple instances. With a thick guest OS running the JVM, the hypervisor doesn't have much visibility into what the JVMs are doing. The hypervisor is busy managing the memory used by the guest OS, and the JVM heap gets managed as a side-effect.

Tips: Try to use less than 896MB in a Linux VM. Over that limit, more complex, slower memory mapping techniques are used. Tune JVM parameters like min/max heap size and -XX:ParallelGCThreads. Try to run the same guest OS version on a physical host for increased page sharing.

Late-Night Grid Lab

Sun Workstations with weird keyboard layouts! Solaris 10 desktop! NetBeans IDE?!?! HELP! It was hard to get much of the lab done because of this funky setup.

Sun has a free, Open Source grid engine! I didn't know that. Typical grid engine focused on solving computation-heavy tasks, such as running simulations, computing PI to millions of digits, etc. An application generates tasks, which are distributed across a grid, then the the results are merged together. Uses the standard DRMMA API... whatever that is. Sun has network.com, for pay-per-use grid computing resources.

I got a free shirt because I remembered the technique used for computing PI... it's like computing the area under a curve with Riemann sums. Oh, my! This is the first time I've used calculus in real life! Well, ok... it's in a lab setting, not exactly real life. There's a difference. Unless you're working on the JSR-286 portlet spec.

General Session -- Oracle Guy

Oracle VP guy was showing off Fusion 11g R4. They have some nice looking JSF charting components that detect the user agent at runtime and gracefully degrade from interactive Flash graphics to a static PNG if the browser doesn't support Flash.

Big announcement: Oracle Enterprise Pack for Eclipse. Yes, not everyone uses JDeveloper. It's free and it works with app servers other than Oracle's.

They showed off a cool app that was like an AJAX-driven, hierarchical company directory, where you can navigate the entire company in a giant tree. I've always wanted to write something like that. Maybe we should use JavaFX so that we have thousands of employee photos rotating around the center of the applet like bees swarming around a hive.

JDeveloper 11 R4 has spiffy visual SCA / SOA modeling tools where you can wire components together.

WebLogic Server Virtual Edition runs on JRockit Liquid. JRockit Mission Control monitors the heaps and other metrics with minimal perfromance impact on production servers. JRockit RealTime was interesting... instead of seeing JVM pauses and unresponsiveness during garbage collection, this figures out what's going on with the JVM and tries to make garbage collection intelligent and deterministic. In other words, it incrementally collects garbage instead of the usual scheduled "big garbage sweep" that makes JVMs unresponsive.

Oracle has a data grid product: Coherence. I wanted to look into this more, but their Coherence site isn't responding right now.

Coherence (noun)

1: the quality or state of cohering: as a: systematic or logical connection or consistency

Yeah, I'm not getting a very consistent connection to their site.

Groovy: The Red Pill --Scott Davis

By far, the most interesting and entertaining presentation, featuring EXPANDOOOOO-META-CLASS!

The speaker did a good job of introducing the language and its usefulness without diving into too many details about its syntax.

Overall, Groovy relaxes the verbose (or, as the speaker put it, "Victorian") syntax of Java. It leverages the Groovy compiler to fill in a lot of the mundane details for you, such as getters and setters. The last line of any method is an implied return statement... which reminds me of Perl. All attributes are private, methods are public by default. Semicolons at the end of lines are optional. Makes sense. You can do outrageously dynamic stuff at runtime, such as successfully calling methods that don't exist and implementing them on the fly.

All this reminds me of the first Spider-Man movie: "With great power comes great responsbility." Groovy gives you a tremendous amount of flexibilty in messing around with dynamic language features, but it also gives you the power to almost redefine the language and really confuse your fellow developers. Even though Java is verbose and syntactically based on C++, it did away with C++ "features" that were commonly abused, such as operator overloading and macros.

Groovy String = GString. Programmer + GString = umm... RearEndOutOfBoundsException?!?!

Anyway, you can do multiline strings and EL / Perly looking expressions within strings, like "${title} by ${artist}."

Objects that are are declared final in Java are now extendable in Groovy, and you can add and redefine methods at runtime:

String.metaClass.shout = { ->

 delegate.toUpperCase()

}

This reminds me of JavaScript, where you can do something similar with String.prototype.shout. Dynamic method replacement is useful for testing... you can override your real method implementations with mock methods. There's a built in GroovyTestCase class.

The "each" method is built into a lot of objects, replacing clumsy for loops. Very useful for iterating through lines in a file and XML elements. Working with hash maps becomes rather Perly:

map.each(key, value->println("${key} = ${value}"))

Numeric literals are objects, so you can do 5.times(println "hi"). That's a bit weird.

GORM is a groovy wrapper for Hibernate.

SCA with Apache Tuscany

Wire components together with annotations or XML (Service Component Definition Language), by specifying different bindings like JSON-RPC, useful for wiring client-side and server-side components together. Also has ATOM and JMS bindings. Aligned with OASIS Open Composite Services Architecture (CSA).

New support for OpenAjax widgets with <implementation.widget location="widget.html" />

Works with OSGi, of course. The slides show that it includes a deployment framework that could potentially handle grids, clouds, etc... but they're just starting to implement this.

Make an SCA app in 10 minutes

So, how does this work with Spring? Andrew Borley says that Spring is for wiring up objects locally, and Tuscany is for wiring remote objects. See slide 25 from this presentation. Local beans are wired through Spring, which in turn may be wired by Tuscany to remote services.

JPA 2.0

This is a WIP. A criteria API! Hooray! Expanded O/R mapping. Overall, some of the curious omissions from JPA 1.0 are fixed, where you had to use Hibernate-specific annotations. This includes support for mapping collections of basic types like and strings and integers.

Support for "embeddables" that get flattened out in the database schema; Hibernate has this already.

@OrderBy annotation to influence the sort order when the list is retrieved. Different from @OrderColumn, where order is persistent and enforced by an integer ordering column.

More flexibility in map support, can use basic types for keys and values, like integers.

Under discussion:

Caching

Custom functions in the select list, kind of like calling a stored procedure, but with a custom Java method.

Better management for detatched objects

Ajax & JSF: Natural Synergy --Kito Mann

Natural Synergy?! Like mixing oil and water? A very good presentation with a bad title.

There is no standard JavaScript bridge to determine which JSF component to update, so many Ajax component libraries do their own thing and step on each other. A good point Kito made is to choose a good component library that meets your needs and stick with it. Start with the Tomahawk components first, add some RichFaces to it and see if that makes you happy.

Ajax4JSF (now part of RichFaces) lets you easily add Ajax support to existing JSF components. You can define regions of the page that can be updated via Ajax. Familiar JSF component attributes like onclick can fire a server-side event and perform a partial page refresh. Something like this:

<a4j:support event="onkeyup" reRender="myPanel" />

Extends the standard JSF ViewRoot with AjaxViewRoot to determine what needs to be updated.

ECruiser is commercial, has fancy components based on data tables and spreadsheet-like functionality, with lazy loading of data as the user scrolls and reveals new areas of the table.

ICEfaces has direct-to-DOM rendering. The server maintains its own model of the browser's DOM and processes very specific changes to the DOM. This is innovative, but I think this strays too far from JSF and utilizes just about every JSF extension point to turn it into almost something entirely different from what JSF developers are used to. This makes integration with other JSF libraries very difficult. Check out the ICEfaces architectural spaghetti on slide 29! This is the only component set that implements Ajax Push (Comet); more on that later...

Then, you have pure Ajax widgets, that were developed independent from JSF. There are JSF wrappers for them, such as jMaki, YUI4JSF, DojoFaces, Mojarra Scales (add-on components to the JSF 1.2 RI).

jMaki

presents a common model for different libraries.

Supports widgets from Dojo, Yahoo, Flickr, Google! Oooh!

Works well when the focus is on client-side visual eye candy and Web 2.0 components.

Not as tightly integrated with JSF, so it's a little weird to tie components to data exposed by JSF backing beans. You use some JavaScript-looking syntax in the value binding.

If rolling your own Ajaxy JSF components, use an existing toolkit like RichFaces CDK.

JSF 1.2 improves Ajax support by allowing another shorter lifecycle instance alongside the standard one.

Groovy on the Cloud -- Chris Richardson

Groovy-based Cloud Tools written by the speaker.

Solaris is now officially supported on Amazon's EC2.

With VMs (instances of AMI images) on the cloud, the state of the VM (including local files) are lost. So, you need to be careful with production instances, but this works out very well for development and testing, because when you start the instance, you start with a clean slate. Persistent storage (mountable inside the VM) is coming soon, probably this year.

For storage, you have S3 buckets and objects. Buckets are like folders, objects are like files. But, you cannot nest buckets within buckets to represent a hierarchy. However, you can name your objects so that they represent a folder hierarchy, i.e. local-mnt-jakarta-whatever. Clever! There are 3rd party Linux file system drivers that store data in S3. Even more clever!

S3 has nice REST & SOAP APIs to manipulate the buckets & objects: GET / PUT / DELETE, etc. works well for files. Many large scale sites out there love to use S3 as a big, fat, cheap file repository for serving static content, like video.

As an example of the outrageous scalability of EC2, there was a Facebook-like social networking app that would have been crushed under the weight of its own success, as it was initially launched with only a few AMI images. Within a week or so, they were able to scale it up to over 3,400 images to support the load. Wow.

Elasticfox (Firefox plugin) is the easiest tool to use for managing EC2 images.

There are many standard EC2 AMI images. Rather than building a custom AMI image, it may be easier to configure a standard image to launch a script upon startup, to do a yum install, copy files, etc.

Cloud Tools ease application deployment and can even perform load tests with JMeter. JMX support is there to monitor the app server and can collect metrics like txns per second, average response time. You can run multiple JMeter tests in parallel and generate reports.

For functional testing, there is Selenium Grid from ThoughtWorks. Selenium itself is a nifty Firefox plugin that lets you record macros for browser interaction and play them back, checking for certain responses along the way to ensure that the app is working. I've used it a bit.

JetS3t tool accelerates uploads to S3. It computes the difference of the existing S3 bucket content with the content you're uploading, so that you merely upload the incremental update, instead of the entire S3 bucket all over again. Cool. Consider something like uploading a WAR. Very little changes in a WAR file between code updates; almost all of the bulk is in standard JARs that don't change between updates.

Cloud Tools has Maven goals to deploy, undeploy, etc.

What made this session really good is Chris Richardson's evaluation of Groovy. While Chris Davis evangelized Groovy in the "Red Pill" talk, Chris Richardson took a more pragmatic approach... maybe because he's not writing any books on it yet.

...so, Groovy can be frustrating because the IDE support isn't quite there yet. Well, you can't entirely blame the IDE plugins, because now you're dealing with a very dynamic language, and the IDE doesn't have the usual, rigid Java syntax to fuel its suggestions. Supposedly, there is a good IntelliJ plugin for Groovy.

Unit tests sometimes have trouble catching things like missing methods, because in Groovy, it's acceptable to call a method that doesn't exist.

General Session -- Intel Guy

Web 3.0 means context awareness. Whatever.

Sun is getting cozy with Xen... Xen + OpenSolaris = Sun xVM.

The latest JRE is 68% faster on Xeon than the previous version. What does this mean? More graphics spinning around in 3D using JavaFX, or course!

Groovy & Grails -- Guillaume LaForge

Speaker was not prepared for this presentation. Why isn't my code working? Audience, please tell me! You're the Groovy project lead, you tell us!

This is interesting: you can use Groovy to override the singleton type of behavior, even if you invoke a class as a singleton, you can force it to create a new instance every time:

Dog.metaclass.static.bark = { new Dog() ... }

Again... be careful not to confuse other developers with this!

Implementing methods at runtime is expensive, so intercept the method call, cache the method implementation, and then invoke it, something like Dog.metaclass."$methodName" = { -> call the cached $methodName }.

There are all sorts of DAO patterns in Java; the speaker thinks that even the generic DAOs (as detailed in the Manning Hibernate books) have too much repetition. With Groovy, you have Dynamic SQL Finders that are based on the domain class. Domain classes are all about leveraging Groovy as a Domain-Specific Lanuage and using Domain Driven Design. This is where you can use Groovy's dynamic features to make the language fit your task, rather than the other way around.

So, you can use Groovy's method-implementation-on-the-fly to do stuff like this:

album.findAllByTitleLikeAndArtist(...)

...and it will transform the method name into a SQL statement at runtime! Is the world ready for this?

Groovy can help make Spring more transparent by doing something like this...

Book.metaclass.constructor = { -> (use Spring's appContext to make the actual object instance) }

...so that you can simply call the object's constructor, and it will use Spring's bean wiring magic to instantiate the object.

Did this speaker even really say anything about Grails? He noted that you can tell that a dog is French because it says "wouf" instead of "woof." Reminded me of a scene from an old Pink Panther movie.

Servlet 3.0 API

This WIP (JSR 315) will be part of JEE6. Overall, they are beefing up the servlet API and focusing on modularity and integration with Open Source frameworks, handing some stuff that EJBs were supposed to handle.

The old, monolothic web.xml will be more modularized, so configuration for frameworks can be more self-contained. Framework JARs can have their own little web.xml files tucked away in META-INF, using a new element: web-fragment. There will be more APIs to configure the ServletContext for servlets, filters, and listerners at runtime. For now, most of these can only be set when the servlet starts up.

Of course, there are new annotations to assign methods to handle requests, declare servlet filters, etc. @GET, @POST, @DELETE, etc. for REST.

Aynch servlets! These make use of persistent HTTP connections to support Ajax Push and the Bayeux protocol (using JSON and publish/subscribe to pass events between client and server). A request can be suspended then resumed by an app to push an event to the client. ServletRequest has new methods to support this.

They're planning on some sort of login/logout support at the servlet level, based on the www-authenticate header.

New HttpOnlyCookies are restricted to server-side processing, so that they can't be hacked on the client-side.

Misc. stuff they're working on: better file upload, container-wide init params, and whatever is needed to enable upcoming features of JAX-RS and JSF 2.0.

In the Q&A session after the talk, I asked if they plan on making the servlet URL mapping more flexible, using something like regular expressions instead of just wildcards. They thought about it, but they're afraid to add such features while maintaining backward compatiblity. I suppose more fine-grained URL mapping would be handled by a web framework, anyway.

Converting Applications to OSGi -- BJ Hargrave, Peter Kriens

OOP is good, but you end up with a big tangle of objects. Tools like SOA, object factories, DI try to overcome Java's lack of modularization. But, that's not enough.

You may think that packages give you modularity, but packages are not heirarchical and they only control some visibility. A huge problem is that packages can be split between JARs. JARs are just dumb ZIP files that can contain any packages and classes, where all public classes are visible to everyone. For instance, while you think you have the right version of commons-logging in your WAR, the app server actually has its own implementation with the same packages and classes tucked away in a JAR somewhere.

In addition, there is no versioning support built-in to Java. Build tools like Maven help resolve versioning of JARs at build time... but these don't help with classloader issues at runtime.

There is no built-in extension / plug-in model. How do plug-in modules collaborate, and how do you enforce security?

In OSGi, your app consists of bundles that are exposed through a service registry. They had a nicer diagram in the slides, but I can't get to them now. This is the gist of it, with security enforced at all levels:

Traditional classloaders just blindly crawl through all the classes and JARs on the classpath. There is some configurabilty with the PARENT_FIRST / PARENT_LAST option, where you can tell the app server to look in your WAR first before the app server's JARs. But, it's still a mess.

In OSGi, you explicitly declare dependencies on bundles and versions, and an intelligent class loader looks at the network of relationships between bundles and figures out which one to load. An OSGi bundle is a JAR with metadata. Class loading is based on the package name, and you cannot have packages split between JARs. Also, because class loading is much more explicit, it is much quicker because the class loader doesn't have to go traipsing through hundreds of JARs to find your class! This has to be a big factor in why most web apps take so darn long to start up. Is it the Spring wiring or mostly the classloader looking for classes? (I'll keep this in mind for a future JProbe project.)

There was some sort of class loading diagram like this:

   System Loader
         ^
         |
   Context Loader
     ^      ^
     |      |
    App    OSGi --> bundles

So, your app's custom, weird classloader could still co-exist with OSGi, but you really want to avoid that.

Thanks to OSGi's strong versioning support, you can use multiple versions of the same class within the same JVM!

OSGi also provides lifecycle managment through an API that manages modules at runtime. Now I see where this "hot-swappable" or "incremental app update" stuff comes from in WebSphere App Server 6.x. WAS 6 is implemented as OSGi bundles, so if you have an OSGi-enabled app, you can update JARs at run-time, without restarting the app.

Many popular Open Source projects have OSGi metadata already, including Eclipse and Groovy. OBR is a popular OSGi bundle repository, also Apache Felix Commons and Eclipse Orbit. Maven is becoming more OSGi aware.

So, how do you convert existing apps into OSGi apps? Put all of your app's classes together into an uber-JAR and find cut points where you can separate out similar functionality into bundles. Find dependencies between the bundles and declare imports and exports for them, but focus on separating out one bundle at a time, or else you'll be overwhelmed. Of course, this fits into SCA, where you'll think of these bundles as service components that work together. A tool called "bnd" (bundle tool) helps you wrap your JAR as a bundle.

The raw OSGi APIs are difficult to use directly from your app, so you probably want to pick a toolkit like Spring Dynamic Modules for OSGi, which exposes Spring beans as OSGi services. There is also Apache iPOJO.

So, what do you do with legacy code? Rework it and include it in your OSGi bundles, or just refer to it? Refer to it when it's an external API that you don't have control over, and its implementation could differ... or it's pretty much just too big and ugly to bundlize. Rework and include it when it's small and you have high cohesion. Try to reduce the number of dependencies. Of course, fewer bundles is better.

Hibernate was a mess to OSGi-ify, because it refered to so many other libs.

When declaring your bundle, you can specify which packages are only visible to your bundle (Private-Package) and which are exported to other bundles (Export-Package). Identify "glue dependencies," which are optional features such as Hibernate importing packages from javax.mail for sending mail... specify "resolution := optional"

Replace your app's custom classloaders and reflection API calls like Class.forName() with OSGi compliant code, so that bundles and versioning are honored.

The only links between your bundles should be through service interfaces, so model them that way. Services are notified when they are registered and withdrawn. Figure out which services need to be registered with which other services.

Be wary of "containerisms," bundles that have too much control over other bundles and limit their usefulness outside the container. All the "strong cohesion / weak coupling" that applies to OOP applies to service design, as well.

Pax Runner helps you get started with OSGi. Apache Felix also has Maven plugins for OSGi.

JSF 2.0 -- Ed Burns

FacesTrace helps in debugging JSF apps.

Goals of JSF 2.0:

Make custom components easier to implement; possibly integrate with scripting languages.

Better Ajax support.
- Partial Tree Traversal to single out individual components to update.
- Partial Page Update to update only dirty regions of pages.
- Can define zones that are updated through Ajax, like Ajax4JSF.

PDL - Page Description Language, templating support like Facelets.

Less configuration, favoring "convention over configuration" like Rails.

More compatibility between component libraries.

Maybe a rewrite of state management code.

Maybe bookmarkable URLs, like RESTFaces.

Maybe there should be a simple way to map UIComponents to an XHTML file. Yeah, I've done something like this already!

There is a simplified lifecycle for serving resources. Also, localized, versioned resources and resource libraries, accessed through EL like #{resource['title']}.

Performance Comparision of the Big 3 Web Frameworks -- Sujoe Bose

Versions used: MyFaces 1.2.2, JSF RI (Mojarra) 1.2.03, JMeter 2.3.1, JDK 1.6, Spring MVC 2.0.6, Struts 1.x, and 2.x.

Under a high load with low think times between requests:

MyFaces ate up tons of memory. Both MyFaces and RI ate up nearly 100% CPU.

Spring MVC performed well, with low CPU usage. Struts 2.x tanked.

With realistic think time:

JSF RI performed well, better than MyFaces under a high work load.

The speaker ran this test on wimpy, single-core hardware, so the frameworks weren't able to utilize multiple cores for multithreading as they would on modern hardware.

DTrace BOF

DTrace can help diagnose end-to-end performance problems, from the client-side JavaScript calls down to SQL statements. Can turn on/off dynamically and has very little impact on production systems. There is a DTrace probe for FireFox 3 for collecting JavaScript metrics; it can collect JavaScript function args and return values. There are probes for Java 6 and even OS level library calls for reading files, etc. Support for MySQL 6 probes. Can probe just about any app written in C if you know the function calls.

To configure DTrace probes, need to write weird scripts in DTrace's own little language, but there are probably enough scripts out there to utilize.

All this sounds neato, but it only runs on OpenSolaris 10! And maybe parts of it on Mac OS. Call me back when someone has implemented something like libdtrace on OSes that I care about.

Night event! I'm off to the Smash Mouth concert! Hmmm... fizzy domestic beer and awful music. You can't even perform your own songs decently; why must you butcher Van Halen?

General Session

This is cool -- VisualVM. It gives you a very visual, JProbe-like interface for troubleshooting performance problems. It can monitor Tomcat and do heap analysis like JProbe. Needs JDK 6 to run, but supports profiling of Java 1.4 - 7. You can examine objects on the heap and filter on packages, etc.

The next version of NetBeans (now available as a preview release) has nice JavaScript support. It features context-sensitive completion for popular JavaScript libraries and warns you when you're using non-standard browser features. Supports JavaDoc style comments in JavaScript code to provide hints for the IDE. Integrates with FireFox, IE support coming later.

Something about Java gaming being cool again because of APIs like jMonkeyEngine that tap into lower-level APIs and make better use of the hardware.

Everyone loved the Java pen, Pulse from LiveScribe.

What's New in Ajax

A common problem with JavaScript heavy apps is that their event queue can appear to hang the browser and make it unresponsive. Developers don't have control over a browser's threads, but a tool like Google Gears simulates thread-like behavior through a wooker pool. The speaker showed a demo of an event-heavy app, and Google Gears indeed made it a lot more responsive.

There are some technologies like Mozilla Prism and Adobe AIR that can take Ajax apps and bring them to the desktop.

Aptana Jaxer can run JavaScript on the server side, so that you're running the same language on both the client and the server, and both sides can talk JSON. Jaxer can also support clients that don't talk JavaScript. (Aptana also has cloud stuff in beta.) This may sound odd now, but an interesting point that the speaker was making is that many of these harsh client / server boundaries are going to fade and maybe even disappear. Maybe language is one of the first of these barriers to fall.

Google App Engine - Google has its own cloud, like Amazon's EC2, with Python-based tools for deployment. Available as preview release for now, with free, wimpy accounts. Does this only run Python apps? Looks like it. What does this have to do with Ajax, or even Java?

Google's Ajax Language API lets you call language translation services through Ajax. It can also detect languages on the fly.

Best JavaScript frameworks are jQuery, dojo, scriptaculous, GWT, and prototype. jQuery is very DOM-centric, makes it easy to add behavior to page elements.

John Resig (jQuery guy) says that 1.2.4 will be out very soon. He's finally merging in the dimensions library with the jQuery core. It's about time. Prototype has always had this built in, for as long as I can remember. 1.2.4 also has performance improvements with event handlers, and 3 times faster drag and drop. Version 1.3 will feature more performance improvements, especially with DOM manipulation.

There is some sort of "ScreamingMonkey" project from Mozilla, as well as IE support through "IronMonkey." (Wasn't that a martial arts movie?) They're trying to take the Open Source JavaScript engine that is used in Flash players and plug it into browsers. Or trying to make browsers run scripting languages other than JavaScript.

Asynch Ajax & Java

AjaxPush, Comet, Reverse Ajax all refer to the same basic technique that uses application-mediated communication rather than the Ajax client making polling requests to check for server events. Different techniques:

Push -- low latency; no constant polling requests. GMail and Meebo use this.

Long Poll -- send request, wait for event to happen, then send response while keeping the communication open. Response is never empty.

HTTP Streaming -- send request, wait for events, stream the response in chunks, then wait for more events. Response is continually appended to. Beware of proxy servers messing this up, because they may wait for the full response before returning anything to the client.

So, much of this makes use of keeping the HTTP connection alive between the client and server. How will this work in large scale apps with a thread servicing each request?! Well... don't use a thread to process each request! Instead, use "queued file descriptors" to use a few threads to process tons of requests that are mostly sitting there waiting. Sockets are not the limit here; you can have thousands of them. Threads are much more limiting and can eat up a lot of stack memory. This technique makes use of NIO and avoids blocked threads.

For large file uploads, NIO can be used to get at 1 file part at a time.

The whole concept of keep alive connections with long polling and streaming is nothing new. Netscape described this as a "push" technique back in 1999.

The Bayeux and Cometd (that's not a typo) protocols are based on JSON and publish / subscribe. JSON messages are published on channels.

So, what app servers support these techniques?

Of course, the Sun guys are going to promote Glassfish as the best. Glassfish has built-in objects to support this, with "guaranteed delivery"... whatever that means. It's based on Project Grizzly, with GrizzletRequest and GrizzletResponse, which are designed around asynch processing, unlike the Servlet API.

Resin supports this by extending the Servlet class.

Jetty... you do something in the service() method with "continutations." Looks weird.

Tomcat 6 has CometProcessor interface with CometEvents. Looks nice and event driven like NIO itself. I like Tomcat.

I guess WebSphere App Server is starting to support Bayeux / Cometd in a beta / preview mode.

Heap Analysis with SAP Eclipse Memory Analyzer (MAT)

Nice! Read the blog and download here. Runs on Eclipse 3.3 and analyzes Sun JVM binary heap dumps. IBM heap dumps aren't supported because they're weird. IBM has their own heap analysis tools. This helps you determine who is keeping which objects alive. Can visually group objects by what classloader created them.

You can find duplicate instances of strings. This is cool because you can see actual string values in the heap... I don't remeber being able to do this with other heap analysis tools. This can give you a lot of insight as to which objects are being inefficient with strings.

You can also look at collection fill ratios and find collections that were instantiated with more capacity than they ever used, wasting heap space.

RIA with Flex and Java -- Tony Constantinides

This left me very unimpressed with Flex. Maybe because the speaker spent the first 20 minutes playing around with Flash sites over a slow connection, putting me into a drowsy state.

"You know what makes an interface really good? When the controls bounce! Look at this site of model photos! I can navigate vertically AND horizontally!"

May I navigate horizontally toward the exit?

Oh, he's talking about Flex now? Ok... when working with Flex, use the debug version of Flash, so that you can see what regions are getting updated. Get Flex Builder from Adobe for the swell Eclipse plug-ins. Not free. "Best $600 I ever spent!" he said. I could tell you about the best $600 I ever spent, but that would get me in trouble.

MXML - Macromedia XML for GUI layout. This compiles to ActionScript / SWF. Frame 1 of the movie contains the core, and frame 2 contains your app. Supposedly, there is a short learning curve for Java devs. You can define special effects like dissolves and hook them up to components through XML attributes.

Flex Builder has a profiler, CSS editors, data access wizards, web service tools, etc.

Adobe AIR lets you run Flex apps on your desktop, using WebKit. And it adds access to the file system, clipboard, and SQLite.

Flash Player 9u3 (9.0.115) has support for H.264 video and HE-AAC audio! Hooray! And more support for hardware graphics acceleration and multiple cores.

The security model restricts you to the same domain, but you can work around it with proxy servers or similar trickery.

Adobe Binary Protocol gives you quick data access. BlazeDS provides middleware for direct data access. Sockets are supported by disabled by default.

Flex talks to Java through <mx:RemoteObject>, which refers to a config file that refers to a Java class.

<mx:DataGrid dataProvider="(indirect handle to your Java function)" />, then you have <mx:columns> and <mx:dataColumns> within them. This is starting to look like JSF!

Flex 3 has an API to create SWF files directly from from Java, where you don't need an MXML file. You can add components like buttons through Java and generate SWF.

Spry-JS is some sort of Ajax plugin for Flex from Adobe, because "Flex isn't just about Flash," I guess it can interact with your browser, too.

Speaker, show us more cool web sites with Flash!

http://tv.adobe.com

Ok, now I can go home.