Category: Java

My recent interest in Signals and Slots led me to a few other more detailed docs on the subject

• Signals and Slots – TrollTech Docs v4.6
• QtJambi Docs – the Java spin of Qt
• Meet QtJambi
• QtJambi reference docs
• Qt Jambi desktop environment

A λ (lambda) is an anonymous function. In addition to Closures, Oracle are looking at including lambdas in JDK 7, which would bring more functional goodness to the feature stagnant Java. This InfoQ article sums up the situation nicely.  It talks about the difference between lambdas and closures – a closure is a function that doesn’t rely on any external arguments – it is a closed function.  However, a lamda is an open function. 

λx. x + y   (open function, depends on y)

λy. λx. x+y (closed function, the inner open lambda is satisfied by y being supplied in the external function)

The former reminds me of Groovy’s closure currying

The proposed syntax looks something like this

inc = #(int x) (x+1); // single expression
inc2 = #(int x) { return x+1; }; // block

The rest of the article talks about the proposed syntax for lambdas and the concerns with implementing in various code constructs that potentially conflict with existing Java language syntax and rules.

Start Here: http://java.sun.com/javase/technologies/desktop/javawebstart/index.jsp

Java Web Start Guide

Java Web Start Developers Site

FAQ: http://java.sun.com/javase/technologies/desktop/javawebstart/faq.html#72

JNLP Specification

Java Web Start Tutorial

Unofficial Java Web Start/JNLP FAQ: http://lopica.sourceforge.net/faq.html#turn-off-splash

I’m a bit late to the game here, but it seems a ‘spiritual successor’ (my term) to JGoodies form layout called MigLayout has been around since at least 2007 and is currently campaigning to be in JDK7

The following article gives a quick rundown of MiGLayout compared to Swings traditional layout managers: MiGLayout: The one Java layout manager that does it all

This is something that’s usually taught to first year Java students.  Though I had a small mental blank about how it was implemented. I knew that to get around the ‘limitation’*, you could specify a class with multiple interfaces, but that was only half the solution. What about the implementation?

Surprisingly it was hard to get a clear answer from the fractal patterns that Google found, a lot of developers saying, “oh yeah, you need interfaces” but it didn’t sound like they knew themselves.

So, this was my way, probably duplicated a zillion times, but here you go, here’s a way:

We are going to have three classes, A, B & C (sorry for the lack of imaginative names here).  Class C will extend both A & B.  We’ll extra interfaces for A & B dubbed Ai & Bi respectively.

First an interface for the classes we are going to ‘extend’ from.

   1: public interface Ai {

   2:     public void aMethod();

   3: }

   1: public interface Bi {

   2:     public void bMethod();

   3: }

and now some implementation:

   1: public class A implements Ai {

   2:  

   3:     public void aMethod() {

   4:         System.out.println("aMethod");

   5:     }

   6:     

   7: }

   1: public class B implements Bi {

   2:     public void bMethod() {

   3:         System.out.println("bMethod");

   4:     }   

   5: }

And now for our binding class, C.  The class implements both interfaces, and takes in implementations of each of the super-classes as constructor arguments. The implementations of each method defined in the A and B interface is a delegate to the relevant A or B class that was injected in the constructor.

   1: public class C implements Ai, Bi {

   2:     private final Ai a;

   3:     private final Bi b;

   4:     

   5:     public C(Ai a, Bi b) {

   6:         this.a = a;

   7:         this.b = b;

   8:     }

   9:  

  10:     public void aMethod() {

  11:         a.aMethod();

  12:     }

  13:  

  14:     public void bMethod() {

  15:         b.bMethod();

  16:     }

  17: }

The call to the implementing a.aMethod() is effectively a super() call.  You can then append your own extra implementation, or remove the delegating call and define your own.

So what about the diamond problem, when both A & B define a method that is named that same thing.  In Java if you try to say a class implements interfaces that have duplicate signatures you’ll get a compile time error.  If Ai and Bi both had a method called cMethod() then the C class would refuse to compile.

Other ways

My research found other mentions.  If you got lazy, you could have C extend A, and implement Bi.  Then you wouldn’t have to write the interface Ai and C would be a little smaller since it would only inject the B implementation and have a bMethod() delegate.

Another way was to have the 2nd class as a static inner class.  Although I have no issue with this implementation working, as soon as I see ‘inner’, I’m led to believe its re-use value becomes a bit more limited and certainly more cumbersome to refer to.

Notes

BTW, if you want to find a decent explanation of what to do and an interesting reading of a Mixin pattern implemented in Java, then see here.

* I say ‘limitation’ in quotes because apart from the well known diamond inheritance problem that crops up with multiple inheritance in C++, from what I read, using multiple inheritance could be a code smell.  Certainly the ambiguity that comes from not knowing exactly which one will be called or whether or not you’ll know at compile time, or run-time is a concern.  (Don’t delay the Bad-news)