The development of complex interactive web applications inherently requires you to store state in one location or another (on the server, on the client, in a database, …). Using JSF, the web session preserves the state of the container managed beans by taking your scope rules into account. Since this is conveniently tied to regular Java classes and their fields, it’s very easy to accidentally grow the session without really realizing just how large the memory footprint has become.
Product Updates, Company News & Fun
We’ve reached the end of this series. It’s been an interesting ride for me since even though I wrote down the ten reasons many months ago, each blog post made me discover interesting additional implications. Some that I never pondered on before and wasn’t really aware of until I sat down to write about it.
What are your thoughts on this series? Did I miss an important reason? Did I get something wrong? Is one of those reasons actually not great at all? Please reach out, even if it’s just to be the devil’s advocate. We’re planning to mold these blog posts into a report and contrasting views will make this into a much more interesting read. This is an ideal opportunity to be part of our unique RebelLabs reports and maybe even become a regular contributor!
The original premise of this blog post was to just talk about backwards compatibility, but it will actually fan out to forwards and sideways (is that a real term?) compatibility also. Interestingly, Java excels for all of these.
Before we start, here are my top 10 favorite things about the Java platform again…
We all know that writing code is the easiest part of application development. Tracking down problems, and especially those related to performance and concurrency, is what’s tricky. While I was always aware that the Java Virtual Machine provided great forensics tools, it was only when I worked with Python and C++ for three years that I was confronted with the sad reality outside of Java land. That reality is best summarized as: “You’re on your own dude, good luck!”
Since there’s really not much to compare the Java profiling tools to, in this blog post I’ll summarize a few observations about performance testing and why Java makes this as easy as it can get.
This blog entry in the series is going to be quite short, since there’s really not that much to say besides a statement of fact: Java IDEs are the most advanced in the world!
As a reminder here are my top 10 favorite things about the Java platform again:
- The Java Compiler
- The Core API
- The Java Memory Model
- High-Performance VM
- Intelligent IDEs
- Profiling Tools
- Backwards Compatibility
- Maturity With Innovation
What rocks about the Java virtual machine (JVM)?
That’s an easy one, isn’t it? Most people will tell you that the differentiator of Java is its cross-platform nature. Java offers write-once-run-anywhere, which is provided by the virtual machine. That’s not very unique though, a lot of languages and platforms have adopted virtual machines and Java wasn’t even the first. Smalltalk relied on a virtual machine a decade before Java was even invented!
So, what rocks about the Java virtual machine? In short, by now it’s the virtual machine. The JVM is the most complete of any application VM out there: it’s cross-platform, open-source, crazy fast, verifies the bytecode for safety, hosts both statically and dynamically typed languages, provides automatic memory management and it’s tunable at runtime.
The Raspberry PI and Leap Motion hands-on labs at Devoxx 2013 started with a packed room, we even had to fetch additional chairs for people standing in the back. Vinicius and Yara senger explained their super useful embedded devices panel where many sensors and boards can be accessed through easy REST URLs.
Parallelism is the current way towards increased computing power and concurrency has been entrenched in our applications for many years, even if it was just to have an event dispatch thread. To allow for a coherent memory view, processors include memory models where barriers can be used to ensure that writes are visible to other threads or processes.
This is not another Maven rant nor intended as a flame war–we could even think of this as an “anti-rant”, if you like. I didn’t even bother to see how many other dozens of blog posts on this subject have been written. But let’s face it, one of the most commonly ranted-against tools in the Java development industry is Maven. According to recent results in our 2012 Developer Productivity Report (check out our really popular 2013 version too), Maven is the #1 build tool used by developers.
So what is a build tool supposed to do? Basically, it should automate a bunch of processes that developers need to do regularly, removing some of the manual sting from compiling your source code, packaging and running tests on it, etc.
Let’s start by reviewing the top 5 things that a Build Tool should do really, really well…