JavaFX Review

I had high hopes for JavaFX as I started reading about it. At first glance it shares many of the same goals I have: better designer/developer workflow, more declarative applications with better object initialization and data binding. JavaFX uses the Java runtime for efficiency and doesn’t suffer some of the major performance problems of Groovy and JRuby. The designers invented enough new syntax here that it will not be as easy to learn and in particular as easy to adopt by Java programmers as I would like. There are a few key aesthetic changes from Java and a few cases where weird new syntax is used to save a few characters of what would otherwise be more readable code for a new programmer. A Java programmer would find it awkward to switch back and forth given its javascript roots. But after reading the documentation and looking at the samples it still felt workable. Clearly these decisions were made for script programmers and I agree they are an extremely important constituency in IT and under served by Java today.

But as I dug into the implementation I found one deal breaker for me. Though they can use and extend Java classes fairly well, JavaFX classes cannot really be used back in Java. They are not JavaBeans and don’t expose fields in a way Java code could access them. I think it is very important for client/server applications to be able to share code. That is one big advantage of Java over Flex. But it does not seem possible to build a domain model in JavaFX and share it between the client and server code. You could build the domain model in Java and then wrap it in JavaFX but now the domain model itself is inaccessible to the JavaFX programmers and cannot use the declarative features. How can we get robust/round-trip workflows from different types of developers with this partitioning? The JavaFX programmers would be waiting for the Java programmers to make some change and could not maintain the complete design when it is finished. In their prototypes, they’d use data binding and other features that would need to be recoded by the Java programmers.

Maybe they can fix this but right now I don’t need another incomplete wrapper language. JavaFX may be a decent way for script programmers to get the benefits of the Java runtime but it won’t empower the type of real synergy we need between the different skill sets that build and maintain software.

There are also a few less than optimal implementation details under the hood. I don’t particularly like how properties are implemented. They uses primitive fields in some cases but eventually container objects get allocated for each property which needs data binding. There is a hybrid mode where fields in the object are defined for both the container and the primitive. The get/set methods lazily init the binding and use that once it has been initialized. I didn’t see manual controls to enable binding like you do in Flex so I assume they detect binding expressions and enable the feature or not at compile time. This might work well in practice if you have all of the source and compile times are not too long.

Though bindings in JavaFX may fire a little faster than Flex once things are initialized, my reading of the code tells me there will be a higher memory footprint and more init time cost. I prefer the simplicity of the Flex approach – I could at least understand how that one worked by reading the code quickly.

In general in JavaFX, there was more code generated than needed to be in there including an extra class for each class which uses data binding. Complex property initialization semantics also bloat the code just a bit.

JavaFX may well be a good solution for some folks but I’m not banking on it to jump out of its niche, particularly given that it appears Java applets are still suffering from some basic problems. For example, my experience with the JavaFX samples on my Mac was disappointing. I encountered some minor install problems and had to redo it a few times. When I did get things working, the demos flashed as I scrolled the browser window which looked bad and init time did not feel quick and smooth. These are probably things you can address but if the demos look bad, I guess it is still hard to optimize your applets and remove visual glitches?

I am impressed by http://www.visualthesaurus.com which is also a Java applet. This is based on thinkmap (formerly plumb tree design) who are early applet pioneers with some custom infrastructure. So maybe Java on the client can be done right, Sun just hasn’t figured out how to do it yet? In any case, my advice is to take a wait and see on JavaFX. Once Oracle has ported over open office, maybe it will have improved 🙂

Scala Review

Scala is an impressive language built on top of the Java runtime. Many of the irksome problems in Java have been fixed in Scala.

I like:
* The language is concise and eliminates unecessary semicolons, type definitions and braces. For simple programs, the code is clean and easy to read.
* Scala classes can use and extend Java classes and can be made to work the other way around though a bit awkward in some areas.
* More flexible imports including a way to rename a class on import
* Addition of an “object” keyword so you can define static instances more flexibly (this replaces static members)
* Improved flexibility of get/set methods, properties and fields
* Interfaces replaced by more flexible Traits which do a better job approximating multiple inheritance
* More flexible abstract definitions

A few other Java changes are maybe good or bad:
* == In scala means .equals in java and “eq” in scala means ==. So make it more accurate but slow down the default case by requiring a method call for each comparison.
* A file can contain more than one top-level class. I personally liked that feature of Java as it makes it quick for both people and compilers to find the definition of a class.

Scala brings functional programming concepts to the Java runtime: Java meets Erlang. Well executed but it may limit the usefulness of Scala in the business world and in contexts which require strongly engineered solutions – i.e. high performance, scalable, low footprint, low CPU, and code readability and maintainability. With functional programming, you can create more elegant, concise, and likely more provably correct program. But you give up control to the implementation of the various high level language operators.

Scala has features which make it a great language for building languages. It seems almost enough to build an uber language which embeds DSLs from various disciplines. You can do operator overloading, and the flexible syntax lets you define keywords, etc. The samples seem quite elegant and well designed. But with these complex ways of layering code, it becomes hard to reason about performance costs, and hard to pick up any arbitrary piece of code and understand what is going on quickly. Various separator characters are optional so you often omit parens, dots, etc. I like that in many ways but wonder how it works out day to day when trying to find syntax errors. The language also has quite a grab bag of non-standard syntactical short cuts, most of which you can not just pick up by reading the code.

I like how they implement traits. Each trait maps to a simple Java interface and generates a class with static methods if necessary. Each concrete class gets the trait member fields which are then access via methods of the same name. The methods in the Trait definitions turn into static methods which take a “this” parameter. They are called by methods added to the concrete class which includes the trait. This avoids copying all of the code into each class which includes a Trait.

I use this pattern to avoid the need for multiple inheritance myself so it is nice to see it done automatically. But if you implement everything as traits, you double the number of method calls in your system plus and code bloats up by all of the wrapper code generated in each concrete class. Fortunately a Trait with no members is treated just like an interface though so this is good as long as you know the implementation cost and how to avoid overusing it.

Scala does generate a lot of classes. It is not shy on generating code to make your code smaller. Code in the Java runtime means not just executable size but also init time overhead due to lazy linking. It seems like the one or two simple benchmarks I’ve seen show a slowdown of ~20% loss going from Java to Scala with a higher memory footprint but I suspect it is highly variable depending on the code. IMO, footprint and startup time are Java’s biggest weaknesses so it is too bad it is getting even worse with Scala.

That said, that number is much better than other languages built on top of Java. The one big thing they got right is to use the Java type system and they avoid creating an object for each property – in some cases at least. From reading the book and looking at the code it is still not clear to me when you are dealing with an “int” or an “Integer” since this is behind the scenes. That can make a huge performance difference so I wish those rules were more transparent.

All in all I do think the designers of Scala have done a tremendous job in advancing the state of the art of language design. Not that many people seem as concerned about these efficiency issues as I am so you may take them with a grain of salt. I look at the language as the main tool in my toolbox to make my business competitive so I want it to be as flexible and efficient as possible. So I’m stuck in C and Java as general purpose languages – C for runtime efficiency and Java for the best mix of runtime, reliability, maintainability.

So for me personally, I would consider using Scala for coding and presenting academic work (assuming I had time for the learning curve). I would not use it for a typical commercial project as it stands now. With discipline you could certainly use the nice parts of the language and build efficient, maintainable systems with a minimum of overhead. Unfortunately this means everyone creates their own discipline which means we don’t have a nice consistent way of using it so code is not as “developer portable”.

That said, there is reason to think I could be wrong on this last point. Ruby also seems like a flexible language that lets you implement languages on top of it. Like Scala, even someone who knows the Ruby core might pick up a piece of code and have no idea what it is doing till they learned all of the new operators introduced. Given Ruby’s success, maybe Scala will create sub-niches that use/invent particular language patterns that work very efficiently? I am not following that particular trend myself because I don’t think we need this plethora of languages – just a few really good ones that are as intuitive as possible. In particular, we need to standardize on core operators so we can start exchanging software parts more effectively. A language which defines many sub-dialects may being working against that goal. An open language is harder to learn and keep control of in an engineering setting.

I believe that Ruby succeeds because we haven’t got these core operators exactly right yet. Ruby makes adding new abstractions easy and intuitive and folks have put together some really good ones that really help developers be more productive. But though it may be a great proving ground for language abstractions it is not something you’d use to implement a strongly engineered system given its fully dynamic, interpretive nature. Just check the benchmarks.

Anyone think I’ve misjudged Scala? Any other languages you think I should be looking at?

Moving on from Adobe

This was an extremely tough decision as I will miss the incredible folks and am leaving a product which is so well positioned in the market.

I have been blessed by working with some of the most amazing engineering organizations all of which embraced my ideas in the decision making process. Shortly after the merger, I realized that the LiveCycle management was not a good fit. My reasons for staying 3 1/2 years have been the tremendous people, the opportunity, and the technology itself. I can only bear to leave now as the most difficult and important design work is done and the product is in the good hands of the awesomely efficient LCDS team.

I don’t have specific plans though will be looking for a small company or more likely starting a small company either using one or more of C/C++, 3D graphics, data/scientific visualization, Java, maybe with some Flex or in some new area like machine learning. I’m looking for challenging problems that monetize platforms, services and solutions and am looking at keeping costs low so the technology stays relevant in the long term. I will look for the most efficient technologies – both in terms of ease of programming for all types of developers, and the efficiency of the runtime (think green!). I’ve got a few ideas for areas which are ripe for disruption and am always looking out for the next big thing. I’m looking to self fund for now and won’t be hiring until I have something I think is a sound long term, successful business.

I also plan on doing some blogging now that I have some free time. Mostly I’ll write about software platforms and design patterns, Java, Flex, C, ATG, AVS etc. I may also do some blogging on software management styles using some lessons I learned from my Dad and reinforced in the school of hard knocks. Good management skills are like oil in your software engine.