Is there a market for Java tools?

Now that the smoke has settled on the news of Google’s acquisition of the Java GUI building expertise of Instantiations, it is probably time for wild speculation. If Google was only interested in Instantiations’ GWT Designer, they could have bought only that product and the development team behind it. But Instantiations has sold all their Java/Eclipse products and staff to Google. This could also be another proof of the fact that it is extremely hard to make real money in an eco-system that’s associated with FREE.

FREE is a price tag that makes people put aside their intelligence for a while. It works even better than CHEAP. The tools from Instantations were not really expensive, even though they are best of breed in the Java GUI Design arena. Our customers were and still are extremely satisfied with WindowBuilder, SWT Designer or Swing Designer. We’ve had very faithful customers who’ve renewed their support every year.

But we also had many prospects who wanted SWT Designer or RCP Developer but were not able to get a budget of a few hundred bucks per seat, because all their eclipse tools in use were free. So even if they saw the benefits of atool they wouldn’t want to pay for it. They’d rather throw lots of person days at the problem.

But somebody has to pay the people who build and support these great tools. They won’t do it just for the love of it (well, I know some people who might, but they don’t count ). Eclipse has been largely paid for by IBM and many other companies, and thus by their customers, so neither Java, nor Eclipse, nor any other high quality tool really is for free. You subsidize them by buying DB2 or Oracle or any other products.

So coming back to my speculation: This whole thing might just mean that all the investment in developing and supporting WindowBuilder didn’t really pay back or there were signs for a negative trend. So while many people are excited in hopes for a free WindowBuilder in the near future, there will probably also be some drawbacks. Even Google will need a business model for supporting users of these tools.

An interesting question here is: being a web centered company, where could the benefit of a rich client GUI builder be? What could be an attractive reason for Google to give away SWT Designer or SWING Designer? There even is no real competition to cause any trouble to, because WindowBuilder didn’t have much competition. No question: GWT Builder is a tool that’s attractive for Google. But Rich Client tools that work completely offline? Maybe in the form of a GUI Builder for Android gadgets…

I hope I am wrong and Google’s altruism will make them open source and/or give away WindowBuilder. Maybe there will be some support contract constellations for large customers which will finance the tool. But why, exactly, should that work better at Google than it did at Instantiations?

We’ll hopefully know more soon.

Instantiations sells their Java Business to Google

Google and Instantiations today announced that Instantiations is being acquired by Google. So this is what the Instantiations website looks like this morning :

In a first short interview with Mike Taylor, CEO of Instantiations, I found out the following:

• Google is acquiring Instantiations’ Java business. The agreement includes all Java products, trademarks and staff
• All Java products from Instantiations are not being sold any more, at least for “a while”. I am sure they won’t disappear, but for the moment all sales of licences and support contracts has stopped. All reseller agreements were terminated.
• Instantiations’ Smalltalk Business is going to be spun off as a new, independent (privately held) company called (surprise!) Instantiations
• The management team and technical staff of that new Instantiations will be essentially the same as the one of yesterday’s Instantiations

So what does this mean for Java developers?

Since I do not have any insight into the deal, I can only speculate. In the best of all possible cases, some of the tools will be open-sourced sooner or later, my hottest candidate for the first one is the GWT Designer, which is Instantiations’ tool for visually constructing applications for the Google Web Toolkit.

I am quite sure tools like WindowBuilder or WindowTester will not go away, because there is a really big user base out there. Many big shops do use Instantiations’ tools for boosting their productivity and improving the maintainability of their code.

Here’s what Instantiations announced in a mail to all customers of their java products:

From our new Google home, we will be able to leverage our Eclipse Java industry knowledge, award-winning technology and world class development team to continue advancing the state-of-the-art in software development tools. But first and foremost we want to say how much we appreciate your patronage and support through the years. Thank you!

How does this affect you? Please rest assured that your existing Support Agreement will be honored. Our highly responsive tech support team is in place and ready to take care of you.

New downloads for the Eclipse Java products will disabled for a short time during the transition. Please stay tuned for exciting new announcements coming soon on the Google Web Toolkit blog.

As in the past, you may use both e-mail support and product forums to address support issues. Please note the new support e-mail addresses and forum URLs below [not added to this blog post to avoid spam. We will notify you when they become active. In the meantime, please continue to use the existing Instantiations product support channels.

I will keep you updated as soon as I hear more details. We need to know more since we need to tell our customers about the future oft heir tools, so you can be sure we’re going to find out more.

So what does all this mean for objektfabrik?

For now, it means we’re not a reseller of any of these products any more:

• The Window Builder family (including SWT Designer, Swing Designer and GWT Designer)
• The WindowTester family
• The CodePro family
• RCP Developer

No matter what happens to the tools at Google, we’ll continue to provide knowhow in their use to our customers, and we’re going to use them in our Java projects as much as we can.

Stay tuned for more news

The state of GUI Frameworks in today’s Smalltalk IDEs

Over on the VisualWorks NC mailing List, Marten Moostert started a thread on the current state of GUI frameworks on VisualWorks that has motivated quite a few people to jump into the discussion. The discussion now goes on in at least two more threads on the same list.

To sum up a bit what people are complainig about is that the current hype towards Web Technologies, especially seaside, might lead to the fact that Cincom has throttled their focus on medernizing their GUI frameworks quite a lot. A reason for additional frustration is the fact that Cincom has totally stopped work on their GUI framework for several years, because they were workin on a complete rearchitected GUI Framework named Pollock which was a nice piece of work, but was stopped after a few years, making some customers very unhappy while others were glad not having to rearchitect their applications. The really bad thing, however, was that there was no real visible progress in the old framework, and the new one wouldn’t come (a situation that’s not too unknown to some shops who wanted to rewrite their long-standing Smalltalk systems in Java, but that’ another story…).

To make a long story short, I must say that a standstill in GUI frameworks is not a thing that Cincom has a patent on. It’s a truth in other Smalltalk environments as well. Squeak, Pharo and others have their own chaters in this book. VA Smalltalk is no exception.

SWT auf Cocoa 64 bit mit Galileo

So, nun ist es wieder mal soweit. Ich weiss nicht weiter.

Inzwischen läuft mein Eclipse Galileo ziemlich rund. Alles ist JVM 1.6 und 64 Bit. Auch der WindowBuilder läuft rund, und ich kann die meisten meiner SWT-Dialoge nutzen. Klar, das übliche “Mac-Buttons sind aber ein bisschen höher als die von Windows” und “Labels sind ein bisschen breiter auf dem Mac”, aber es hat mich ja auch keiner gezwungen, ausgerechnet ein GridLayout zu nutzen…

So ganz habe ich den richtigen Weg für wirklich portable SWT-Oberflächen noch nicht gefunden.

Also eigentlich alles toll und großartig, wäre da nicht noch eine Kleinigkeit:

java.lang.ClassDefNotFoundError: org/eclipse/core/databinding/property/value/IValueProperty

beim Start einer Shell mit DataBindings aus SWT 3.4 (übernommen vom JDK 1.4). Der Allmächtige G konnte mir auch nicht weiterhelfen. Imports sind soweit okay, denke ich, ein Package mit dem Namen

org.eclipse.core.databinding.property

gibt es nicht, weder auf meinem Mac, noch sonstwo, sagt G. Und irgendwie scheint das alte DataBinding-Zeugs auch nicht deprecated zu sein.

Wer weiss Rat? Wahrscheinlich wieder irgend so ein kleines “Achja, stimmt, wenn Du auf orgMyMac64.galileo.org/swt/cocoa diese 24 dingers da nach Dropins legst, dann geht’s. Steht übrgens schon seit April auf TheUltimateEclipseGuru.org”

Naja, vielleicht finde ich morgen auf dem Eclipse Summit jemanden von UltimateEclipseGuru

Galileo / SWT jetzt auch Cocoa-fähig

Es gibt ein Leben ausserhalb des Smalltalk-Image. Auf dem Mac gibt es das sogar recht oft, denn ein Smalltalk mit nativer Oberfläche gibt es leider noch nicht, seit der Status von Ambrai ja ein sehr fragwürdiger ist.

Darum, und weil man einfach ab und an auch mal was in Java machen muss oder möchte, ist Eclipse immer mit an Bord.

Heute ist ja Galileo-Tag, d.h. die neuste Version von Eclipse wird heute als offizieller Download freigegeben. Neben vielen Verbesserungen in einigen Projekten, die man vielleicht auch nicht unbedingt braucht, gibt es aber insbesondere für Macies gute Nachrichten: SWT unterstützt nun Cocoa. Bisher wurde nur Carbon unterstützt, was nur unter 32 Bit und damit nicht mit Java 1.6 lief.

Ab sofort können also mit Eclipse und SWT echte Cocoa-Oberflächen gebaut werden, und das auch in 64 bit.

Damit ist meine spärliche Freizeit für die nächsten Tage also verplant, denn es warten ein paar kleinere Projekte auf ihre Cocoaisierung…