After months in development, the FlatBuffers 1.1 update is here. Originally released in June 2014, it’s a highly efficient open source cross-platform serialization library that allows you to read data without parsing/unpacking or allocating additional memory. It supports schema evolution (forwards/backwards compatibility) and optional JSON conversion. We primarily created it for games written in C++ where performance is critical, but it’s also useful more broadly. This update brings:

• an extensive overhaul to the Java API
• out-of-the-box support for C# and Go
• an optional verifier to make FlatBuffers practical in untrusted scenarios
• .proto parsing for easier migration from Protocol Buffers
• optional manual assignment of field IDs
• dictionary functionality through binary search on a key field
• bug fixes and other improvements thanks to 200+ commits from 28 contributors -- thank you!

Download the latest release from our github page and join our discussion list for more details.

By Wouter van Oortmerssen, Fun Propulsion Labs at Google*

*Fun Propulsion Labs is a team within Google that's dedicated to advancing gaming on Android and other platforms.

We are proud to announce the open source release of J2ObjC, a Google-authored translator that converts Java source code into Objective-C source for iPhone/iPad applications.

J2ObjC enables Java code to be part of an iOS application's build, as no editing of the generated files is necessary. The goal is to write an application's non-UI code (such as data access, or application logic) in Java, which can then be shared by Android apps, web apps (using GWT), and iOS.

J2ObjC is not a Java emulator, but instead converts Java classes to Objective-C classes that directly use the iOS Foundation Framework.  It supports the full Java 6 language and most of its runtime features that are required by client-side application developers, including exceptions, inner and anonymous classes, generic types, threads and reflection. JUnit test translation and execution is also supported.  J2ObjC can be used with most build tools, including Xcode and Make.

You can go to the J2ObjC project page for instructions on how to use the tool, check out the source code and view the list of reported issues.  The site also has detailed design docs for anyone interested in how the translator works.

By Tom Ball, Google Engineer, Mountain View

Today, we announce the release of Interactive Spaces, a new API and runtime which allows developers to build interactive applications for physical spaces.

Imagine walking into a room where the room recognizes where you are and responds based on your position.

You can see an example above. There are cameras in the ceiling which are doing blob tracking, in this case the blobs are people walking on the floor. The floor then responds to the blobs by having colored circles appear underneath the feet of someone standing on the floor and then having the circles follow that person around.

Interactive Spaces works by having “consumers” of events, like the floor, connect to “producers” of events, like those cameras in the ceiling. Any number of “producers” and “consumers” can be connected to each other, making it possible to create quite complex behavior in the physical space.

Interactive Spaces is written in Java, so it can run on any operating system that supports Java, including Linux and OSX and soon Windows.

Interactive Spaces provides a collection of libraries for implementing the activities which will run in your interactive space. Implementing an activity can require anything from a few lines in a simple configuration file to you creating the proper interfaces entirely from scratch. The former gets you off the ground very quickly, but limits what your activity can do, while the latter allows you the most power at the cost of more complexity. Interactive Spaces also provides activities’ runtime environment, allowing you to deploy, start, and stop the activities running on multiple computers from a central web application in your local network.

Additional languages like Javascript and Python are supported out of the box. Native applications can also be run, which means packages like openFrameworks which use C++ are also supported out of the box. Plans are also underway for supporting the Processing language.

Sound like fun? Check it out on Google Code.

By Keith Hughes, The Experience Engineering Team

We are thrilled to announce the open sourcing release of WindowTester Pro, a solution that automates the process of GUI testing. WindowTester Pro is shipped as a Eclipse plugin and has support for Eclipse versions 3.5, 3.6 and 3.7. WindowTester Pro was previously offered by Instantiations Inc.

Using WindowTester Pro, developers can easily create tests for every GUI they create. The tests generated by WindowTester Pro are standard Java JUnit tests, thus they can be run within your Eclipse environment or they can be automated to run using Ant. Tests can be generated for SWT and Swing Java applications.

WindowTester Pro contains a recording console that captures and records keyboard clicks and mouse movements. The first step in test development is to turn on the Record feature and then work with various elements of the UI such as windows or buttons. WindowTester Pro will capture the steps taken.

Once the GUI has been exercised, the developer closes the application under test. When the application is closed, the recording is terminated and the test is generated.

Using WindowTester Pro empowers developers with testing capabilities and reduces the time required to hand-code tests. This enables developers to build quality into the product early in the process because problems are found and resolved earlier in the development cycle. WindowTester Pro can help developers and companies drastically lower both testing time and cost.

For more information, please visit the WindowTester Pro home page or join the discussion list.

The Googlers who made this open sourcing release possible include Eric Clayberg, Keerti Parthasarathy, Mark Russell, and Seth Hollyman.

By Keerti Parthasarathy, Software Engineer, Google

In addition to being known as “The Mother of Java,” Josh Bloch is also the Chief Java Architect at Google. Josh sat down with fellow Open Source Programs Office colleague Jeremy Allison to chat about APIs, the importance of openness, and the successes and failures of Java.

Some highlights from their conversation:

(0:45) Josh describes what he does for Java and at Google.

(1:59) Jeremy expresses his disappointments with Java, based on the early potential that it showed. Josh responds with an explanation of some of the difficulties that Java faced.

(4:48) Josh and Jeremy talk about some of the factors that contributed to Java’s successes.

(9:51) Josh’s explains his philosophy towards creating APIs.

(14:30) Josh talks about the APIs that he’s most proud of.

(19:45) Josh and Jeremy discuss the importance of reading other people’s code, and the impact of Sun’s decision to put the code and bug database for Java on the web.

(24:00) Josh explains how he came to be in his current position and gives advice for others who are looking for ways to get started programming.

(27:32) Josh wrote the standard Java best-practices guide, Effective Java, and co-authored two other Java books: Java Puzzlers, and Java Concurrency in Practice. As a special treat for this blog’s readers, Josh is offering signed copies of his books for the first two people with correct responses to the following puzzle. Submit your answer as a comment on this post, then use the same Blogger ID to leave a separate comment with your contact info and inscription request (for your privacy, the comment with your contact info will not be published).

Josh’s Puzzle: “The Story of O”

The following Java program is not quite complete; it’s missing a parameter declaration for o. Can you provide a declaration that makes the program print “O noes!”? (The program must compile without generating any warnings.)

public class Story {
   public static void main(String[] args) {
       Object o = null;
       story(o);
   }

   private static void story(<you provide the declaration> o) {
       if (o != null)
           System.out.println("O noes!");
   }
}

Remember to leave your answer and contact info as two separate comments!

By Ellen Ko, Open Source Team

If you’ve ever spent hours debugging your Java code, today’s blog post is for you.

Often bugs that are frustratingly elusive and hard to track down appear simple or even trivial once you have found their cause (the fault). Why are those bugs hard to track down? One possibility is that the fault is in a completely different part of the program than its symptom (the failure).


Contracted code reveals failures much closer to their fault, leaving you with a far simpler problem to solve:

Traditionally, Java programmers enforced preconditions using explicit parameter validation code in public methods, and assertions in non-public methods. Likewise, they enforced invariants and postconditions using assertions. This approach is described in detail here. Since then, new features in Java 5 have enabled a more convenient and expressive implementation of contracts.

Contracts for Java is our new open source tool. Preconditions, postconditions, and invariants are added as Java boolean expressions inside annotations. By default these do nothing, but enabled via a JVM argument, they’re checked at runtime.

• @Requires, @Ensures, @ThrowEnsures and @Invariant specify contracts as Java boolean expressions
• Contracts are inherited from both interfaces and classes and can be selectively enabled at runtime

Contracts help you turn interface documentation into code. For example:

/**
* @param left a sorted list of elements
* @param right a sorted list of elements
* @return the contents of the two lists, merged, sorted
*/
List merge(List left, List right);

Could be expressed as:

@Requires({
"Collections.isSorted(left)",
"Collections.isSorted(right)"
})
@Ensures({
"Collections.containsSame(result, Lists.concatenate(left, right))",
"Collections.isSorted(result)"
})
List merge(List left, List right);

The interface is now precise and every class that implements it can be checked at runtime.

Contracts are a powerful language feature and can provide great benefit if used correctly. We recommend that newcomers find an expert to learn from or spend some time reading around the subject to pick up good habits and avoid bad ones.

One point that often surprises people is that contracts must not be used to validate data. Contracts exist to check for programmer error, not for user error or environment failures. Any difference between execution with and without runtime contract checking (apart from performance) is by definition a bug. Contracts must never have side effects.

Another important point is that by convention module interfaces in Java are total, that is, they are defined for all input. In the case of incorrect input, they promise that a particular exception will be thrown. This behavior remains part of each method’s implementation and cannot be moved to the contract.

Contracts for Java is based on Modern Jass by Johannes Rieken. Rather than being a full time project it was conceived and developed in the 20% time of two software engineers and then developed further through an internship. The internship report (PDF) goes into detail about the work done and the methodologies used.

Contracts for Java was inspired by Eiffel, a language invented by Bertrand Meyer, which has built in support for contracts.

By David Morgan, Andreas Leitner and Nhat Minh Le, Contracts for Java 20% Team

A few years ago, we released GWT, the Google Web Toolkit, which allows code to be written in Java using your favorite editors and then compiled into JavaScript that runs smoothly on host browsers. Today, we're releasing some additional debug tools to make troubleshooting easier. See the post on the GWT blog for more details!

By Jeff Bailey, Software Engineering Team

SimplexSolver is an easy-to-use, object-oriented method of solving linear programming problems. We're happy to announce today that we've Open Sourced the code that runs the newly released Google Spreadsheets Solve Feature and made it a part of Apache Commons Math 2.0.

While numerous other libraries are available that run linear optimization problems, SimplexSolver is the first written in Java with a commercially-friendly license.

Let's say we have the following LP:

MIN -2x + y - 5
S.T.
x + 2y <= 6
3x + 2y <= 12
y >= 0

We could solve the problem in Java using the SimplexSolver:

// describe the optimization problem
LinearObjectiveFunction f = new LinearObjectiveFunction(new double[] { -2, 1 }, -5);
Collection constraints = new ArrayList();
constraints.add(new LinearConstraint(new double[] { 1, 2 }, Relationship.LEQ, 6));
constraints.add(new LinearConstraint(new double[] { 3, 2 }, Relationship.LEQ, 12));
constraints.add(new LinearConstraint(new double[] { 0, 1 }, Relationship.GEQ, 0));

// create and run the solver
RealPointValuePair solution = new SimplexSolver().optimize(f, constraints, GoalType.MINIMIZE, false);

// get the solution
double x = solution.getPoint()[0];
double y = solution.getPoint()[1];
double min = solution.getValue();

Looking at the LP problem and Java code side-by-side, we can see how easy it is to describe the problem in the Apache Commons Math API. More examples can be viewed in the SimplexSolverTest source code. Apache Commons Math 2.0 is not quite released yet, so for the time being if you want to use the SimplexSolver, you'll need to compile it from source.

So that's SimplexSolver: a clean, fast method of solving LP problems. We hope you like it as much as we do! Thanks to Luc Maisonobe and the rest of the Apache Team who helped integrate the SimplexSolver into the Apache codebase.

by Ben McCann, Software Engineering Team

The ICU project is celebrating 10 years of being open source this month.

"ICU" in this case stands for International Components for Unicode - not to be confused with Intensive Care Unit or International Communist Union... It is the premier software internationalization library, appearing in everything from your Google Android phone or your iPod all the way up to IBM mainframes. It provides the Unicode support that all of these programs need for handling the languages of the world, from Arabic to Chinese to Vietnamese.

ICU originated back in an Apple/IBM/HP joint venture. That code was morphed into the core of Java internationalization for JDK 1.1.4 - a large portion of this code still exists in the java.text and java.util packages. At that time, it included pretty much just sorting, locale/message support, and formatting for dates, numbers and so on. (If you're interested in early history, see an older paper by Laura Werner - now at Google). The libraries were refined over time and ported back to C and C++; now there are also wrappers for other languages, such as PHP.

ICU's data comes from the Unicode Consortium's open source project for locale data - CLDR - and typically releases each new version right after CLDR does. CLDR 1.7 was just released Friday, May 8, with ICU 4.2 following on the very same day.

While ICU was around before Google, more recently Google has played a strong role in the development of ICU, and in providing major contributions to the Unicode CLDR project. ICU forms the foundation of our 40 language initiative, so we look forward to many successful future birthdays!


By Mark Davis, Internationalization team