Jazoon 2010 Day 1

2. June, 2010

So, this is the great wrap-up of Jazoon 2010, day 1. What did I have?

The keynote by Danny Coward

Java SE and JavaFX: The Road Ahead. After the acquisition by Oracle, everyone was curious as to what happens to Java. Unfortunately, the slides aren’t online, yet but from my faint memory, we might get closures after all and with a sane syntax, too. Plus all the stuff mentioned on Sun’s JDK 7 page. ATM, this stuff is a bit fluent and it’s hard to get a definitive list but something is moving at least.

From my point of view, closures and all the other language features are too late for the Java language (important companies won’t upgrade to Java 7 and time soon, some of them even cling to 1.4!) but the implementation in the main language of the Java VM will allow to build better and faster non-Java languages on top of the VM. Now if the VM would include a compiler API to build JNI code for native libraries on the fly, we would have a worthy challenger for .NET. Yeah … I know. A man can have dreams, okay?

And there was some talk about JavaFX. It seems that the technology is starting to reach its beta-phase, soon (see my notes for the second day). He showed one demo: Geo View of Vancouver 2010. It’s a world map with which country won how many medals and when you open one of the blobs, you get the names of the athletes in a fan-out widget. You can click on the name to get more information (like the photo) or you can compare the results against countries with the same number of athletes or population or closest GDP or just closest geographically. It gives a nice example how to visualize a lot of data and wade through them intuitively.

Client / Server 2.0 with Java and Flex by James Ward

James showed how you can use Flash and a Java server to build really nice web apps. He showed several examples: A few lines of code to build a UI which runs on an Android mobile phone, in the web browser and on the desktop. All with really nice performance. One was the insurance company demo. Just enter some arbitrary data until you come to the damage details and incident report. They show new ways to enter information which make the tool usable to anyone who can recognize a car and a top-view of a street.

If you like what you see, you should probably take the Tour de Flex. It shows off a whole lot of stuff. Also try the Tour de Flex Dashboard. It shows you in real time who looks at what part of the TdF right now.

Blueprint – Modern Dependency Injection for OSGi by Costin Leau

Another DI system, this time tied to OSGi. Nothing really exciting here. The talk was okay but the speaker soon lost my interest.

One thing to note: Eclipse 4 comes with a different DI system. I wonder if they will drop that in favor of the new OSGi standard in 4.1.

Patterns and Best Practices for building large GWT applications by Heiko Braun

I went to see this but quickly realized that I’ve heard the talk before at the JUGS. Here is the link to the slides. As a result of his experience he started project errai which collects best practices to build large GWT applications.

Objects of Value by Kevlin Henney

One of the main weak points on software development is that we don’t know what we’re talking about. When my project manager comes to me and asks “When are you done?” my answer is “Soon” … Right ;-) Or think about strings. Everyone else on the planet calls it “text”.

Obviously, Kevlin had a lot of fun on stage and so had we. In essence, “Objects of Value” or “Value Objects” are even more simple than POJOs (think Integer class). The main reason to use them is to make your code more expressive and readable. Instead of

public User (String name, String firstName, int age, String zipCode, String city)

you (can) create a couple of value objects:

public User (Name name, FirstName firstName, Age age, ZipCode zipCode, City city)

This may sound ridiculous (and it is in this example) but in a lot of places, using String is just a form of bad laziness (the kind of laziness which leads to maintenance problems later). One of the advantages of the approach above is that you notice when you mix last and first name because the compiler will tell you. The major disadvantage is that it leads to a class explosion. Not to an instance explosion since we just replace a String value object with something that tells us what we have, though.

In addition to that, Java isn’t really meant for these kinds of objects. There is a lot of boiler plate code to define value objects and to use them. But if you have a system that is sufficiently complex and you use a value with a unit in many places (think of a currency value), you should really consider to replace the String+BigDecimal combination with a value object.

Many important points of his talk can be found in the paper Objects of Value on his homepage.

This concludes the first part of my Jazoon 2010 report. Go on with part 2.


Using Mercurial with Dropbox

17. April, 2010

If you want to take a Mercurial repository with you, you have several options:

  1. Create a server somewhere. Don’t forget to install all the security patches.
  2. Use an USB stick. Don’t forget it somewhere (like at home) and don’t forget to always push your changes onto it.
  3. Use Dropbox

Dropbox is a file server in the cloud. While they swear your data is save (“All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.” – see the features), it’s better to be safe than sorry. Also, Dropbox can’t really cope with the fast changes to the virtual filesystem done by Mercurial (this will lead to corrupt repositories and missing changesets).

The solution is to create a TrueCrypt container in your Dropbox. Dropbox won’t be able to see any changes as long as the container is mounted. When you dismount the container, Dropbox will check the file for changes (if you write to the container, TrueCrypt just modifies a few sectors). So even if you create a 100MB container, only the initial sync will be slow.

There are few obstacles, though:

  1. You must remember to mount the container, and push your changes into it.
  2. If you forget to dismount and push changes into the container on a different computer, you’ll see two containers. In this case, mount the second container somewhere, merge the changes using Mercurial and then commit to the original container.
  3. You must install TrueCrypt and Dropbox on all computers where you want to use this.
  4. The cycle “mount-push-dismount” becomes tedious over time.
  5. If you use HgEclipse, the plug-in will forget the local paths if you forget to mount the container before you start Eclipse.

The OSS dilemma

7. April, 2010

Disclaimer: IANAL

In his post about EPL, GPL and Eclipse plugins (“EPL/GPL Commentary“), Mike Milinkovich says:

What is clear, however, is that it is not possible to link a GPL-licensed plug-in to an EPL-licensed code and distribute the result. Any GPL-licensed plug-in would have to be distributed independently and combined with the Eclipse platform by an end user.

Which is probably true because of the incompatible goals of the two licenses: The EPL was designed by companies, which make a lot of money with software, to protect the investments in the source code they contribute to an OSS project. Notice “a lot of money.”

The GPL was designed to make sure companies can’t steal from poor OSS developers and sell a product as their own or take some source code, add a few lines of code and then sell it as their own, etc. The GPL, unlike the EPL, is made as a sword to keep people away who don’t want to share their word under the GPL.

As such, both licenses work as designed and they are incompatible because their goals are incompatible. We as OSS developers can whine and complain that there is no legal way to build an Eclipse plugin for Subversion without first creating an Subversion client which is EPL licensed but that doesn’t change the fact that it is illegal. It’s the price we pay for the freedom we have. If the licenses were different, there would be legal loopholes.

Yes, it sucks.


When you’re right, there is no middle ground

15. January, 2010

Yesterday, I attended a talk by Tom Schindl (he’s the guy behind UFaceKit and Qooxdoo, QxWT, etc.) And he’s working on e4.

During our little conversation after the talk, he stressed the fact many people aren’t willing to pay for bugfixes in Eclipse. He’d be willing to work on many of them but someone has to pay the bills. I nodded like everyone else. And we talked about Eugene Ostroukhov and his complaint ““Participate in community!” they said…“. And I immediately saw a parallel in my own history. I had a similar, painful experience with Ed Merks a while ago. That was about EMF and how badly it sucks. And that he didn’t listen to me.

I was mad because I was right and he just didn’t get it.

Yesterday, on the train home, I understood.

I’d like to introduce two new categories of programmers. Both are passionate and enthusiastic about software. The difference is that one group is pragmatic and the other idealistic.

Ed and Tom are pragmatics. They think: “Great feature, I like it, how much will it cost?” If it’s too expensive, they don’t get upset. They think about it, mull it around, consider their options. If there just is no viable way to do it, they can accept that. These people get money to write software.

I’m an idealistic programmer. I get money to stop writing software. That is, I get money to stop writing the software in my head and to start writing the software someone else wants. Not getting what I envision drives me up the wall.

Things can get pretty ugly when those two kinds meet. Because both are egoistic and both are right. It would make sense to make all the changes to EMF that I want. For me and probably a few others. It would cause quite a few problems for Ed, though (mostly because he’d get a lot of complaints by those people who are happy right now).

I’m asking for changes because I have problems. I’m not complaining about petty things. I need to bend EMF and SWT more than the API allows. To solve my problems, I just can’t accept the status quo. The API has to move. But my solution would cause problems for many other people.

Right now, I’m writing software which doesn’t have a lot of customers, so a stable, reliable API is not one of my goals. I can change my API at a whim and no one bothers. Eclipse has millions of customers and every change to any API will cause a tremendous amount of pain around the globe. Say 0.1% have a problem now? That would be at least 1’000 people complaining. One happy, 1’000 after your head. At least. How big is the pressure on Ed to make me happy?

So how to win? I think Linux has the best solution that you can get today. Linux has several release streams that strive in parallel. It’s not a bunch of forks, it’s a bunch of branches. People can hand in stuff that really isn’t ready for prime time. It can be incomplete. It can break other APIs. It can be an experiment. It can evolve. In Linux, there is the next tree.

In Eclipse, evolution is hard. You have to get new features and patches past people you don’t know, who have more experience in evolving APIs, little time and little incentive to hurt themselves. API in Eclipse is hard to evolve because IBM pays many of the core developers. If someone wants some obscure API and the Lotus Notes team will have a problem with that, who will win? The bug report (even with a patch) or your next pay check? There are only a few big commercial products on Linux. Eclipse, OTOH, was created to form the basis for commercial products (hence the EPL). Products that have life cycles between five and ten years. Ten years ago, we had Linux 2.2, KDE 1.0 and SuSE 6.3.

For IBM and SAP, the one year release cycle of Eclipse is way too fast. They have to spend a lot of money on developers just to keep up with all the changes going on in Eclipse and this is for things that can’t be sold to customer (i.e. which don’t earn any money).

So I agree with Bjorn Freeman-Benson that Eclipse needs a set of public git repositories and a low-barrier entry to these repositories (which means one-click install for the build system, no IP checking). It should be a playground, a place where ideas can grow. Not all of them will make it into the mainstream but at least, people can solve their problems without hurting too many others.

At the same time, I’m afraid what will happen when this comes true. But then, I’m an idealistic programmer. I believe that time will tell who was right and that we shouldn’t bother too much upfront.


How to make Eclipse 3.5 work on gtk2 2.18

24. December, 2009

If you’re using Eclipse in Linux with gtk2, then you might have run into this issue: Buttons don’t work when you click on them, tree views are initially empty, icons are missing or not drawn correctly. To fix this, just run this command before you start Eclipse:

export GDK_NATIVE_WINDOWS=1

I suggest that you put it into a little wrapper script. With this option enabled, Eclipse works like it should, even on Linux/gtk.

It’s a good example of the pain when working with Eclipse developers: Everyone agrees that it’s a bug and it’s pretty clear what needs to be done. The fix apparently even exists and “just” needs to be copied from the 3.6 sources to 3.5. And nothing happens because the release process is so involved that it just takes too much time and the workaround (adding the line above or control Eclipse with the keyboard) is too simple.

I can’t say on which side I’m on here. I understand why nothing happens but it still freaks me out.


Groovy Eclipse V2 M2

14. December, 2009

It’s been a couple of days since the Milestone 2 of the new Goovy Eclipse V2 plugin was released. If you’re developing with Groovy and you’re using Eclipse and you’ve been living under a stone, get it now. It’s so much better than the old Groovy plugin.

In word: Development with Eclipse has become Groovy, again.

Links:
Groovy-Eclipse 2.0.0M2 New and Noteworthy
Groovy-Eclipse 2.0.0M1 New and Noteworthy


Attaching Sources To Eclipse Artifacts

8. October, 2009

After running mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=...path/to/eclipse, you might have lots of source JARs but they aren’t in the right place for Maven 2 to pick them up.

This little Python script fixes that. Just run it after eclipse:make-artifacts.

Note: You may be wondering why I use eclipse:make-artifacts instead of the recommended eclipse:to-maven. Simple: I don’t like to have a dozen core-*.jar in my project.

"""Maven 2 Eclipse Artifact Source resolver

After importing Eclipse artifacts into an M2 repository with

> mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=.../eclipse

run this script to move all source JARs in the right place for
Maven 2 to pick them up.
"""
import os, sys
from shutil import copyfile

def processGroup(path):
    print 'group %s' % path
    for dir in os.listdir(path):
        path2 = os.path.join(path, dir)
        if '.' in dir:
            processArtifact(path2)
        else:
            processGroup(path2)

def processArtifact(path):
    srcPath = path + '.source'
    #print 'processArtifact',srcPath
    if os.path.exists(srcPath):
        processArtifactWithSource(path)

def processArtifactWithSource(basePath):
    binPath = basePath
    srcPath = basePath + '.source'
    baseName = os.path.basename(basePath)
    print 'artifact', baseName

    for version in os.listdir(binPath):
        vbinPath = os.path.join(binPath, version)
        vsrcPath = os.path.join(srcPath, version)

        srcJar = os.path.join(vsrcPath, '%s.source-%s.jar' % (baseName, version))
        destJar = os.path.join(vbinPath, '%s-%s-sources.jar' % (baseName, version))

        if os.path.exists(srcJar):
            print '%s -> %s' % (srcJar, destJar)
            copyfile(srcJar, destJar)

m2repo = os.environ['M2_REPO']
if not m2repo:
    raise Exception('Env variable M2_REPO is not set')

root = os.path.join(m2repo, 'org', 'eclipse')
for dir in os.listdir(root):
    path = os.path.join(root, dir)
    processGroup(path)

Updated 01. December 2009: The script now figures out where your M2 repo is. Plus a minimum of documentation.


Updating Eclipse to 3.5.1 with p2

28. September, 2009

Maybe you’ve tried to update Eclipse to 3.5.1 and … you failed. Maybe it’s because the update site has gone. I’ve opened bug 290723. See you there.


Powerful Wiki Engine for Eclipse

1. September, 2009

I’m toying with the idea to write a powerful wiki engine for Eclipse. What I have in mind should

  • Allow multiple markups (because all markups suck, so there is no point to prefer one over the other)
  • Should offer a side-by-side editor (source and preview because WYSIWYG is impossible to get right)
  • Should support automatic links (just like in the Java editor)

Right now, I’m not sure whether I should start with Mylin WikiText or Xtext.

Both look promising. WikiText support multiple markups. I just don’t like the two-page editor (where you have to flip pages to see what you’re doing). Also, I’m not sure how flexible the whole framework is.

Xtext would allow for much more complex markups but I’ll probably have to start with a more basic framework.

Links: Extending RIM with Xtext


Pair Programming Preferences Dilemma

4. February, 2009

The basic idea behind pair programming is that you have one computer, one keyboard, two heads (one being mostly occupied with typing). There is just one problem, though: If you’re a developer like me, you’re using keyboard shortcuts. Lots of shortcuts. And you will have your own ways to achieve things. Those ways will be different from everyone else in the team. You’re not a clone, are you? Which leads to special shortcuts.

IDEA allows to switch prefs quickly with Ctrl-BackQuote (try that on a German keyboard …) Eclipse has no way to quickly switch the UI prefs (shortcuts, active toolbars/menus).

I’ve filed a new bug to track this.