What are "sugar", "desugar" terms in context of Java 8?

I hear about 'sugaring' and 'desugaring' more often in Java 8, what does these terms mean ? are they conceptual or syntactical.

Some Example:

> Default iterated loop resugaring to java > > Observations about syntactic sugar in compilation.

sugar, in programming, usually refers to those sweet additions, mostly shortcuts, that make some constructs easier to type and to read (the latter being, in practice, the most important during the life cycle of your program).

Wikipedia has a definition of syntactic sugar but you should note that not all sugar is, in essence, syntactical (not all recent sweet additions were just compiler changes).

Here are a few examples :

• the postfix and prefix increment operators (i++ and ++i). Their only purpose is to avoid writing an additional statement. They're pure sugar.
• +=, |=, &=, etc. are made of the same kind of sugar.
• Implicit conversion between primitive types and objects is sugar too.
• type inference is sugar too.
• Lambda expression, coming with Java 8, is some other kind of sugar (this one not just syntactical)

Java is widely seen as not being concise enough, especially compared to modern languages. That's why those additions that help make the code faster to read are welcome.

To finish, I'd just note that while a lack of sugar can make your program fat, an excess of sugar, leading to many different ways to write the same things, can make your language queasy and your program less coherent and harder to maintain. Another kind of sugar, API sugar, is most often a plague which makes the API harder to grasp, especially when it's made of additions (overloading for example).

This being said, desugaring refers either to

• the process by which you remove all that is redundant in a language

• the process by which a code processor finds out what's behind a sugared statement (this may for example involves type inference)

"Desugaring" appears to have a very specific meaning in Java 8. It seems to be a catch-all term to express the various ways a lambda expression may be bound to an actual concrete method call.

This document on "Translation of Lambda Expressions" has the real details of what's going on if you're interested in specifics.

A key phrase from the document: > The first step of translating lambdas into bytecode is desugaring the lambda body into a method.

In general "desugaring" in javac allows representing some language features with preexisting ones. This allows representing them in the bytecode without making big changes to the class file format. Also for this reason the back-end of the compiler is more stable than the front-end. This doesn't mean that every new language feature is just syntactic sugar, as is definitely not the case of lambdas and method references. There are more examples of "desugaring" in the compiler:

• for each loops are "desugared" to C style for loops
• assertions are "desugared" to an if sentence
• inner classes are represented as a standalone class

You can investigate also what happen with the String switch, type erasure,...

As others have noted, in computer programming and in this context, "sugar" refers to language features that make the code nicer to read/write. "Desugaring" refers to automatically translating "sugar" constructs into other constructs when the compiler or runtime lacks native support for the sugared versions.

These concepts come up frequently for Java in the context of Android. Android doesn't include a JDK, but instead is a re-implementation of the Java runtime. Therefore support for new Java language features depends on Android supporting the new language features. Currently all Android apps can support all Java 7 features, and a subset of Java 8 features, using desugaring. See "Use Java 8 language features and APIs" for details.

Here's an article going into the details of desugaring Java features in Android: "Android's Java 8 Support". According to the article, lambdas are actually always desugared in Android binaries ("This is why desguaring always happens at compile-time regardless of your minimum API level.")