The Changing Nature of Enterprise Java Application Development, 9:00 – 9:45 by Adrian Colyer
During his talk, the speaker described the audience the future of a Java platform, because it is actually going to be there for a long time now.
He mentioned the dynamic languages compatible with the JVM : Groovy, JRuby, Scala, and Clojure.
He mainly focused on Groovy (which belongs to SpringSource by the way), even if he was not sure if whether JRuby or Groovy would win the « war of dynamic languages ».
For the web platform, he mentioned Grails, built on top of Groovy, Rails running on top of Ruby, and Lift built on top of Scala.
He finished his talk introducing OSGi and Spring DM; the future of enterpise is application may be in the cloud : easily to deploy and scale applications are to come.
The android runtime environment, 10:30 – 11:20, by Joerg Pleumann
The speaker first made an introduction to the Android system, as a platform competing windows mobile and palm.
More technically speaking, it is based on a Linux kernel (along with necessary drivers : display, camera, sound, etc…).
On top of it come the Android Runtime and libraries; the talk is about the Android Runtime and its Dalvik VM.
Dalvik VM : CPU between 250 and 500 MHz, RAM >=64 (equivalent to a 1999 PC), but low power consumption is critical.
The Dalvik VM is really efficient, using explicit registers to keep temporary values: the immediate benefit is the number of lines of the bytecode resulting from the DalvikVM compilation : nearly 30% less than a standard VM compilation.
A dex file (Dalvik Executable) contains several files, and is not compressed.
JNI is ready, a sdk for using JNI is about to come out in the next days; also an Android Debug Bridge is available from the beginning.
The core libraries
dalvik vm specific libraries : dalvik.*
java compatibility libraries : java.* and javax.*
and some apache libraries(mainly for http) : org.apache.*
The core libraries are partly taken from Apache Harmony (a JDK implementation by Apache), partly written from scratch; and some of them have been optimized (using JNI)
The core libraries are mostly compatible to a subset of J2SE 5.0.
JDBC 2.0 is supported, but the SQLite driver is limited., but one can use the alternative in android.database.sqlite which are better integrated.
To conclude with, with Android you can reuse your java knowledge and tools.
Android Application Model, 11:30 – 12:20, by Dominik Gruntz
4 main components :activities, services, content providers and broadcast receivers.
A single class, uses intents to communicate with the other activities; when you launch an activity, you can (or not) expect a result; if this is the case, the method onIntentResult will be called.
You can also define intent filters to describe the intents an activity can handle.
An intent specification is on its way : http://www.openintents.org
An application is packaged using an APK (Android package).
Every activity has a lifecycle containing 4 steps : new, running, paused, stopped, killed and the corresponding methods (onCreate, onStop etc..)
For each activity a new process (with a single thread) is created.
The Looper.loop() dispathes the actions to a queue.
If an activity does not conume events in 5sec, the system issue a warning message.
A service is running background and can communicate with an activity (in process if it’s the same application (APK)) or via AIDL.
Finally, a content provider is the only way to share date between Android applications; it can using SQLite, a file, or a remote storage.
Scalable Agile Web Development: REST meets JCR meets OSGI, by Michael Marth
JCR : JSR 270 for accessing content repository : located on a file or database; can be versioned; node ahave read/write group properties, etc…
Apache Sling is a web framework, on top of REST/Scripting (Ruby, Groovy, etc…)/OSGi(in this case Apache Felix Container, to switch on/off part of the frameework live)/JCR.
So basically Apache Sling allows the user to create/edit/read/update content in a restful manner (http methods), the data being created is then stored on the JCR repository, organized in a very similar WebUrlFriendly way (and then you can manipulate the data through rest or webdav and so on, thanks to JCR)
The demo was really smooth and interesting !
The charm of Mockito: Test Spies in action, 14:30 – 15:20, by Szczepan Faber
The speaker begins asking who uses JMock : 2 or 3 people among an audience of 60 people, half of the audience using EasyMock.
So let’s start with EasyMock : coding in TDD a dictionnary, (and its history) depending on a translator : the translator is mocked.
With easymock the speaker keeps it old fadhioned : createMock/expect/replay/assert/verify , (his test extends Assert) and then refactor a bit in the @Before and @After test methods, nothing special here.
Then Mockito : mock/when/assert/verify : it’s a lighter syntax indeeed!
Szczepan insisted on the fact that usually developers using easymock create replayAll and verifyAll methods called in the @After method; which make Easymok fail when many behaviours are attached.
The speaker uses BDD style template (given/when/then) in eclipse, when creating a test.
Mockito eases the use of a given/when/then syntax when writing a test.
Has good point of failure ?
The failure trace in mockito is linked to the source code and more explicit about the error, it does not whow internal classes exceptions
He concluded with : « Do TDD and write great tests with whatever tools that work for you »
May the force be with you !
Eclipse Galileo and JBoss Tools, 16:30 – 16:50, by Max Andersen
Galileo (3.5) is a huge release.
Must-sees : Eclipse Memory Analyser (to see which plugin consumes all the memory for example), using jmap
XML and XSL editor is really better.
P2 (eclipse update manager) works for real; you shouldn’t use dropins anymore (single zip files to unpackage in /plugins and /features), for offline installation plugins providers should suggest copies of the update site, then you may use P2 to explore these files, as if you were online).