Conference Report: TheServerSide Java Symposium
Conference Report: TheServerSide Java Symposium
Join the DZone community and get the full member experience.Join For Free
"Power strips everywhere," was the first thought that struck me at TheServerSide Java Symposium, which took place Tuesday and Wednesday this week in Prague, Czech Republic. Instantly, the sad flat laptops around squashed JavaOne beanbags became little more than grim memory.
Wireless was immediately available and excellent throughout and, with the preamble prior to the keynote mercifully short and sweet, the conference had begun.
No Fate But What We Make
Neal Ford, delivering the keynote, presented something akin to a "state of the nation" in the realm of IT technology. He addressed the theme of "Predicting the Future", which was the title of his session. He pointed out that a blacksmith in 1890 was never out of work... just like a PowerBuilder developer in 1994. And, right now, there are probably as many of both, in very obscure corners of the world, but certainly not mainstream. Thus "how to avoid becoming a dinosaur in the technology world" was really the driving thought throughout an entertaining talk, with several fun and thoughtfully articulated points, such as that the unique feature of Ruby is that, at the time, it was alone in producing well-architected applications quickly, while prior to that applications were either (1) well-architected or (2) created quickly, but never both at the same time.
According to Ford, some of the signs of the times we now live in include the ubiquity of iPhone apps such as Ocarina (created on the fly by a music major who couldn't get work) and Pangea Software, which made $500 000 on iPhone apps in 2007, so that they stopped making desktop software completely after that. Though the perfect storm around Java is unlikely to be repeated again, there are certainly significant developments, such as the aforementioned iPhone app surge. The other big shift he pointed to, unsurprisingly, were the increasing popularity of functional programming, dynamic languages, and polyglotisms. A few of the interesting implementations of the new world we live in include Twitter, unsurprisingly, but also some very interesting sounding applications I hadn't heard of before, such as secrettweet.com and PostSecret.
Rounding off, he asked himself the question what the "next big thing would be" and stated that we couldn't possibly know that, but that it could potentially come from left field. "No fate but what we make", the Terminator reference, and a Peter Drucker maxim "Go creative, that's how you have most control over it", were the thoughts we were left with when the keynote came to an end.
Highlights of Sessions
Next, two tracks were kicked into action, around which the rest of the conference was structured. The range of topics was interesting, in particular the fact that there were many sessions on monitoring, performance, and the like.
The first of these, "Real Life Java EE Performance Tuning", was based very strongly on case studies. For example, one of these consisted of a customer with a live environment where it took several minutes to log into an on-line system. After the first login, which would take 5 minutes, everything would be fine. So the speaker explained that anything that chokes for a consistent amount of time is suspicious, probably pointing to a timeout somewhere in the system. It turned out that the Firewall was terminating connections that had been open too long and that this was affecting the initial login time.
Another case study involved AJAX calls seriously impacting performance, while the AJAX calls had never really been needed in the first place: the fancy table of contents built around AJAX had only been created to enrich the developer resumes and were not functional to the application at all. Tools mentioned in this session were Ethereal, Wireshark, Firebug, and YSlow. An interesting point was made in that customers tend to find tools quite intrusive (i.e., when you're debugging or tuning their systems) and that thread dumps are therefore not only quicker, but also less likely to be an annoyance since no tools need to be installed.
Kirk Pepperdine's two sessions on performance, in contrast to the empiricist casestudy approach outlined above, turned performance tuning into a science. The first of his sessions, "Hunting Memory Leaks", provided his audience with a set of very clear definitions. A memory leak is a persistent critical memory condition, a non-recoverable situation that never goes away and survives every attempt to collect a particular object. If an object survives all collections, it's a leak. Therefore no guessing (e.g., size-based guessing) is necessary, one simply needs a tool that identifies objects that survive all collections! Prior to introducting that tool, Kirk gave us some more definitions:
- Object age. The number of collection attempts an object has survived.
- Generation. All objects of a class of the same age.
- Generational count. The total number of different generations.
Most objects live in one generation only. Some live in all generations and survive all collections. These are the memory leaks. Therefore, if the generational count is high, the objects are surviving collections. And the generational count exactly identifies which objects are leaking.
The question, then, is one of identifying the generational count. And, as Kirk explained, only the NetBeans Profiler does that:
The steps to solving memory leaks were outlined as follows: (1) Use the NetBeans Profiler to determine the generational count, (2) Take a heap dump and determine the GC route, (3) Do an allocation strack trace, (4) Examine the execution path between the points.
Interestingly, Kirk argued that you don't need to know anything about what the application is made for when you're tuning it! (I.e., whether it is an app for market X or market Y is irrelevant). He says you need to look at one method in one class (i.e., the method identified via the procedure above) when solving memory leaks.
Finally, responding to a question about the possibility of static analysis for performance tuning, he introduced the world to this brilliant thought: "Roads don't have bottlenecks until you add cars." It was a great session.
In his second session, Just Tune It, he discussed that the dynamics of a system need to be analyzed when you're doing performance tuning. In other words, you need to look at the JVM and operating system too, not just at the application. The dynamics of a system are the actors, which are users or other systems (via web services, for example).
Kirk then introduced another scientific-sounding definition to the tuning story: "the dominating consumer". When assessing CPU problems, which activities dominate? I.e., what is the dominating consumer? The answer is one of the following 4: operating system, JVM, application, or nothing. Depending on which it is, you have different kinds of problems and different approaches to solving them.
Other performance/debugging sessions at TheServerSide Java Symposium included Open Source Debugging Tools: The 10 Tool Boot Camp, A Year of Monitoring with Java Monitor, and Practical Lessons in Memory Analysis.
If performance and monitoring was one red thread throughout the conference, then another was Spring.In that context, I attended three sessions. The first was very intriguing: Integrating EJB 3 and Spring by Reza Rahman.
After outlining EJB 3.1 and Spring 2.5, Reza listed the strengths of each. For EJB, the strengths are standards based, zero configuation, secure, transactional, thread safe (good for business tier, specialized for the business domain tier), JPA integration seamless, statefulness, passivation, extended persistence context, message driven beans, robust web services/remoting, clustering, load balancing, instance pooling and server thread optimization, IDE and application server tooling support.
For Spring, the listed strengths were advanced dependency injection, advanced AOP including AspectJ support, Spring JDBC intergration, Spring JMS, iBatis, Hibernate, JDO, TopLink DAOs, and Quartz integration.
Combining the best of both worlds, Reza argued that the two technologies are not mutually exclusive. Not only that, but the combination can be achieved either on Tomcat or a Java EE server. The benefits lie in ease of use and vendor neutrality, enabling you to take advantage of AOP and DI, as well as a broad range of integration APIs. He especially highlighted Springs's nice abstractions and integration APIs (e.g., Quartz and iBatis), which can be very valuable in the context of Java EE 5.
What about the mechanics of Spring/EJB integration? Reza discussed, amongst others, how Spring can be used within a Java EE 5 container, how EJB 3 embeddable containers (OpenEJB, EasyBeans, Embedded JBoss, Embedded GlassFish) can be embedded into Tomcat with Spring, how Spring beans can be injected into EJBs, and how EJB can be used natively within Spring using Spring's Pitchfork.
In addition to the above interesting session, I attended two sessions on the second day about SpringSource. The first was the keynote. Adrian Colyer began by showing Grails and then said... but what if I want to do this in Java? And that's when I heard of Spring Roo for the first time. In other words, Grails for Java developers. It does seem, to me, that Spring Roo is an impoverished version of Grails, though. But that's because I like Groovy. For developers who find Groovy too radical, or whatever, it seems to me like Spring Roo would be a good choice for the Grails convention over configuration approach. The SpringSource Cloud Foundry, presented as "somewhere between Amazon EC2 (infrastructure as a service) and Google App environment (play by their rules)", was also mentioned in this session. The second Spring session I attended on the second day was Rob Harrup's session Modular Web Applications with OSGi. I thought he did a great introduction to OSGi service creation and bundle reuse in OSGi. It was the first time I heard about yet another Spring technology: SpringSource Slices, which is OSGi oriented for the web (and I hope I'm not horribly misrepresenting it with that quick phrase).
Got to say it though: with all of these SpringSource technologies, cool as they may be, it becomes harder and harder to associate it with the "lightweight" label that Spring originally trumpeted.
As always at conferences of this kind, as much [if not more] value lies in interaction with other attendees as in actually attending the sessions. (I'd say as a rule of thumb you should spend at least as much time programming with random people you come across at a conference as you're spending picking up nuggets of wisdom in the sessions.) In that sense, this conference was pure gold for me.
Firstly, Andrew Lombardi, presenter of the Rapid Application Development with Apache Wicket session, gave me a hands on understanding of the purpose of models in Wicket, which is something that's thus far always managed to allude me. At the end of the day, I ended up with a small example that wraps a Customer bean into a CompoundPropertyModel and then displays it on a page which, when OK is pressed, results in the entered values being displayed on a confirmation page. Potential future tutorial for Wicket users!
Secondly, I met the Vaadin framework's Sami Ekblad at the Vaadin booth (the only booth at the conference, for some reason) and we ended up creating a Vaadin plugin for NetBeans IDE together, in the space of a few hours of refactoring of parts of the NetBeans Wicket plugin.
A particularly unique thing about TheServerSide Java Symposium was that lunch times entailed needing to chose a table to sit at based on a table theme. Each table had a theme written on a piece of paper, like "Performance" or "Tooling" and everyone interested in that theme would be sitting at the same table, meaning that you'd avoid the uncomfortable silence by launching into your opinion on the table theme right away. I confess looking for a table with "Uncomfortable Silence" as the table theme, but didn't find one. Next year, maybe?
In short, it was a great conference, very well organized, with great speakers.
Opinions expressed by DZone contributors are their own.