Blog

The latest expert opinions, articles, and guides for the Java professional.

What is Lambda Calculus and should you care?

Introduction to λ-calculus

In this post we try to give a really short overview of what’s λ-calculus and why you might want to know about it. In parts two and three we will see a basic implementation in Scala. Lets start with a short description (quote from Wikipedia):

“Lambda calculus (also written as λ-calculus or called “the lambda calculus”) is a formal system in mathematical logic and computer science for expressing computation by way of variable binding and substitution. First formulated by Alonzo Church, lambda calculus found early successes in the area of computability theory, such as a negative answer to Hilbert’s Entscheidungsproblem.

Read more

The Adventurous Developer’s Guide to JVM Languages

Scala Programming: A Guide to Scala Adoption in Your Java Organization

20-Page Tech Report + 15 pages of Q/A w/ Scala founder Martin Odersky

INTRODUCTION

Scala is a language created by Martin Odersky and his desire to combine object-oriented and functional programming on the Java Virtual Machine. Odersky’s previous work on Pizza, GJ, Java generics, the javac compiler and Funnel eventually led to the creation of Scala and its first release in 2003 at EFPL. Scala is purely object-oriented as every value is an object, and functional as every function is a value. The successful mix of OOP and FP paradigms has made the language relatively popular and a “better Java” for many. It’s also a good language for those looking for Haskell-like capabilities on the JVM.

Following the language’s rise in popularity, Typesafe was founded in 2011 by the creators of Scala and the Akka middleware, to provide easy to use packaging of both in the form of the Typesafe Stack, as well as better development tools and commercial support.

In the last few years there has been some criticism of Scala; it’s mostly been accused of being too complex. In this report, we opine that the perceived complexity of Scala actually arises more from the diversity of the ecosystem rather than the language itself. We then look at a simpler subset of Scala that is perhaps a good place to start for Java teams who are considering adopting it in 2013 or later.

We also include an interview with Martin Odersky, creator of Scala, Chairman and Chief Architect at Typesafe and throughout the report we have comments from Josh Suereth, also from Typesafe, and author of Scala in Depth.

Read more

Frostbyte: The New JVM Language from ZeroTurnaround

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.
Read more

Scala: Sink or Swim? Part 3

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.

Read more

Scala: Sink or Swim? Part 2

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

Read more

Scala: Sink or Swim? Part 1

Disclaimer(s): ZeroTurnaround supports eliminating redeploys in Scala development with free JRebel licenses (more info). The author admits to having no Scala code in mission critical production, and would like to mention that he has lots of opinions about many things in which his expertise can be contested ;-)

Read more

JRebel vs OSGi: Use the right tool for the right job

Read more

Building Eclipse plug-ins with Maven 3 and Tycho

Automatically building Eclipse plug-ins has been sort of difficult for quite a while.

Running the build manually from PDE works, but it’s pretty much a black box and you can’t always get what you want from that. It can sign plug-ins when choosing Export… -> Deployable plug-ins…, but it can’t do this when building a whole update site. If you are used to Maven, Ant or another command line build tool, then things like this are truly annoying.

There are, of course, some tools provided by the Eclipse Foundation for headless building of plug-ins, but they don’t seem easy to set up or convenient to use. Tycho for Maven 3 aims to change that, making it possible to build OSGi bundles / Eclipse plug-ins in an environment familiar to most developers and with minimal additional configuration.

Background

Tycho still doesn’t have an 1.0 release, but seems pretty stable, if lacking a few features. It doesn’t yet have a lot of updated or detailed documentation, but I found help in blog posts about building with Tycho. Mattias Holmqvist’s posts, for example, are recommended reading.

The information I found was sometimes outdated, though, or didn’t go into the things that we needed to make a headless build for JRebel for Eclipse, which has had over 800 downloads in February alone and continues to climb the charts on the Eclipse Marketplace. I figured that since others may have similar needs to ours at ZeroTurnaround, it would be cool to share this experience with everyone (*note: this post assumes some experience with Maven and PDE).

First, I’ll describe what we needed from Tycho. JRebel for Eclipse consists of 6 Eclipse plug-ins, some of which depend on each other. One plug-in provides general JRebel/Eclipse integration, another embeds JRebel itself, and others provide debugger, WTP and RAD integration. We needed to be able to:

  • use existing meta-data (manifest-first model), so that we can still use PDE for development
  • build the whole set of plug-ins at once when doing a new JRebel release
  • sign all our plug-ins and features
  • build single plug-ins separately to release bug fixes quickly

It was actually quite easy to get the first three requirements met by a Tycho build, but it turned out the fourth one was harder to achieve (more on that later).

At first I just added a pom.xml file to each plug-in and feature, specifying the artifact name, version and packaging type for each. Tycho can even generate a basic pom.xml for you. A parent pom.xml was added to define some common Maven plug-in settings. I also created a new update site project, which only has the site.xml that says which versions of what features to add to the site.

Sample project: Achievements for Eclipse

To make things easier to demonstrate, let’s create a sample project that mimics the setup I used. And to make it more fun (or ridiculous, take your pick), the sample project will add a couple of achievements to Eclipse, similar to Steam, Xbox or Playstation achievements. I got the idea for that from this post. The project structure will be like this:

Read more

First-class Scala Lift support in JRebel

Read more