Embedded Java 1.4 Compiler

19. May, 2011

If you need a small, fast Java 1.4 compiler that you can embed in your application, try Janino.


Project Ceylon, Successor for Java?

14. April, 2011

A lot of languages compete for the king’s seat taken by Java. Most of them solve a lot of problem with Java but none of them really takes the win. As I say: “Why is there more than one database? Because they all suck.”

Now Ceylon enters the stage (slides from the presentation). The main goal is to clean up the SDK while keeping an eye on what was good and what was bad with Java.

I’ve had my share with programming languages. On a scale between 1 and 10 (best), Python gets 9 from me. Java gets 6. Scala gets 5.

So how does Ceylon fare? At first glance, I’d give it a 7.

Pros:

  • Compact syntax. No packages, no classes.
  • I like to idea of the recursive block scope which gets rid of the very limited public/private and the ill fated package public. My only concern is how you can declare friends to something at a nested scope (for example for tests).
  • Short syntax to avoid NPEs. The approach allows to catch null pointers when they are assigned instead of when they are used. This means: If you find a bug, you’ll actually know what to do about it.
  • No new keyword! I really never understood why they added that.
  • No checked exceptions. No one got them right, anyway.
  • Just one constructor per class. I never use them anyway, and the new named argument syntax solves many of the existing problems.
  • Method references

Cons:

  • = vs. :=. Come on. In 2011, I still need to tell the compiler something it already knows? Also, looking at my code, I’ll probably use := a lot. So that means extra effort for me. Bad. Not everyone’s brain is wired for immutables.
  • “if (exists foo)” to check for null values. If I already have to use a special syntax to mark something as “can be null”, why do I need to mention that again in a condition? What’s wrong with “if(name)”?

Things that leave me puzzled:

  • local vs shared. I understand that the compiler can’t infer types for shared references in a single pass but who cares? The compiler is a tool that has to make me more productive. If the compiler needs two or three passes to resolve dangling type reference, so what?
  • How is the module system working? How do you bundle types in a container to keep the namespace clean?

Getting Rid of Checked Exceptions in Java

18. March, 2011

So, you’re tired of rethrowing checked Exceptions that you can’t handle? Did you wish a long time ago IOException and SQLException were in fact RuntimeExceptions (as they should be according to Sun’s own definition)? The pain was there but it got kind of dull over the years? Acceptance of the inevitable and all that. How about this:

    @SneakyThrows
    public void doSomething() { 
        throw new Exception();
    }

Did I hear a “WTF”? Say hello to project Lombok.

IBM developerWorks has a great article to get you started with your own custom AST transformations.


TNBT – Object Teams

15. March, 2011

Object Teams, or OT/J for short, is a solution for the old Java problem “there is no I in ‘team'”: Most Java code is written as if the whole world was openly hostile. It’s riddled with final, private static, singletons, thousands of lines of code which almost do what you need except for this one line .. that you can’t change without copying the other 999.

Groovy’s solution: AST transformation. A topic for another post.

OT’s solution: create a Java-like programming language which allows you to extend code that isn’t meant to. A great example: Extending Eclipse’s Java compiler.

The Eclipse Java compiler is one of the most complex pieces of code in Eclipse (“5 Mbytes of source spread over 323 classes in 13 packages“). Unlike other compilers, it can compile broken code. The same technology is used to create byte code and error markers in the editor.

Stephan Herrmann wanted to add support for @NonNull and @Nullable. Usually, you’d create a branch, keep that branch in sync with the main branch, etc. Tedious. For every change that someone makes in the main branch, you must update your development branch. Even if the change is completely unrelated. CVS has a very limited concept of “related”. DVCS like Git or Mercurial are better at merging but they also don’t understand enough of Java to give the word “related” a useful meaning. “Same file” is the best you can get.

So instead of the tedious way, he used OT/J to create an OT/Equinox plug-in which patches the JDT compiler byte code. Sounds dangerous? Well, OT/J does all the ugly work. You just say “when this method is called, do this, too.” Sounds a bit like AOP? Yes.

Unlike AOP, it communicates intent more clearly. The code wasn’t designed to be the most compact way to define a “point cut” and then leave it to the reader to understand what this is supposed to mean. It better communicates the intent.

I’m not completely happy with the syntax, though. I don’t have specific points, only a general wariness. Maybe a careful application of Xtext would help.

Related Articles:

  • The Next Best Thing – Series in my blog where I dream about the future of software development