Blog

This is Part 1 of a three-part series designed to extrapolate on the concept of Continuous Delivery in the context of DevOps, the process flow and tools involved, and a suggestion for implementing these processes.

What’s all this DevOps stuff?

Over the last year or two, organizations with strong development teams have undergone something of a revolution. It really began in 2001 with the Agile Manifesto signalling the end of the waterfall methodology in software development, in favor of Agile tools and processes. These tools (Scrums, sprints, etc) have set the stage for what is turning out to be the ‘third renaissance’ in software development. “DevOps” – the merging of Development and Operations – viewing the entire delivery cycle of software as a single process, rather than the walled silos of old – is the stage for this new approach to application deployment: Continuous Delivery. (Read up for more understanding of Continuous Delivery vs. Continuous Deployment)

A New Approach to Application Deployment: Continuous Delivery

Enough with the buzzwords and lofty history chat. Lets get into the meat and potatoes.

Continuous Delivery is an extension of the DevOps approach to managing the software development, build, testing, and deployment process. The first phase of Continuous Delivery, Continuous Integration, has now become commonplace in many organizations. Continuous Integration allows for hot-builds of applications immediately after check-in and compilation of existing code. If the code compiles cleanly and gets the green light, it is automatically deployed onto a Continuous Integration server and is available for immediate testing; however, we have seen that most firms are still incapable of automating their deployment processes.

This has been a huge boon to the software industry. Code that is actively being developed may be viewed and tested by people not intimately involved in the development process, without any user intervention. The application appears on the CI servers within minutes of a check-in by the developer (assuming nothing broke), giving visibility into a project outside the local coterie of coders.

How does Continuous Integration extend into Continuous Delivery?

Taking this concept further, Continuous Delivery takes CI and extends it beyond just CI servers, allowing for deployment of code all the way up the service chain. Not only can code be hot deployed to CI servers, but the same code should be deployable to all test environments (QA, Testing, and Staging), and, with basic checks in place, right to Production. With a properly built environment, the same code that comes out of the CI server can be deployed all the way up the chain, without any changes to the built package.

So why do this?

The goal of Continuous Delivery is not just making updates to the environments automated. That part is easy, and has been implemented many times before using automated deployment tools like Puppet and Chef. The difference here is that Continuous Delivery takes a much more holistic approach to the problem, and looks at it in the following way:

All environments should be as similar as possible; the same packaged code should be able to be deployed on any server, in any environment, without requiring customization or manual intervention.

I’ve heard that before – isn’t it too hard?

Not really!

Java applications in particular have this capability intrinsically. Applications are bundled into an easy to deploy package (JAR, WAR, EAR, etc), and the containers are by default set to accept this file as the entire application, and manage it appropriately. Generally the issues are not with the deployment methodology, but with the application itself. We’ll go into some of the pitfalls of implementing a Continuous Delivery strategy in Part 2 of this series.

There’s a great phrase you find in a lot of Continuous Deployment resources:

“If it’s hard to do, do it more often.”

Think about this for a few minutes. If there’s a rough spot in the deployment chain, does it make sense to avoid it and leave it there, like a speedbump on the autobahn? No! Focus in on it, keep going over it and smooth it out until it’s no longer an obstacle!

What benefits does Continuous Delivery bring?

The primary goal in any Continuous Delivery solution is to streamline the delivery pipeline from the developers desktops all the way out to production. With automation, proper testing, and clean configurations, the average Continuous Delivery implementation can speed up the delivery process by two orders of magnitude. Whereas before, the delivery lifecycle might be 6 months, (180+ days), a stable and well-established system can allow for software updates to drop down to a few weeks, or a few days. Removing the stress and worry about deployment into production allows for faster updates, more often, with less downtime and happier end users.

What kind of impact can I expect on our organization?

Probably the most concrete example of a successful implementation is by looking at the ‘turnaround’ time from when a bug or feature is requested on the production side of the environment, and when that bug or feature is implemented.

In a standard (ie ‘waterfall’) environment, the bug would be noted in the production environment. It would be slated for the next release of the product, and resources would be assigned to fix it. Once that cycle was complete, the product would ‘waterfall’ through QA, Testing, and Deployment, and the fix would go live with the next release.

In many organizations, this process could take months. With a fully implemented Continuous Delivery process, this could take days, if not hours.

That’s the win.

Snap! Ok, how do I get there?

Continuous Delivery requires some specialized tools and thought about how your products are packaged and distributed. In Part 2 of this series, we’ll take a look at some of the tools that are available, and look at how to start preparing your existing environment to better adopt Continuous Delivery concepts.

“GeekOut is the coolest and most laid-back event in the Baltics for me so far. It was One day, One track, One crowd in 2011. Highly interested coders, great medieval setting in Tallinn and the great care of the ZeroTurnaround conference crew make this one of the best kept conference secrets in Europe.”

- Peter Neubauer, Neoj4, speaker from the first ever Java Developers Conference in Estonia.

What’s happening at GeekOut 2012?

You better get ready for a tech-vacation in the capital of e-Country Tallinn, where startups grow on the trees and developers are productive (thanks to JRebel). Ed Burns, Kirk Pepperdine, Jaroslav Tulach, Matthew McCullough and more speakers are there for your benefit, helping you get new angles and views. Not to mention having some time to discuss that with your team-mates, other devs around Europe.

We had developers from over 30 Estonian companies+some Finnish. We had Peter Neubauer, John Davies, Martijn Verburg, Joonas Lehtinen and Alex Snaps as the speakers and over 130 developers attending. I bet they all remember a full day tech-talk topped with beer and pizza? Having a successful conference and receiving feedback that the event should be larger this time, we set the date for June 14th – 15th in 2012 and can list over 10 Java experts from around the World to come to little e-Estonia. It is an ambitious plan, that you can be part of in fulfilling by attending the conference.

Six reasons to come if you are a developer:

• 12 talks to attend a choose from during two days;
• Highly technical talks to learn best practices;
• Get inspiration at evening party&networking by meeting speakers, other developers over a beer and discuss how you can improve your work;
• Get time off to discuss work in light of new ideas with your own team;
• Cloudbees, Vaadin, Odnoklassniki.ru and more to come to show off their tools and projects;
• You can make it into a small vacation, exploring the beautiful Tallinn over the weekend.

Four reasons you can tell your Team Lead or HR Specialist to send you to GeekOut:

• The conference will increase developers motivation and productivity;
• Developers can learn best practices and get ideas;
• A chance for your team to take time and talk to other team members, field experts and – colleagues getting ideas how they can improve their work, what they are doing wrong and what else could be done to add value;
• Estonia is a close by and reasonably priced country so you can send more developers to get trained then with a regular conference.

Don’t miss out the GeekOut 2012!

It would not be hard to imagine, at this point, that President Toomas Ilves of Estonia has a soft spot in his heart for ZeroTurnaround.

For the second time in 6 months, we’ve been privileged to receive the Estonian President in ZeroTurnaround offices. This time, he visited our Boston office. Back in November, shortly before we were recognized as the #1 company in Estonia to watch in 2012, President Ilves visited ZeroTurnaround’s headquarters in Tartu, Estonia.

Find President Ilves...(hint: look for the bowtie)

President Ilves is keenly interested in a hands-on approach towards the proliferation of Estonian-headquartered companies around the world, some of which are located in Boston and other cities in the USA. And for good reason: he is a key driver of e-Estonia, the term coined to describe Estonia’s “incredible success story that grew out of a partnership between a forward-thinking government, a pro-active ICT sector and a switched-on, tech-savvy population.”

President Toomas Ilves and ZeroTurnaround's newly-appointed President and COO Alex Laats

From the ZeroTurnaround team, thanks for your support and we look forward to your next visit, Mr. President!

While not everyone is interested in spending nights writing company blog posts and releases, there is quite a collection of creatives on the team.

When I started at ZeroTurnaround in September 2010, I was employee #10. The team has grown to nearly 50 people today (250% increase in team size in 2011), and it’s strange to see this little startup blossom from a single office in Tartu, Estonia to a multinational company with offices in Boston, Tallinn, Tartu and Prague. The President of Estonia has visited our company twice in the last 12 months.

Some write technical posts, others run a photo blog and yet others contribute long-winded rants about seemingly random subjects (ehem….me). So without further ado, here are the folks at ZeroTurnaround who maintain their presence in the blogosphere…

Disclaimer: Perhaps unintentionally, I imagine this post will encourage the writers below to blog more frequently, since postings seem to have died off for most of us around early March :-/

Jevgeni Kabanov (CEO/Founder) and Toomas Römer (Director of Engineering/Founder)

http://dow.ngra.de

Hi there, Jevgeni and Tom here, the two company founders, Java hackers extraordinaire and creators of JRebel. We write here about all kinds of different technology topics that are not suited for the company blog. From PHP to Java, from Windows to Plan 9, from Batman to Dr. Manhattan. It’s been a little while since we last posted, but what do you expect? We’re busy! ;-)

Anton Arhipov (JRebel Product Lead)

Code Impossible: http://arhipov.blogspot.com

Hi there, this is Anton the JRebel Product Lead. My blog is probably most well known for my series last year called Java Bytecode Fundamentals, which received thousands of unique views. Even now, 40% of all the traffic actually lands on Part I of the post: http://arhipov.blogspot.com/2011/01/java-bytecode-fundamentals.html

I’m a pretty avid IntelliJ IDEA fan, and made several popular posts on “What’s cool in IntelliJ”:
http://arhipov.blogspot.com/2011/06/whats-cool-in-intellijidea-part-i.html
http://arhipov.blogspot.com/2011/07/whats-cool-in-intellijidea-part-ii-live.html
http://arhipov.blogspot.com/2011/08/whats-cool-in-intellijidea-part-iii.html
Usually I blog about some corner cases in Java, overviews of the conferences I attend, and some random cool tools I find useful. Sometimes I write about JRebel goodies too.

Anton Pelešev (Infrastructure Engineer)

http://www.beeta.ee

I blog on www.beeta.ee. It’s in Estonian.. for a reason: I want to write about tech stuff for dummies. The reason was that there is so many tech blags/news for geeks, not so many for dummies (especially in Estonian, naturally a well-known global language). I like to write about privacy and openness on the internets and easy stuff that non-tech folks could implement themselves. One of my co-writers is a passionate Android lover, so he writes about mobile topics. But we’ll write about whatever we find useful for ourselves and others. Why should people read it? That’s a tough one. Well, as I said, we are trying to reach out to the regular folks out there. Tech is not only for standard nerds.

Bogomil Shopov (Community Enchanter)

http://bogomil.info/

I’m proud to say that I’m one of the most popular and awarded bloggers in Bulgaria since 2004. My blog (http://bogomil.info/) has more than 1000 readers per day. I like writing about technologies, digital rights, citizen journalism and personal stuff.

Since 2009, I’ve been trying hard to write in another language on my blog about “Communities, open web and technologies” (talkweb.eu). My efforts of changing the web are noticed by Forbes (http://talkweb.eu/openweb/942) and Wikileaks (http://talkweb.eu/openweb/1098). It must be hereditary; even at age 4 my son also has a blog (http://bebekose.wordpress.com/) ;-)

Dave Shevett (LiveRebel Evangelist & Continuous Delivery Tech Advocate)

http://planet-geek.com/

I guess the subtitle of my blog says it best: From the dark depths of the unfathomable void come the otherworldly yammerings of a man out of society. Welcome to… Planet Geek!

I’ve been blogging here since early 2004 and cover a wide range of topics, from business yammerings to programming to reviews and politics.

Greg Kell (Business Development Representative)

http://gkell.tumblr.com

I started this blog after I got a Minolta XG-M 35mm camera out of my parents attic and started carrying it around with me when riding my bike, going on trips etc. It being a film camera, the learning curve was longer than having the luxury of taking as many photos as I wanted with a digital, but the process was a lot of fun. I have since moved to using a digital camera, but still love using film. This blog was created to share some of my photos with family and relatives.

Oliver White (Marketing Manager)

http://cellardoorpress.blogspot.com

I started blogging in 2006 but my own rantings began to disgust me a bit, so I stopped when I began writing occassional content for Prague TV, an English language portal for Praguers to get around and find out stuff. Suddenly, as if an Xmas gift to myself, I registered a new blog at the beginning of this year and somehow found the time to publish a handful of posts before work and travel got the better of me.

Cellar Door Press is simply a mouthpiece for my own meanderings and brain refuse, in which I write about music, whiskey, marriage, the American Dream and what to consider when staying in a 500-year-old hotel. It’s about as good as it sounds – seriously, don’t read it ;-)

Not like you would hear it from us first, but IntelliJ IDEA 11.1 was recently released and we’ve released a new plugin for JRebel to match it: http://plugins.intellij.net/plugin/?id=4441

Ok, why do I need a new JRebel plugin?

The new version of IntelliJ IDEA has incompatible changes in the debugger API (http://youtrack.jetbrains.com/issue/IDEA-81452). It’s important for us that we maintain support and development for the older versions of IDEA as well. Unfortunately, this means we need to fork the plugin and present a new 1.4.x version for IDEA 11.1+.

Do I get anything with the new plugin?

Yes, this presents us with a great opportunity: we can now use all of the newer APIs that we previously did not for compatibility reasons. We will still support and develop the plugin for versions 8 through 11.0.2, but it will be version locked at 1.3.x.

We understand the possibility for confusion, but there are many positives for this as well. We can stop working with older APIs that we only used to maintain backward compatibility, and start using all of the new APIs that allow us to provide a better experience for our users. For example, now you can use the new “fancy file” dialog system, which includes autocomplete. Word.

How do I upgrade to the new JRebel plugin?

You need to first uninstall the existing JRebel plugin, as IntelliJ will natively install over the old version and try to use the same plugins. This won’t work, and the JRebel plugin will be disabled. Either uninstall the JRebel plugin through the Settings->Plugins window or delete the plugin in the USER_HOME/.IntelliJIDEA11/config/plugins/jr-ide-idea directory.

Then install the plugin again through the Plugins window in Settings (http://zeroturnaround.com/intellij-idea-jrebel-tutorial-formerly-javarebel/).

What if I want to keep using an older version of IntelliJ?

Even though the new IntelliJ version (11.1) installs on top of the previous one (11.0.x), you can still separate the configurations. Here’s how: copy the USER_HOME/.IntelliJIDEA11 directory to USER_HOME/.IntelliJIDEA111 directory. Now, you need to tell the new IntelliJ instance that it has to use the new location for the settings. This is done in INTELLIJ_HOME/bin/idea.properties file. The idea.properties file contains a number of parameters that point to the settings directory:

idea.config.path=${user.home}/.IntelliJIdea/config
idea.system.path=${user.home}/.IntelliJIdea/system
idea.plugins.path=${user.home}/.IntelliJIdea/config/plugins
idea.log.path=${user.home}/.IntelliJIdea/system/log

You just need to change it to this:

idea.config.path=${user.home}/.IntelliJIDEA111/config
idea.system.path=${user.home}/.IntelliJIDEA111/system
idea.plugins.path=${user.home}/.IntelliJIDEA111/config/plugins
idea.log.path=${user.home}/.IntelliJIDEA111/system/log

Now you will be able to keep 2 versions of IntelliJ with different set of plugins. This is a very specific case and hardly anyone would like to follow such a setup, but just in case, I wanted to let everyone to know that it is possible.

While it IS true that we don’t take home awards every day, this is in fact the 4th medal of honor that ZeroTurnaround has received in the last 9 months: since June of last year, we’ve taken home the JAX Innovation Award, the Duke’s Choice Award/Oracle Innovation Award and the Estonian Innovator of the Year Award.

ZeroTurnaround spent a few hard days talking with hundreds of people at EclipseCon, showing JRebel and LiveRebel demos to the point where we all lost our voices. By the time the award ceremony was upon us, my mind had unraveled to the point where I literally took our booth placard down, carved it up with a box cutter and wore it as a sandwich board (see below):

(From left: Sang Shin (JRebel Evangelist), Oliver White (me, Markitect), Dave Shevett (LiveRebel Evangelist) and Ian Skerret (Director of Marketing at Eclipse)

I suppose the effect speaks for itself :-)

Thanks to all EclipseCon folks who believe that there is another way to work with Java – with instant application hotpatching and no user sessions interrupted using LiveRebel. Download LiveRebel free for 30 days, and bring Continuous Delivery in to your deployment process.

ZeroTurnaround is proud to announce Frostbyte, a new stack-based language for the JVM. The language was born out of frustration of working with the standard Java software stack and tools. Hopefully this language will be the long awaited answer to the myriad of JVM languages that have hit the streets in the past couple of years. With some confidence, we believe that Frostbyte will solve both social and engineering problems that software developers have to deal with.

A key innovation in Frostbyte as a stack-based language is the use of inverse reverse Polish notation with parentheses. Instead of first putting things on the stack and then executing an instruction on it, we let you write it the other way around, which feels more natural.

Frostbyte code maps very closely to Java bytecode, and any overhead in code becomes blatantly obvious. Instead of adding in the whole kitchen sink, we chose to cherry-pick the features that make the language both easy and simple yet powerful enough to replace Java in most if not all applications.

Examples

Let’s look at a basic hello world example:

fun main :=
  (call echo „Hello World!“)

Frostbyte lets you define chunks of bytecode that are always inlined when called. For example, the standard library defines echo as a chunk:

chunk echo :=
  (with System (with (get out) (call println ...)))

And the expanded form of the hello world is:

fun main :=
  (with System (with (get out) (call println „Hello World!“)))

Instead of Strings, Frostbyte has Ropes as the main text type, but Ropes are implicitly converted to Strings, e.g. when interfacing with existing Java code.

fun main (args: Rope[]) :=
  (echo (with „Hello, “ (call concat (args head))))

If the above is saved in a file hello.fb, you can run it with the fb command.

> fb hello Jim
Hello, Jim

The Frostbyte language is fully internationalizable. In fact, the built-in default language is Estonian, but language is detected from each source file. Other languages are provided as simple translation files — English (British) and Russian are included by default. For example:

Köis=Rope
esik=main
kaja=echo
võttes=with
kutsu=call
jätka=concat
head=pea

The Estonian translation of hello.fb would be:

fun esik(argumendid: Köis[]) :=
  (kaja (võttes „Hello, “ (kutsu jätka (võttes argumendid (kutsu pea)))))

You can also provide translation maps for your own code — the translations are stored as annotations in .class files. The Frostbyte IDE (coming soon) has knowledge of these translations and will suggest code completions based on your selected language.

Of course, no language introduction is complete without the Fibonacci example. There are several ways to do it. While if statement + recursion is one way, we are trying to deprecate the if statement, since it’s really just a degenerate form of pattern matching. One way to do pattern matching in Frostbyte is to describe the patterns in function arguments and provide a separate function body for each case.

fun fib (0) := 0
fib (1) := 1
fib (n) := + (call fib (- n 1)) (call fib (- n 2))

As you can see, operators like + and * don’t need the call keyword. You can also create your own operators by using the op keyword instead of fun.

Pattern matches can also appear as expressions in function bodies. Here’s an example in Estonian. We’ll also introduce code blocks, loops/closures and let (olgu) keyword.

// get current time as Aeg (Time) type
amps praegu: Aeg := pööra (võttes System (kutsu currentTimeMillis)) Aeg
 
// Funktsioon, mis leiab raamatukogust laenutatud raamatud, mille tagastamisega on hilinetud või mis on rikutud
fun leiaHilinenudRaamatud := (
 olgu raamatud := võttes Andmebaas (kutsu leiaLaenutatudRaamatud);
 võttes raamatud (kutsu koonda ( raamat ->
   ons? (< (võta tähtaeg) (kutsu praegu)) ->
     (uus Hilinemine raamat)
   ons? (võta rikutud?) ->
     (uus Rikkumine raamat)
 ))
)

For those few who don’t speak Estonian, a translation is in order:

amps=chunk
praegu=now
Aeg=Time
pööra=convert
olgu=let
koonda=collect (filter + map)
ons?=case (introduce a pattern)
uus=new
raamatud=books
raamat=book
tähtaeg=due date
etc.

Complex Example

Let’s look at a bit more complex example that introduces classes as well.

class Vector2(x: Double, y: Double) :=
 // dot product
 op ‌·(that: Vector2) :=
   + (* (get this x) (get that x)) (* (get this y) (get that y))

We can write (get this x) as a shorthand for (with this (get x)). But we can also use the with keyword to shorten the field accesses:

op ‌·(that: Vector2) :=
  (with this (
    + (* (get x) (get that x)) (* (get y) (get that y))
  ))

But even better, if we write with X or Y, then a tuple of X and Y is put on the stack, and any access to their fields or methods will alternate between X and Y.

op ·(that: Vector2) :=
 (with this or that (
   + (* (get x) (get x)) (* (get y) (get y))
 ))

We can then see some repeating patterns here and can reduce it down further

(with this or that (
   + (* dup (get x)) (* dup (get y))
 ))

dup will duplicate the next bytecode instructions, but combined with this or that means the first (get x) will be (in Java-speak) this.x and the next (get x) will be that.x . How cool is that.

Bytecode

I bet you are curious about the kind of bytecode generated by Frostbyte. Lets look at the expanded hello world again.

fun main := (with System (with (get out) (call println „Hello World!“)))

javap gives us this:

  0:   getstatic       #16; //Field java/lang/System.out:Ljava/io/PrintStream;
  3:   ldc             #22; //String Hello World!
  5:   invokevirtual   #24; //Method java/io/PrintStream.println:(Ljava/lang/String;)
  8:   return

So the translation is quite straightforward: with System (get out) in this case translates to getstatic, then “Hello World!” to ldc, and call to invokevirtual. call always translates to either invokestatic, invokevirtual or invokespecial, except when it’s used to expand a chunk, in which case it gets replaced with the chunk and any arguments are inserted into the bitemarks (e.g. in the echo chunk, … is a bitemark).

chunk echo := (with System.out (call println ...))

Frostbyte 1.0 Roadmap

The language is still in development, but we are getting close to the first public Beta release. For 1.0, we have some more awesome things planned:

• First class co-monads
• Kabanov-Raudjärv type inference
• Lazy chunks
• goto statement with labels
• Dynamorphisms

While we are still working towards the first publicly available version, here are some links for you to familiarize yourself with the language to be ready for the big release.

• Frostbyte 1.0 Language Specification
• Documentation, Tutorials and Examples
• API reference

Into the Future

We think Frostbyte will make a real change to the way software is developed. ZeroTurnaround is confident that it will become the next Java and will solve most of the problems that plague developers around the world, such as difficulties dealing with concurrency, parallelism, and the CPU-memory gap.

The Frostbyte 2.0 compiler will have built-in AI that is able to make aesthetic judgments about your code and will outright disallow ugly code, over-abstractions and excessive copy-and-pasting *.

To enable the latter, the AI will have a connection to a centralized data cloud and will be able to compare your code to everyone else’s. It will automatically find copyright and patent infringements and end the software patent wars forever. The AI will utilize automated crowd sourcing to some extent and you can also play your part in improving everyone’s code!

Exciting times are ahead and we are glad to take part in inventing the future!

* we know some people want more freedom, and are working on ways to lift some of these constraints for commercial Frostbyte subscriptions.

Google Web Toolkit (GWT) is a Java framework for writing web applications that lets you stop worrying about writing HTML and Javascript and how your application looks, or even works, in different web browsers. The client-side code produced by the GWT compiler is very robust and optimized for performance. Even thought GWT feels very productive, you can still use JRebel to enhance your productivity even more. In this post, we will look at some GWT features and what JRebel can do to support this cool framework.

Short intro to GWT and JRebel

When you run a GWT application it is divided into two parts: Server side and Browser side. On the server side, there is a normal JVM with Java code, but on the browser side there can be HTML/Javascript in production or Java code in development. The first one is called “production mode” and the second one is “development mode” (go figure!) and we will focus on the development mode. In development mode your entire application is in Java byte code and thus all the Java specific features are available; for example, you can debug client-side code with a Java debugger or even reload client-side code changes with JRebel

JRebel for GWT is available in development mode, and if you have installed JRebel then the support for GWT is enabled by default. We don’t support production mode because compiling JS from Java is terribly slow, especially if deferred binding is in use via GWT.create.

GWT-s server side with JRebel

In the server side of a GWT application, you run a normal Java server. This means that when you make a change to the Java code in there, then you must redeploy your application in order to see it, which can take 30 seconds to 10 minutes depending on your app size and tech. On the server side of GWT, there is no easy way to update code quickly like you can achieve by refreshing on the browser side. This is where JRebel comes in to truly save time, money and developer lives ;-) In server side the benefits from JRebel functionality is clear: you eliminate the redeploys in there just by using JRebel.

GWT-s browser side with JRebel

GWT-s browser side looks much more interesting than the server side. Each time you open a new browser window (or refresh an old one) a new GWT session is made for you by the GWT browser plugin. In Java code, this means there will be new ClassLoader and resource cache just for your session. So because every new session gets its own ClassLoader and resource cache, you can see changes to your Java code just by refreshing the browser. It’s fun and comfortable.

Of course GWT is pretty smart, so everything must not be regenerated on every new session. So why would we need JRebel on the browser side of GWT?

The benefits of JRebel on the browser side are not that as evident as they are on the server side but they are there – with JRebel you still maintain current application state if you reload your client side code, and you don’t have to refresh your browser.

What about JSNI methods?

Our customers and users will be happy to hear that we’ve recently updated our JRebel-GWT plugin, which has now implemented the reloading of the JSNI parts of the changed class as well (it didn’t before).

For users that don’t know what JSNI methods are, here is a little bit about JSNI. One of the coolest features of GWT is the Java-to-Javascript compilation in production mode. As everything will be Javascript anyway, GWT allows you to write direct Javascript methods in your code, called JSNI methods.

But when we look at JSNI methods in development mode we will encounter a small problem, namely that we must be able to run the direct Javascript code also in development mode. To achieve that GWT has a system inside CompilingClassLoader that extracts the JSNI methods from the Java class source code and remembers it when the class is loaded for the first time. The old version of our JRebel plugin did not support those methods, so in the new plugin we built support for re-extracting the JSNI methods and making them available again when the class itself is reloaded.

GWT class generation

Another big part of GWT is class generation. GWT has a lot of browser-side resource files from which it generates different Java classes. There are for example i18n files and ui.xml files that generate different Java code. In a running application this is probably a big performance win, but for a development time class update this is a nightmare. Luckily, JRebel can update even those files in run-time with a simple browser refresh, so there you go.

Let’s take a look at GWTs support for i18n. In GWT, when you make your message classes and put some text references in them and make some properties files with the text in them, then on the first request those files with contents from properties files are compiled into new Java classes.

The problem with this generation is that first all the properties files are basically made into a big list, and then i18n-ed files will take their labels from any one of the files. Now, when any one of the source properties files is changed then JRebel must regenerate all of the i18n-ed files because GWT does so in the initialization and there’s no way to find out which generated file the new text is meant to go.

One solution would be for JRebel to generate different i18n files in development mode, so that the i18n content comes from a map instead of directly compiled file. So we could just update the changed text to a map and then the files would automatically get the new content.

Another possibility for JRebel would be to do a more intelligent tracking for properties sources to Java sources but this would take to much more time and memory.

So we decided just to regenerate everything because this has the smallest possibility to break something. :-)

Conclusion

GWT is a very innovative tool for writing web applications, but any developer who uses GWT can certainly benefit from JRebel, both on the server side (instant class reloading in the running app), and also on the browser side (no need to refresh because JRebel can reload the classes and even regenerate GWT-s generated classes).

The goal of using JRebel with GWT is to eliminate server restart/browser refresh when you change some parts of the code. That includes Java code (of course) and also JSNI functions, all sorts of generated classes (i18n, templates etc). If there are any classes that JRebel does not regenerate yet, please let us know – we’d be happy to improve GWT support in JRebel!

If you have any comments, please leave them below or let me know at andres.luuk@zeroturnaround.com

In Scala: Sink or Swim Part 1 and Part 2, we looked at the challenges of Scala complexity from the perspective of a newcomer (especially coming from the Java world). In this post, I’ll give my thoughts on what is so great about Scala in the first place that Java developers should consider using it. A detailed account would take more than one blog post, but I’ll try to give a brief overview with links to relevant reading. Again, this post is mostly meant for Java developers that potentially want to try Scala.

To put it briefly, I think there’s a subset of Scala features that form a relatively simple language that is still quite powerful. I don’t pretend to be an authority on this — and maybe your subset is a bit different from mine (leave comments!). Certainly I’ve left out some useful features here, but I think most of the important ones are covered.

The allure of Scala if you are mostly writing Java now is probably this:

• More intentional code — i.e. You can get rid of most of the boilerplate stuff
• DRYer code — repeat yourself less
• No need to write types in every declaration — they are inferred (mostly)
• More abstractions — less copy & paste
• More concise code
• I think it’s safe to say 2-3 times less lines of code than equivalent Java. Occasionally the difference can be even bigger (or smaller).
• Immutability is easier
• Use val (or lazy val) by default instead of var and you might be surprised how seldom you really need mutability
• Slightly more functional code
• Scala blends functional and object-oriented programming, so you can start making your code more functional without radically changing your current programming style
• Functional abstractions over collections
• forget for-loops — with lambdas, many collection transformations are one-liners
• New ways to compose things
• traits enable some compositions that are impossible in Java
• Pattern matching
• a huge improvement over if-else chains or switch statements when you don’t want to use polymorphism just to choose between alternatives (which could be most of the time!)
• Java interoperability
• something that creates more corner cases and complexity in Scala, but also a blessing as your code can easily interact with existing Java code

Everything above pretty much sums up why I enjoy Scala, so if you’d like to stop reading here, I’ll understand ;-) The reasons for these inevitably vary from person to person, so like I said earlier, please feel free to leave a comment if you think there’s something I should have mentioned. It’s also worth mentioning that Scala code can perform as well as Java code. Some abstractions do have their overhead, though.

Scala features that should make you jump for joy

Above, I wrote down some of the aspects of Scala that I really enjoy, so now let’s look at some of the language features that enable these. The list is not comprehensive, and I will hint at some more features below, but IMHO the main ones are:

1. Algebraic data types (case classes)
2. Pattern matching
3. Traits
4. Adding methods to existing classes
5. Syntax
6. No Primitives
7. Anonymous and higher-order functions

1. Case classes (a.k.a. algebraic data types)

It’s amazing how easily you can write small classes for holding data in Scala. Even if you don’t use getters and setters in Java, a public data class is still so much code: it usually needs its own file with imports; equals, hashCode, toString implementations and so on. In Scala, if you need a small data class you can often add it to an existing .scala file and just describe the field names and types:

case class Person(firstName: String, lastName: String, age: Int)

Case classes like this are immutable by default, like most data classes should be. equals, hashCode and toString are based on the combination of the fields. The compiler will even add a copy method, which uses current values as default arguments. For example, on my birthday, I could execute this code:

val newMe = me.copy(age = me.age + 1)

Think this is cool? Read more about case classes.

2. Pattern matching

Case classes also interact quite well with pattern matching, which is like a more generalized switch statement. Given our Person class above, we could do some matching on different persons like this:

val aPerson: Person = // find a person
val canDo = aPerson match {
  case Person("Chuck", "Norris", _) =>
    // here we only care about Chuck Norris, and not his age -- Chuck Norris is ageless.
    // Underscore in Scala usually means “wildcard” or “we don’t care about it”
    true
  case Person(_, _, age) if (age >= 18) =>
    // matches only adults who are not Chuck Norris
    true
  case _ =>
    // matches anything else. this is like the default case in Java’s switch
    // if you leave it out you will get a MatchError for a non-matching object
    false
}

A pattern match, like most control structures in Scala, but unlike those in Java, is also an expression — it can compute a value, which in our case is a Boolean that is true for Chuck Norris and adults, but false for everyone else. Only one of the cases is executed, there is no fall through and there are no break instructions needed.

Pattern matching can also be a good replacement for the Visitor pattern. Read more about pattern matching.

3. Traits

Traits can be used exactly like interfaces in Java, but they can also contain implementation code. If you have a complex type hierarchy, they make it easy to mix several aspects of the implementation from separate traits into concrete classes.

For example, let’s introduce an Ordered trait that defines < and > methods for comparing objects. Implementations must only implement a compareTo method.

trait Ordered[T] {
  def compareTo(other: T): Int // abstract method, returns 0, negative or positive
  def >(other: T) = (this compareTo other) > 0
  def <(other: T) = (this compareTo other) < 0
}
 
// we can mix Ordered into an existing class, implement compareTo and get < and > for free!
val ChuckNorris = new Person("Chuck", "Norris", 0) with Ordered[Person] {
  def compareTo(other: Person) = 1 // Chuck Norris is always greater than another person
}
 
ChuckNorris > Person("John", "Doe", 22) == true

Of course, this small example isn’t perfect as it only gives us ChuckNorris > person but not person < ChuckNorris. To get both, we’d change the Person class:

case class Person(/*...*/) extends Ordered[Person] {
  def compareTo(other: Person) = /* implement ordering for all persons */
}

Read more about traits.

4. Adding methods to existing classes

You can, in a way, add methods to existing classes without changing their source code. This is useful for various things, and is achieved by implicitly converting an object of one class to an object of a wrapper class. The methods are defined on the wrapper.

For example, if we wanted to add a method that says whether a person is minor or an adult, we could do this:

class PersonWrapper(p: Person) {
  def minor = p.age < 18
  def adult = !minor
}
implicit def personWrapper(p: Person) = new PersonWrapper(p)
 
Person("John", "Smith", 43).adult == true

Personally, I don’t like that “extension methods” are implemented this way, because implicit conversions hold some dangers and are easy to abuse, so you just have to remember to use them responsibly. Read about some hints here.

5. Syntax

You’ve seen some of the syntax in the examples above. It might seem odd at first, with the types coming after names in declarations, but it is quite good once you get used to that change. It’s a nice concise syntax and def compareTo(other: T): Int is more readable than public int compareTo(T other), IMHO. As we saw above, one-liner methods are much nicer than Java equivalents, and infix method calls let us drop the dots and parentheses where we want to (ChuckNorris > person is equivalent to ChuckNorris.>(person)).

Generally, I’d say the syntax lets you do more with less, compared to Java.

6. No Primitives

Scala hides the JVM primitive types from you. Everything is an object, everything can have methods. The compiler will still decide to use primitives where it can, and boxes values where it can’t, but all you see are objects. For example, the Scala library adds a to method to Int, such that 1 to 100 produces a Range you can iterate over:

for (i <- 1 to 100) {
  // do something a 100 times
}

7. Anonymous and higher-order functions

These barely need a mention. No modern language should exclude anonymous or higher-order functions, and even Java will get them soon. They allow easier parallelization, creating custom control structures and concise code for dealing with collections, among other things.

For example, lets say we often need to do something with all the adults in a collection of Persons. We could create a higher-order method that allows mimicking control structure syntax:

def foreachAdultIn(persons: Iterable[Person])(thunk: Person => Unit) =
  persons filter { p => p.adult } foreach { p => thunk(p) }
 
// now we can write
foreachAdultIn(listOfPersons) { person =>
  // do something with person
}

Conclusion

Generally speaking, the benefits of Scala have the potential to outweigh the disadvantages, if you know which side of the pool you’re diving in to….you don’t want to hit your head on the bottom after the first jump!

I believe that the main Scala features listed above are already enough to let you write more concise and intentional code than in Java, but getting there is more challenging. For several years, I’ve written all of my hobby code in Scala, and there’s even a bit of Scala code in production at ZT (nothing mission critical, though). But I’ve only occasionally dived into the deeper parts of the Scala swimming pool. They are sometimes fun to explore, but can be scary at first. Even with just the features above and perhaps a bit more, Scala is still my favourite language.

If you or your team of Java developers are considering adopting Scala as an alternative JVM language, let me know about it and maybe I can send you some more pointers – calls are $2.99 per minute ;-) This subset of Scala outlined in this article series might be already enough to make it a compelling choice. You will still enjoy a lot of the power of the language with just these features, and once you are comfortable with that part, you can consider some advanced Scala features and going further in the pure functional direction.

Thanks for your time, and have a productive day!

Want to reach me? Leave your comments below, ping me at erkki@zeroturnaround.com or tweet to @t4ffer

Disclaimer: According to British scientists, the author is descended from apes.

In Part 1 of Scala: Sink or Swim? we looked at some things you should ignore in the Scala ecosystem when you are starting to adopt Scala. I think it was important getting that out of the way first — if you discover these things as you’re learning, thinking that’s idiomatic Scala, they might scare you off, and you would be missing out, in my opinion.

In this post we’ll look at some more things that are not quite perfect in Scala land, but that you must simply live with, at least for now. Finally, in Part 3 of this series, we’ll peek at some language features that form a simpler subset of Scala, but still make learning and using Scala worthwhile.

Things you must live with

Any language has some annoying warts — you just learn to live with them. I think it’s a good rule of thumb to avoid the things mentioned in the previous posts at least initially, and decide whether you want to use them after becoming comfortable with the language. Or maybe you already are on good terms with some of them — I’m not trying to change your mind about that. If not though, keep in mind that these things are also part of the Scala community in it’s diversity, and ignoring them completely might not work as well when you find that, for example, some of the Scala answers on StackOverflow or on the mailing lists are of the opposite mindset.

But you should totally be able to coexist with the “deep end” of Scala and still write good code that is not too foreign even to Java developers. There are many libraries in Java that I can’t stand or that are internally divided into so many layers of abstraction that they are extremely hard to debug or understand, but that doesn’t take away from the value of Java itself.

The same is true for Scala, but as a newer and less popular language than Java, there just isn’t a comparable number of libraries that are really solid.

Comparatively, Scala is still in the early days where Java would’ve had EJB 2 and Struts 1 as the pinnacle of web development. The language is still that young, but perhaps this comparison isn’t quite right — I don’t think Scala ever really had as big of a blunder as EJB 2, and web development with Scala is not necessarily behind or ahead of web development with Java.

But there’s still a lot of exploration and mapping of the territory going on. In the Java world, most people would not blame the Java language for EJB 2. They would just stay clear of that single part of it. But with Scala, some folks are quick to blame the language or the community and ecosystem as a whole for any particular misgivings.

And the Java world still hasn’t reached a consensus on the eternal question: which web framework to use? And it never will, because no single framework is particularly amazing, for one reason or another. Different variables weigh into that choice each time.

So, I’ve done my best to narrow down the main unavoidable issues into 4 areas:

1. Binary Compatibility
2. A good IDE is pretty much a requirement for understanding some code
3. Compiler speed in conjunction with IDE use patterns can slow you down
4. Scala is still evolving and getting new experimental features

1. Binary compatibility

This is perhaps the biggest issue with Scala. Libraries compiled with one version will not necessarily work with the next or previous versions, so they need to be recompiled with each version upgrade. SBT can do this (compile against multiple Scala versions), and I think that has been one of the main contributors to its relative popularity.

If some libraries don’t recompile, they will hold back users from moving to newer Scala versions, or alternatively force users to use source dependencies or even resort to forking. But things have been getting better even on the binary compatibility front.

2. Need an IDE to understand some code

Some would likely disagree, but I think you definitely need an IDE for developing Scala code, and maybe even more so for reading code written by others. It is not as easy as in Java to immediately see what a particular line of code does, due to more constructs being available (such as implicit conversions and type inference). An IDE that lets you jump to declarations and shows types when you hover over something with an inferred type is essential in understanding some Scala code.

Thankfully, the Scala IDE for Eclipse is quite good since version 2.0, and I hear the IDEA plug-in might be even better.

3. Compiler speed

This is the largest issue that remains with tooling IMHO — when you have a project with thousands of lines of code and use Build Automatically in Eclipse, you might end up in situations where changing a single line + saving will result in half a minute of waiting. Compiler speed is also something that is being worked on.

4. Scala is still evolving

New features will be added to next versions of the language, potentially including value classes (yay!), control structure syntax improvements and even compile time meta-programming. This can seem kind of scary, especially the last bit, which is also known as… oh man, I don’t even want to say that word (macros). In reality, that change will likely be optionally enabled and not exposed to most users.

Plus, there already are a many features in the language that you shouldn’t use without good cause, as mentioned earlier. Josh Suereth pointed out some more in a comment to a previous post, such as vals/vars in traits (due to issues with initialization order). I just hope that library authors are not too eager to jump at the chance of experimenting with every new feature where they could do without. Of course, that doesn’t go for everything — some libraries may really benefit from these language evolutions.

There is even a new proposal for disabling some language features by default, which generated a huge comment thread on the mailing list. Seems that many expert users think it is too much of an inconvenience to have to enable those features everywhere they need them. I don’t have a particularly strong opinion on the matter, but I’m not totally against the idea that some devices for shooting yourself in the foot should have safety locks.

As a bonus, the best comment from that thread:

Don’t worry. Loops will be optimized in 2.10.
Cheers
- Martin

This is about the for loops vs. while loops issue I mentioned briefly in the last post. It will be great to see this being improved finally.

Update: some more developments on the mailing list. It seems the main reason for the proposal is a longer term direction for Scala that has the potential to unify some of the hairier features of the type system into a simpler set of rules.

Conclusion

There are some issues everyone in the community must live with when they use Scala. In my opinion, it is not too much, considering the power you are getting from the language.

I previously alluded to a division in the community (and my earlier post probably didn’t help it). Some people with functional programming background seem condescending at times, and probably think that the OO guys don’t care enough about writing better code. Many potential Scala programmers with OO backgrounds care about creating large code bases that are maintainable by any able team member or new hire for years to come. And until the functional side has proven to the wider community that programs written in the functional and more abstract way are as maintainable, their voice will not be taken too seriously by the larger group.

It’ll be interesting to see whether the functional/theoretical and OO/pragmatic side can achieve a more symbiotic co-existence and further bridge the functional / OO gap, or whether the groups will diverge even more. In any case, I think it helps if you know about this division when you start with Scala. Get comfortable with the basic language features, and then decide whether you and/or your team wants to keep avoiding the other side, or start expanding your horizons further.

Keeping in mind that I’m more of OO background, I think what the Scala community needs most at the moment to make Scala an even better Java alternative is to bring in more pragmatic programmers who would write solid libraries that don’t overuse symbols, avoid some of the more complex type system features, maybe even stay more imperative than functional (while still preferring immutability), and don’t go overboard with the type safety.

It doesn’t mean the more pure/functional/type-theoretical/experimental/research side of Scala should go away — they should all be able to co-exist in some kind of symbiosis.

I think this has been happening and will continue.

Look for more in Part 3…

In Scala: Sink or Swim? Part 3, I finally get the all the great things about Scala, and why I even started playing around with this interesting language in the first place.

Thanks for tuning in! If you have any questions, post them in comments or drop an email to erkki@zeroturnaround.com. In the next and final part we’ll take a brief look at the Scala features that are probably the reasons Java programmers should learn Scala in the first place. These form a subset of the language that is actually relatively simple, but still quite powerful.

« Newer Entries | Older Entries »