Entry 6, Day 10

The technology stack… We’ve talked a bit about tiered application composition, now let’s take a broader look. Software is basically composed of layers. That simplifies things. You have an operating system using hardware directly. Then, there is the Java runtime providing abstraction between Java bytecode and actual program execution. Then, if we are in the JEE realm, we have a server.

The kind of server depends on you needs. If you like EJBs, you need an application server (Weblogic, Glassfish or whatever). If you prefersomething lighter, you can go with web container (like Tomcat). Finally to help you serve static content like Java Script (which is static in terms of being executed on client machine, not ours), there are http servers like Apache. You can combine all of them – use application for EJB layer, web container for web layer and http for static. There might be, of course, many more servers in the application ecosystem, namely proxies, firewalls, load balancers (or it can be dedicated hardware, and usually is), but this is more of the infrastructure domain, not application.

Then there is some kind of framework providing abstraction over JEE api or just complementing it. Think Spring.

And, at the peek of the mountain, there is Java language. The language shapes architecture of your system, ties things together and allows you to play with stuff. I’ll go with Java 8 because well… cutting edge, you recall, do you?

Actually Java 8 is quite cool. Everyone says that’s because finally we have lambda expressions, but there is more. There is, for example, internal iteration.

Internal iteration, instead of imperatively iterate over collection, allows you to declare iteration and let the runtime do the rest. Why it is important, you may ask? Because if you iterate imperatively you do that either in sequential way, or you have to play with threads, think about number of available cores and do other tedious and error prone stuff. If you let the runtime iterate, on the other hand, it may perform e.g. a new forEach operation concurrently, using all available cores, and this is transparent for you. It makes things simple and fast.  Also, a new Stram api allow you to perform map, filter, reduce, and other operations with performance improved by doing what really must be done lazily. I haven’t yet explored all new features of Java 8, but things look promising.

<scary JVM internal stuff>

By the way, lambdas aren’t just syntactic sugar for inner classes as many people think. In fact, lambdas implementation in virtual machine uses additional layer of abstraction. Lambda is actually a recipe, not an imperative piece of bytecode. It’s true bytecode is generated on runtime, not compile time, using fifth invocation mode, invokedynamic, introduced in Java SE7 to support dynamic JVM languages (Groovy, Jython etc.). Lambda call site is created using so called “language logic” or “bootstrap method” that was to be provided by specific dynamic JVM language to help dispatch calls. In Java language lambdas execution, such logic is called Lambda Metafactory.

As a result of several nifty VM tricks, lambdas are much faster than inner classes, especially on multicore systems, and have a potential to be even faster in further versions of Java. If you are into this stuff, check out a cool presentation by Brian Goetz, the Java language architect.

</scary JVM internal stuff>

So, I’m going to use Java 8. And few other runtime technologies, which I will discuss in the next post.