Fork us on GitHub

Properties & Continued Terseness

When you have a saved search for "cross platform" sometimes unexpected things come up...
Properties & Continued Terseness

Properties & Continued Terseness

We've been working on some pretty exciting things recently trying to get them out of the door. As part of that work we added some API's specifically one that probably should have been a part of Codename One 1.0: Properties file support...

Working with properties files under Codename One should be identical to working with them under standard Java only instead of using java.util.Properties we need to use This allows the implementation to be updated more easily and more consistent across platforms. We also fixed some minor historic behaviors in properties e.g. making it derive from HashMap<String, String> instead of Hashtable which makes it both faster and removes the need for casts when working with it!
I find properties to be much easier to work with than XML for simple key/value cases.

Terseness Continues

I've been on a terse code mission for a while, trying to reduce verbosity in our code which now thanks to lambdas is truly standing out. As you recall we added an encloseIn API to Container, this allowed great code like:

Container c = Container.encloseIn(new BoxLayout(BoxLayout.Y_AXIS), myFirstCmp, mySecondCmp, myThirdCmp);

Which is way better than:

Container c = new Container(new BoxLayout(BoxLayout.Y_AXIS));

But its still not great, the part that bothered me is the layout creation code... What we really need is the layout and this allowed me to re-think this API and instead come up with this:

Container c = BoxLayout.encloseY(myFirstCmp, mySecondCmp, myThirdCmp);

Which I think expresses what we are trying to do just as well, while removing some boilerplate. Obviously there is also an encloseX method to correspond. I've also encapsulated a similar common use case for BorderLayout using:

Container c =;

Which is equivalent to:

Container c = new Container(new BorderLayout());
c.addComponent(BorderLayout.CENTER, centerCmp);

Another long term pet peeve I addressed was that Form is missing a layout constructor. This is problematic especially due to the fact that we repeated Swing/AWT's mistake of using FlowLayout as the default layout!
In terms of performance this means that every form created allocates a FlowLayout and then allocates a new layout to replace it. By adding the layout for the content pane in the constructor we effectively solve that issue and reduce a line of code.

And finally I also added an add(Image) method to Container which is similar to the add(String) method and is really a shorthand for add(new Label(img)). Its not a big deal but small things like that make the code slightly more readable.

Share this Post:

Posted by Shai Almog

Shai is the co-founder of Codename One. He's been a professional programmer for over 25 years. During that time he has worked with dozens of companies including Sun Microsystems.
For more follow Shai on Twitter & github.