InfoQ Homepage Presentations Java.next
Java.next
Summary
Erik Onnen attempts to demonstrate that Java is still the best programming language for the JVM if simplified idioms are used along with proper tooling.
Bio
Erik Onnen is a Senior Engineer and Analytics team lead at Urban Airship, the leading provider of Push, In-App Purchase and Subscription services for mobile applications. He specializes in distributed systems at scale. Prior to joining Urban Airship, Erik was a platform lead for Jive Software where he lead the development of the activity and recommendation engine services.
About the conference
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Community comments
Trying to promote weaknesses as advantages ????
by Serge Bureau,
Very interesting
by John O'Hanley,
Re: Very interesting
by Oleg Pro,
Re: Very interesting
by Johannes Jensen,
"logging almost never degrades performance" ???
by Kai Wähner,
Get the message out there!
by Ivan L,
Missing Language Features
by Clifford James,
Re: Missing Language Features
by Iqbal Yusuf,
Cool idea of not using a container.
by Sai Matam,
Trying to promote weaknesses as advantages ????
by Serge Bureau,
Your message is awaiting moderation. Thank you for participating in the discussion.
After writing Scala for a little while, Java seems so weak.
Using available frameworks do save time, but for new code, Java does not even come close to cut it anymore.
The part I do agree with is moving away from EJB, EAR and WAR.
Java "easy to read", sorry but it is not true since Java 5 and it is getting worse each successive revisions.
Time to move on.
Very interesting
by John O'Hanley,
Your message is awaiting moderation. Thank you for participating in the discussion.
Interesting talk. Erik clearly has a lot of practical experience with high-traffic servers. He makes points about many things; some that caught my attention:
I applaud his strong preference for simple practicality.
What exactly does he use instead of a container, I wonder? That didn't seem clear from the talk.
Re: Very interesting
by Oleg Pro,
Your message is awaiting moderation. Thank you for participating in the discussion.
An app based on Play framework could be good example of system that dose not use web container.
Re: Very interesting
by Johannes Jensen,
Your message is awaiting moderation. Thank you for participating in the discussion.
He talked about using en embedded Jetty server with Jersey on top. So they are opting out of the container managed lifecycle but not containers per se.
Get the message out there!
by Ivan L,
Your message is awaiting moderation. Thank you for participating in the discussion.
Back on the east coast, there is still lot of hand wringing on the part of tech managers if they run something that wasn't defined in a specification. There is a very natural contradiction to be had in that these same managers are using enterprise products because they want to provide value, yet the specifications trail the open source community, which is popularized exactly because they provide value.
On the contrary, once something makes it way into *insert enterprise container here*, its probably a diluted form of the good open source idea.
I loved the easy dismissal of xml oriented orm tools, thank you for bringing sanity back to Java. After you code a DAO, you typically never need to see it again. The only thing that I've ever really seen Hibernate add is development and maintenance cost.
I also agree on embedded Jetty. Previously I was advocate of Tomcat, but embedding Jetty was so easy I can't even see myself using Tomcat that much anymore either. You can also quickly add great features to embedded Jetty that would be a lot harder to do even Tomcat (and would force you to get into the configuration muck of it)
Missing Language Features
by Clifford James,
Your message is awaiting moderation. Thank you for participating in the discussion.
Good points but I still wish Java had language support for read-only C-style structs w/ built-in equals() and hashCode() semantics. Groovy and Scala both have shortcuts for this (Scala will enforce the immutability as well). I do feel like this is a missing java feature masked as a "pattern" that requires a good bit of boilerplate. Even with a good IDE, you still have to type a lot for these. Totally agree about XML though ;-)
Re: Missing Language Features
by Iqbal Yusuf,
Your message is awaiting moderation. Thank you for participating in the discussion.
Very radical specially if you are a developer in a enterprise IT. :) About a year back while upgrading a 10 year old Java system I proposed embedded Jetty without using any container. Could not sell the idea on security issues. I would like to know more about securing embedded Jetty. Great presentation.
"logging almost never degrades performance" ???
by Kai Wähner,
Your message is awaiting moderation. Thank you for participating in the discussion.
I strongly disagree (though I have not watched the video, maybe it explains when you should do logging). I have seen several applications where logging was the bottleneck. Especially if you turn on logging of frameworks such as Hibernate.
Of course, logging is important for development and production, but you should be aware when and what to log.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Cool idea of not using a container.
by Sai Matam,
Your message is awaiting moderation. Thank you for participating in the discussion.
Erik's practice of not using a container and using embedded Jetty seems radical at first. This scaled very well for Erik. I also liked Erik's idea of keeping things simple and not to be intimidated by 'existing lore'.
Sai Matam
Codewalk.com