Category: version control

Undo/Redo in Java using Protostuff serialization and binary diffs

Many applications need Undo/Redo functionality. Commonly used implementation patterns are:

  • Command Pattern
  • Memento Pattern (state snapshots)
  • State diffs

When using the Command Pattern one would encapsulate both the change logic and its reversal in command objects. Undo/Redo is implemented by managing stacks of those objects. This approach has its limitations, for example for changes that are unidirectional in nature, like anything involving randomness, encryption, etc.

State snapshots save the full state of the edited data as object graphs or some representation thereof. This is also called the Memento Pattern. It often uses serialization and typically compression of the object graph to reduce memory use and ensure immutable snapshots that can also be stored out-of-process, if desired.

State diffs are based on the idea of State snapshots, but only store the difference between states. This can vastly reduce memory consumption of your Undo/Redo history. It is based on diffing algorithms that compute the delta between two states (or their memento) and allow Undo/Redo by applying the deltas as patches against a given state. A disadvantage is that jumping to a state involves a whole chain of patch applications. But it is a good approach when the user mainly navigates the Undo/Redo history sequentially.

A highly reusable implementation of Undo/Redo using State Diffs is available at my github account: https://github.com/odoepner/diffing-history

It uses the following Open Source libraries:

  • Protostuff for object graph serialization using runtime schema
  • JavaxDelta for binary diffing and patching

It provides the following features:

  • Unlimited Undo and Redo
  • Can handle any type of Java objects
  • Low memory footprint
  • Straightforward type-safe API
  • Supports stack size listeners
  • Gzip compression for the serialized current state

It is Open Source under the Unlicense.

Usage

The main API is the History interface.
Create an instance of DiffingHistory to get started.
The DiffingHistoryTest calls all History methods and illustrates the API.

Advertisement

Recursively compare content of two directories

Command line

This requires the diff and vim packages.

diff --recursive /dir/ect/ory1 /dir/ect/ory2 > 1_vs_2.diff
vimdiff 1_vs_2.diff

Potentially useful diff options:

--ignore-all-space
--exclude=.svn

GUI

Install Intellij CE.

Then either Run IntelliJ Diff from the command-line.

Or from within a running Intellij window:

  • Open a common parent directory as a project
  • Select the two directories to compare
  • Right-click – Compare Directories

Alternatives

I often see the GPL-licensed WinMerge tool recommended, But it works only on Windows, last release was 2013 and navigation into sub-directories and file diffs is a bit clunkier than in Intellij.

Continuous delivery using github, travis-ci and bintray

Continuous-Delivery-schema

Let’s say you work on a Java application and want to frequently make it available for download so that user’s can easily try the latest version.

Let’s say you work primarily on your laptop or personal computer using a Java IDE and commit code changes, but you don’t want to spend time manually building jars, packaging war or zip files, testing your application or uploading files to a website, etc.

Instead you want to have a fully automated process that compiles your source code, runs automated tests and other quality control mechanisms, builds your application and uploads the result to a public website.

But you don’t want to install any infrastructure for this and not run anything besides Java and your IDE on your own machine(s).

Basically you want to use developer-friendly reliable cloud services but you don’t want to pay a single cent.

All of this is possible, as long your code is Open Source:

  • Host your source code on github
  • Let travis-ci run vour build process
  • Let travis-ci upload the build result to bintray

For details, you can take a look at one of my github projects.

Relevant config files:

Diff zipped files in Intellij using “Archive” file type

Some file types are really just zipped (or maybe gzipped) folders containing xml and/or other plaintext based files.

For example

  • *.epub e-books
  • OpenDocument files
  • Java source jar files
  • JEE web application archives (*.war)
  • Pentaho report files (*.prpt)

If you happen to have such files in a software project, and don’t want to treat them like opaque binary blobs, you need a tool that helps you to transparently unzip, act on and rezip them. Also you probably want to be able to diff them without resorting to commercial tools like BeyondCompare.

IntelliJ CE (Community Edition) supports archive diffs as part of its regular Comparing Files functionality. All you need to do is make sure the file extension of the file types you want to be treated as archives are accordingly registered in Settings – Editor – File Types.

The screenshot below shows *.war and *.jar registered as Archive file name patterns (by default) and *.prpt (Pentaho report files) as an example of a manually added pattern:

intellij_register-pentaho-prpt-as-archive-file-type

JBoss Undertow is pulling me in … :o)

I am very impressed as I am trying out the various code examples for Undertow, a kick-ass, light-weight yet powerful, ultra-easy-to-embed HTTP and Java Servlet engine.

One of my side projects requires an embeddable yet feature-complete Java HTTP engine with low memory footprint and a simple straightforward API. I dismissed Tomcat, briefly considered Jetty, found Winstone too old and unmaintained, simpleframework not well-enough documented, vert.x and netty a little too much for my purposes and/or too complicated, so that a few weeks ago I had actually started to clone and refactor NanoHttpd.

The NanoHttpd refactoring was a great learning experience, but it certainly felt like I was reinventing the wheel in the form of a cute and mobile but slightly rusty foldable unicycle. ;o) – no offense please, nanohttpd developers …

Then I found out about Undertow. The author Stuart Douglas is now officially my hero. What an awesome job he is doing! The server meets all of the above mentioned requirements and is apparently also comparatively fast. No wonder it is the HTTP engine used by Wildfly, the new JBoss AS.

Anyway, if you want to try yourself, I’d go with version 1.1 final at this time, i.e. this in your Maven pom.xml:

<dependency>
    <groupId>io.undertow</groupId>
    <artifactId>undertow-core</artifactId>
    <version>1.1.0.Final</version>
</dependency>

I decided to pretty much ignore the documentation section of the undertow.io website for now, as it is still for version 1.0 and the API has changed – improved, I guess – since then. It seems to me, that at this point the core code itself and the usage examples are the best documentation for version 1.1. Both are Maven modules of the undertow github project.

By the way, if you are wondering why the project has no issues section on github: The issue tracking is done in the JBoss Jira.

Java software engineering – reference resources

Official Java and JEE

Java Technology Reference

Java Standard Edition (JSE)

Java Enterprise Edition (JEE)

The official Java tutorials

The official JEE 7 tutorial

JEE 7 Technologies index

Java language spec and JVM spec

Java community

Oracle Java community

OpenJDK

Java Community Process (JCP)

Apache Commons

Apache.org Java projects

JBoss.org

Spring

Google Guava

Trending Java projects on github

JEE and Java web servers

Apache Tomcat

JBoss Wildfly

Glassfish

Build and test automation

Sonatype Maven books

Jenkins documentation (wiki)

JUnit reference documentation

Source and version control

The SVN reference book

Git reference documentation

Java IDEs

Intellij IDEA documentation

Eclipse documentation

Netbeans knowledge base

Vim configuration for Java coding

Create single copyright holder, GPL licensed source code repository

I sometimes want to create a source code repository and build process for a GPL licensed software project, where the sole copyright holder (“owner”) is a single legal entity, like a company or a foundation.

This is how I do it:

  • Link to the license from README.md (e.g. the Free Software Foundation’s GPL, version 2)
  • At top of each source file: Copyright notice, license statement, warranty disclaimer
  • Include a plain-text copy of the full license in the root of your distributable package(s)
  • In the README.md, indicate that the project mandates copyright assignment
  • Define the legal agreement process between code contributors and the project owner

The GPL was chosen for its strong copyleft nature and combined with the sole copyright holder approach to enable dual licensing business models.

On sites like github, the code contribution itself is usually done by pull request. The legal agreement process between code contributor and project owner should be complete before the pull request is accepted.

I am not yet sure how to best automate updating the year range in the copyright notice, probably at commit time.

Subversion 1.8 released

The new Subversion 1.8 features look quite good for a centralized Version Control System (VCS).

But note that the Subversion 1.8 working copy format is backwards-incompatible. Some tools like recent TortoiseSVN versions will use the 1.8 format by default which will cause compatibility problems for IntelliJ and any other tools that do not yet support it.

So for now, it is probably better to stick with 1.7 and wait until all your tools fully support 1.8. For IntelliJ you might want to watch [IDEA-94942] for status updates.

Personally, I am more interested in Git anyway because it offers all the flexibility of a decentralized VCS. I am reading the free “Pro Git” ebook on my Kobo eReader (epub format).