-- Devoxx last day, I only slept 2 hours during the previous night. Need I really say more? --
Clustering your applications with Hazelcast by Talip Ozturk
Hazelcast is an OpenSource product used by many companies (even Apple!).
HashMap is a no-thread safe key-value implementation.
If you need thread safety, you’ll use ConcurrencyHashMap.
When you need to distribute your map against distributed JVMs, you use Hazel.getMap() but the rest is the same as for the Map interface (but not interface itself).
-- a demo is presented during the entire session --
Hazelcast let you add nodes very easily, basically just by starting another node (and it takes care of broadcasting).
Hazelcast alternatives include Terracotta, Infinispan and a bunch of others. However, it has some unique features: for example, it’s lightweight (1,7 Mb) without any dependency. The goal is to make distributed computing very easy.
In a Hazelcast cluster, there’s a master, but every node knows the topology of the cluster so that when the master eventually dies, its responibilities can be reassigned. Data is backed up on other nodes. Typical Hazelcast topology include data nodes and lite members, which do not carry data.
Enterprise edition of Hazelcast is the Community Edition plus Elastic Memory configuration and JAAS Security.
It’s easy to use Hazelcast in tests with the Hazelcast.newHazelcastInstance(config) statement.
Besides, an API is available to query about the topology.
Locking is either done globally on the cluster or on a single key.
Finally, messaging is also supported, though not through the JMS API (note that messages aren’t persistent).
A whole event-based API is available to listen to events related to Hazelcast.
A limitation of Hazelcast is that objects put into it have to serializable. Moreover, if an object is taken from Hazelcast and then modified, you have to put it back into Hazelcast so that it’s also updated inside the cluster.
Hazelcast doesn’t persist anything, but ease the task of doing it on your own through the MapStore and MapLoader.
There are two ways to store: write-behind which is asynchronous and write-through which is synchronous.
Reads are read-through which is basically lazy-loading.
About long GC-pauses:
Killing a node is good, but letting it hang around like a zombie is not
There’s a plugin to support Hibernate second-level cache and it can also be tightly integrated with Spring.
mgwt - GWT goes mobile by Daniel Kurka
The speaker’s experience has taught him that mobile apps are fated to die. In fact, he has used and developed many mobile applications. The problem, is that you’re either limited by a too small number of applications, or the boundary goes higher and you cannot find them anymore. In the past, Yahoo put web pages into a catalog, while Google only crawled and ranked them. App stores looks like crap, they don’t provide a way to search for applications you’re itnerested in. Besides, when you’re looking for public transports schedule, you have to install the application of the specific company. Worse, some sites force you to install the application instead of providing the needed data.
When developing mobile applications, you have to do it for a specific platform. As Java developers, we’re used to the "Develop Once, Run Anywhere". Also, there’s already such an universal platform, it’s the browser. PhoneGap tries to resolve the problem and provides HTML and JavaScript as the sole language. Now, you get "Build Once, Wrap with PhoneGap Around, Run Anywhere".
GWT is a framework where Java is compiled into JavaScript instead of bytecode. Better, it’s compiled into optimized JS, and that’s important because mobile access may dry your battery dry. Finally, there’s GWT PhoneGap integration so you can write awesome webapps, wrap them into PhoneGap and release them on a store. PhoneGap works with your app composed of HTML, JS and CSS and plugins that are native and let you access mobile device features. Two important things to remember: data passed between app and device is done as strings, and calls are asynchronous. PhoneGap uses W3C standards (when possible); it’s an intermediate that will have to die when the mobile web is finally there.
Yet, PhoneGap doesn’t solve the core "too many apps" problem. GWT’s compiler compiles Java into JavaScript (a single file per browser). Remember that GWT’s code is optimized that would be hard to achieve manually: that’s very important when running on mobiles to due limited battery issue. mgwt is about writing GWT applications, aimed specifically for mobiles. In order to create great apps, be wary of performance. There are 3 areas of performance:
- Startup performance, a matter of downloading, parsing, executing and rendering
- Runtime performance which is really impacted by layout. As a rule, never leave native code. So, if you use JavaScript layout, you’re doing just that. CSS3 provides all the means necessary to layout. Likewise, animations built in JavaScript are bad and prefer CSS instead.
Both are taken into account by the GWT compiler. Note that mgwt provides plenty of themes, one for each mobile platform.
-- And now ends Devoxx 2012 edition for me. It was enriching as well as tiring. You can find the recap of the previous days here: