1 2 3 Previous Next


234 posts

We are proud to announce the release of Leonardo Sketch 1.0.  Leo is a open source cross platform vector drawing tool built for designers and programmers. With Leo you can draw, diagram, and create presentations; then export your final work to a variety of formats including PNG, SVG, PDF, Java2D code, and JavaScript Canvas code; as well as sharing your work in progress with Twitter and Flickr.

Leonardo Sketch is distributed under the BSD license and can be downloaded from LeonardoSketch.org.

New features for the 1.0 release include:

  • redesigned rotate and scale tool
  • fill shapes with complex gradients and patterns
  • direct manipulation for almost everything
  • export to editable JavaScript using the open source Amino graphics library.



Now you might, ask, why am I posting about a drawing tool here on Java.net?  Because Leonardo Sketch is 100% Java! End users will never know it, of course, because I created native exes with AppBundler, but it's all Java underneath  That makes it very easy to hack on, and ensure it runs everywhere.

The other reason I'm posting it here is because Leo can export graphics code as well as graphics files. Currently it will generate HTML, HTML + Canvas (JavaScript), and Java2D.  I'd like to support other formats going forward, such as FXML, but I'll need some help from you guys. The advantage of generating graphics is that you can draw rather than code up the UI, then attach logic and event handlers as desired. By using a naming convention in your graphics you can update them later without changing the code. You can even have control over the output such as prerendering expensive things (like shadows) to images automatically.  Here is a little tablet app I wrote in an hour thanks to Leonardo.


  Looking for a fun open source project to contribute to? This is the one! Not a great coder but you still want to contribute? Great! We need help filling out the language translations, drawing more symbol sets, creating more textures, and filling more bugs.  There's tons to do. Join the fun!

For the past few months I've been working on an open source UI toolkit called Amino. It has lots of cool features like a scenegraph, CSS control skinning, and dynamic translation editing. You just have write your app in Amino and you get the cool stuff for free.  But what if you have an existing Swing application and don't want to rewrite it?  Don't worry, Amino's got you covered.

Amino now has beta integration with Swing.  You can drop any Amino scene into a Swing panel, then mix it with the rest of your app.  The key is the JComponentWrapper class, which implements JComponent and contains Amino Nodes.

Rectangle aminoRect = new Rectangle(0,0,20,20).setFill(FlatColor.BLUE);
JComponentWrapper wrapper = new JComponentWrapper();    
JPanel panel = new JPanel();    
panel.setLayout(new BorderLayout());    

That's all you have to do. JComponentWrapper will process all of the repaints and map Swing events to Amino events.  Here's a screenshot of a more complicated example that embeds a custom Amino chart in the middle of a frame with other Swing components.


To learn more about Amino, you can:

We are making progress on the next release of Leonardo, an open source desktop Java drawing program.  One of the key features scheduled for the next release is a webservice that lets users save and share reusable symbols they've created. For example, someone could create a set of GWT mockup widgets, then share this set with others.

The challenge I face is that I'm mainly a client side developer. I could write a basic webservice that would persist the symbols, but I wouldn't necessarily build it the right one. To be a good service you need to handle failures, spamming, load and concurrency issues, and more. I'd also like to let users log in with OpenID rather than creating yet another username and password, which adds more complexity.

So, I'm posting here looking for an engineer or two who'd like to work on such a service for Leonardo.  I'm open to building the service in anything: JavaEE, plain servlets, JRuby, Jython, or even CouchDB.  All that matters to the client is speed and features.  If you are interested in helping out, please comment on my blog here and I'll get in touch with you.





Ruby Red is Here! Blog

Posted by joshy Nov 22, 2010

Ruby Red, the first full release of Leonardo Sketch is ready for download.   Leonardo is a desktop open source drawing program written entirely in Java. In this first version of Leonardo, features include:

  • Full vector drawing with shapes, paths, groups, and images.
  • Export to PNG, PDF, SVG, and HTML Canvas.
  • Sharing via Email and Twitter
  • Integrated Flickr image search
  • Installer builds for windows, mac, and cross platform.

If you find bugs or want to request features, please file a request in the issue tracker or use the Make a Wish button in Leonardo itself.

I'd like to thank all of the contributors for their continual testing. We'd also like to thank several of our international users for contributing translations. We now have English, German, Czech, Turkish, and French.  If you are interested in contributing a translation for another language, please join the Leonardo Developer Google Group and let us know.

So download Leonardo Ruby Red now. and please spread the word.

AKA: a Teachable Moment in Performance Tests, Profilers, and Debugging statements.

The other night I couldn't sleep, so I started to write some code.  Most great programming insights begin like this.  I added some new CSS selector types to the Amino skinning parser, then went to bed.  A couple of days later I noticed Leonardo, the drawing program built on Amino, was running visibly slower. Clearly I had screwed something up with my recent changes. Time to put on the work boots and dig in.

It has been said: the only way to make your code faster is to never let it get slower. And the only way to do that is to create performance tests that you can run on both the old and new versions of your code. Fortunately I started adding configurable tests a month ago, letting me run a layout test on any revision I choose and compare it to any other revision.  By running the test on the last several versions I could narrow down exactly which commit had caused the problem.  Easy enough. Now I can fix the problem. Or so I thought...

Once isolated, I quickly deduced my CSS evaluator was doing extra work looking for parent nodes that don't matter in most cases. I simply commented out the extra function, then ran the performance test again. Hmm. It's still slow!  But I turned off all of the functional changes,  right?

After analyzing this code for two hours I gave up doing it by hand and pulled out a real profiler. Never guess where you think code is slow. Use a real tool.  Fortunately the VisualVM tools, built on the excellent NetBeans RCP, is easy to use and built into all modern Sun derived JVMs. I launched it with jvisualvm on my Mac, installed the VisualVM-Sampler plugin to get NB style per method profiling, then was off to the races. It seems that 90% of the time was being spent in string concatenation from a couple of debugging lines inside of nested loops. Here's an example:

p("current match is " + match);

The odd thing is that p() is a no-op!  It looks like this:

public static void p(String s) {
     if(DEBUG) System.out.println(s);

and DEBUG was set to false. How could this code be causing the problem?

I commented out the p() lines and confirmed that they were the root cause, but why were they slow when they didn't do anything? After a bit of puzzling I finally figured it out.

The key is the '+ match' part.  The compiler turns + match into + match.toString().  I had recently modified match to dump a ton of debugging information in it's toString() method.  Even though p() wouldn't do anything with this info, the toString() method is still called.  Only commenting out the lines completely removed the excess work and the performance problem was solved.

The lesson?  First: always profile your code to find the real hot spots, using something like VisualVM. And second: have flexible performance tests to find regressions.  Without a test I could run on any Mercurial revision it would have taken far longer to find the bad commit.

The upshot of this exercise is that Amino and Leonardo are now visibly at least twice as fast as before! Go Java Tools!


The Deprecation Blog

Posted by joshy Nov 3, 2010

The Deprecation

If you're reading this blog then there's a good chance you've heard Apple has deprecated their implementation of Java on the Mac.   Contrary to the resulting outrage over the last few days, I don't find change to be a shocking surprise.

Ultimately Apple puts in the technology that will let them sell more computers. As a consumer company they support technology that runs consumer apps.  The desktop Java community simply hasn't created the thousands of consumer apps that exist on the Mac or the iPhone. these are almost entirely Cocoa or straight C+ OpenGL apps.

We are to blame

I challenge you to come up with even a list of 100 consumer apps written in Java. Without significant desktop Java apps Apple simply has no incentive to continue funding their Java port.  The truth is, desktop Java has been dying for years, and Apple has finally accepted it. And I say this as someone who's worked on desktop Java for nearly my entire professional career. Desktop Java is dying, and it is our fault.

There are a variety of reasons for Java's failure on the desktop; reasons ranging from Sun to IBM to Swing to Deployment bugs and many other causes. I won't rehash them here because the end result is the same: no significant consumer desktop Java apps after nearly 15 years.  Apple simply made a pragmatic decision to no longer support a technology that costs them more than it brings in.  No Steve Jobs conspiracy theories required.

Apple's Goals

Apple's message to developers is very simple: use web technologies or use Obj-C/Cocoa.  That's how it is on the iPhone, iPad, and now on the Mac. While they will probably never bar you from installing your own JRE, by default the Mac is set up to run Cocoa and the web really really well, with nothing else needed.  That's Apple's decision for their computers and all of our ranting won't change that. Honestly I'm surprised it didn't happen sooner.

Desktop Java has to earn it's place on the desktop.  It's always been the case that a JRE may not be on a PC.  Now there is the potential that this may be the case on Mac OS X (perhaps as soon as next summer).  If we want this fixed, then we need to do it ourselves, as a community.

Where do we go from here?

If desktop Java is going to be relevant then we have to start making great desktop apps.  We shouldn't look to Oracle, IBM, or Apple to make this happen. They've been supporting us for years with little direct revenue to show for it (the toolbar deal was the only thing that ever brought in money for desktop development).  If we want desktop Java to be around for another 15 years, then it's up to the community to make it happen.  Nut up or shut up!

My personal contribution to fixing desktop Java is by creating an new UI toolkit and graphics stack which drops the  Swing/AWT legacy. This new toolkit, called Amino, has a modern fluent API, CSS style-able components, and is fully redistributable with a liberal license (BSD). When I first designed Amino I assumed we might one day be without a default JRE on Mac, so I built it to work with multiple backends.  It should be possible to replace AWT with standard OpenGL or SDL without too much work. In theory it should be possible to run an Amino app on SoyLatte without too much work.

Making desktop Java relevant again is very possible but it's up to us, the desktop Java loving community, to make this happen. I'm looking for some volunteers to help me make direct OpenGL & SDL work on SoyLatte without X11. With that done it will be possible to bundle apps with a JRE. Never again will we have to depend on anyone else's software installation to make our apps work.  They are our apps, so it's up to us to make them work.  Without a community developing such technology, then desktop Java is truly dead.

When you go to the polls today shouldn't you make sure you have the support of a drawing program that will fight for your interests in Washington?

Other applications receive the majority of their funds from "Special Interests" like the Association to Flash America and Acrobats for a Longer Download.  They've voted with "Big Drawing" over 108% of the time, and they pass the buck on to you, the hard working tax payer.

Don't you deserve a drawing application created by "The People and for the People"? Leonardo Beta 2 improves layout speed by up to 50%, and adds "Export to HTML Canvas" so that your drawings won't be locked into their file formats.

Voice your opinion now by downloading Leonardo Release 1, Beta 2.

This message was written and paid for by Patriot Kittens for a Truthy America and Freed Drawings from Planet Earth

A decade from now 90% of people will use phones, slates, or netbooks as their primary computing device. This is a very exciting development in the software world and promises to reshape the way we make software (check out the great stuff our lead developer is doing in his day job at Palm), but Amino isn't for that world. Amino about that 10%: the content creators who need killer desktop apps, the programmers who want great tools, and the knowledge workers who need to manage incredible amounts of information at lightning speed. Amino is the toolkit to build these apps.

Amino is a next generation graphics library and UI toolkit. Though originally built as support for Leonardo Sketch it is now it's own incubator project.  Amino is an (extremely alpha) 100% open source Java library that provides:

  • a 2D/3D scenegraph with multiple backends (Java2D, JOGL, and more coming).
  • a set of UI controls, skinnable with CSS.
  • Utility classes to help you build desktop apps quickly.
  • is extremely testable.
  • 100% open source (BSD), redistributable, and embeddable.
  • 100% Java, ready for use by any JVM dynamic language (Groovy, JRuby, Jython, JavaScript, JavaFX Script, etc.)

The source is available here. The JavaDocs are available here.

You can read the getting started tutorial which shows you how to build a basic app. Amino will look very straight familiar to Swing developers, but with a few enhancements:

  • Uses an event bus instead of listeners on each component, enabling better separation of model and view
  • A background task API to handle threading for you.
  • Mixes a retained mode scenegraph with immediate mode paint APIs so you can work at the abstraction level you prefer.
  • There are no Look & Feel classes. All UI skinning is done directly with CSS 3, even the default L&F.
  • If you use the (experimental) JOGL backend you can directly mix 2D graphics with OpenGL code.
  • All controls can be referenced by ID, similar to JavaScript libs, enabling further separation of concerns.
  • Amino has a tool called AppBundler which generates Mac OSX .app bundles as well as JNLP builds. The user should never know that your app is written in Java, or any other language. They will just love your app.

How is Amino different than JavaFX and other UI toolkits?

Amino is not innovative. On the contrary, Amino takes the best ideas from the past 20 years of UI toolkits, throws out the stuff that hasn't worked well, and bundles the rest up in a nice clean package with no legacy issues.

Amino is inspired by JavaFX and Swing, among other toolkits. At JavaOne 2010 Oracle announced a new Java only direction for JavaFX 2.0, which makes JavaFX even closer to Amino. Though similar, there are some differences:

  • Amino is BSD licensed and community developed, allowing you to do things you can't do with the Oracle owned JavaFX, such as: subsetting, bundling with your application, embedding on a mobile platform, recompiling with GCJ or Kaffe, or forking it for your own uses.
  • Amino is focused expressly on desktop apps. JavaFX is focused web based and mobile applications, similar to Flex and Sliverlight.
  • Amino is significantly smaller than JavaFX. It aims to be fast, easy to learn, and very, very lean; at the expense of backwards compatibility and features.
  • Amino is embeddable in Swing panels, so you can add just a little bit of Amino to your existing apps.

How can I help?

Amino is extremely alpha. Though the ambition is high, the current release is slow, ugly, and buggy. So the first way you can help is by just checking out the website, downloading the library, and trying to build something. Then file bugs! Only by building things can we find out what's broken or missing.  Next, if you are interested in helping to develop Amino itself, there are a bunch of areas open to work on:

  • Event Bus: needs a new implementation. The current one is slow, not scaleable, and probably has memory leaks.  See the wiki for details.
  • Scene Graph: the current scenegraph is minimal, just enough to get the controls to work. We need the rest of the shapes (path, oval, arc, lines, etc.) and transforms (rotate, shear) built and tested. See the wiki for details.
  • Maven support: I don't use Maven but a lot of people do. It would be great to get Amino and it's dependent libs built into a Maven repo.
  • CSS parser: I'm currently using a new from scratch CSS 3 parser. It needs to be finished to support some missing properties, as well as refactored to be more maintainable.
  • Installers: the AppBundler currently supports JNLPs and Mac OSX .app bundles. We'd like it to support NSIS generated MSI bundles and Linux launch scripts, but we need developers from those platforms to work on them.
  • More Controls: we have a fair number of controls, but a lot is still missing like menus, task panels, search fields, charts and more.


Please try out Amino and give us feedback. It will really help us make Amino into the best UI toolkit for desktop apps.


Anouncing Leonardo Blog

Posted by joshy Sep 4, 2010

Today I am proud to announce a project I've been working on for the past  few months called Leonardo. I've long believed there's a need for a good  desktop drawing app that is completely cross platform, free, and open  source. Leonardo is that app.

You can read the full project announcement on my design blog here:



XML Utility Library Blog

Posted by joshy Jun 28, 2010

There's been a ton of talk lately about several mobile operating systems and their problems, such as language restrictions, fragmentation, and anti-competitive practices.  It's never a good idea to talk bad about your competition, so I'll take this opportunity to simply say a few things about the webOS (the OS that powers Palm's Pre and Pixi phones) that you might not know.

As always, I am writing this as Josh the blogger. These are my opinions alone and do not reflect the opinions of Palm Inc.

  • webOS devices are part of the web, not tethered to a desktop.  You install apps through the web. You your data is backed up to the web. OS updates come through the web. Your address book is a merged view of your contacts living in the web.  You never have to sync to a desktop computer. I know some Pixi users who have never once plugged their phones into a computer, because their phone is already a part of the web.
  • The webOS treats it's users like grown ups: they can install any apps they want.  What if the app duplicates a built in app? Fine. What if the app isn't in the on device catalog? Fine: you can install apps from the web or beta feeds without any restrictions and do the marketing on your own. What if the app hasn't been reviewed, came from my cool programmer friend, and might hose my device?  Well, if you enter the developer code into your phone then you've accepted the risk and can install any app you want.  There's a whole community of people making cool but unauthorized apps. They are called the Homebrew community, and Palm encourages them. You're an adult. You can make the decision of what to install on your phone.
  • The webOS lets you use any language you want to develop apps. While Palm doesn't provide tools for languages other than JavaScript, C, & C++, there are no restrictions against using any other language. Our new PDK gives you a clean POSIX layer with direct & standard access to input (SDL), the screen (OpenGL), and device services (API bridge). There's nothing stopping you from porting a C# compiler or a Lua interpreter. Developers are free to use whatever tools they wish. The results are what matter. Good apps are good apps.
  • The webOS doesn't have fragmentation. All webOS devices run the same OS, regardless of form factor. They are all updated over the air, for free, in all countries and carriers. This means that 99% of webOS devices have the current version of the OS within a few weeks. There is no fragmentation of the operating system across devices or form factors. This lets developers focus on making great apps, not waste time supporting 18 versions of the OS.
  • The webOS is built from the DNA of the web.  Yes this includes using HTML, JavaScript and CSS as the primary application development layer, but it's more than that. I can just start typing to have my question answered by wikipedia. The address book contains your contacts that live on the web. If my wife changes her Facebook profile photo, my phone is automatically updated. I can write an app that links to other apps through Javascript calls.  The web is about connections to the people and services you care about, not just HTML pages.  So is the webOS.

At Palm we care greatly about the end customer experience. We are also developers, so we care greatly about the developer experience. And most importantly, we don't see the two at odds.  Happy developers create great apps that create happy customers. It's a win, win.  That's why we are doing everything we can to make happy developers. We don't always do everything perfectly, but when something is broken we do our best to fix it and be transparent. It's how the web works and it's how the webOS works.

So, as a developer, I hope you'll think about the benefits and freedoms of the webOS, and consider it for your next mobile application.


I'm excited to show you all one of the things I've been working on since I joined Palm.

Palm Hot Apps

Today we launched a new microsite called Palm Hot Apps. This is a leader board for our Hot Apps promotion, where the top selling & downloaded apps compete to earn bonuses between $1,000 and $100,000 dollars.  Since this is a competition we wanted to have a constantly updated site that shows who's winning right now and who might be winning in the future.

If you are a JavaScript developer, or interested in mobile app development in general, or just a Palm enthusiast, you'll definitely want to check out the site. As of this posting you can earn a bonus in the entry level bracket with only $500 in sales for a paid app, or 12k downloads for a free app (see the site for full details). The competition is still wide open, and webOS is really, really easy to develop for, so I urge you to build something cool and compete.

Since this is a Java blog you might be interested to know that I wrote the entire backend for the microsite in Java. I'm also happy to say that I didn't use any frameworks at all.  There's a certain sense of zen peace that comes from using pure JSPs and servlets.  Where the code really is a direct expression of what is really happening underneath.

I went with what my amazingly talented engineer friend Brian Goetz has often said: build the simplest thing that could possibly work. In this case I considered the following constraints:

  • This is a promotion with a deadline, so the site needs to be launched ASAP
  • To minimize risk, use technology I know very well
  • The site will be high volume, so minimize state
  • We need a way to expose data to 3rd party JavaScript widgets and other websites in the future.

These constraints led me very quickly to one solution: Linux + Tomcat + JSPs & Servlets. The choice of Java is a natural, since it's fast and my 15 years of experience means I can knock out code in Java faster than any other language.

Linux and Tomcat are known quantities. I personally still hate Tomcat's configuration system (why can't I specify init params without having them nuked when I update the WAR!!!), but it performs very well and every conceivable issue has already been found, fixed, and documented on endless websites.

The choice of JSPs and Servlets was a bit more subtle.  Since there is almost no state in the site I didn't need the state management capabilities of the typical web framework. The graphics would be coming from a designer so JSPs were a natural fit for turning pure HTML into a webapp.  I used servlets for all of the data access because it easily lets me create JSON webservices that can be used on the site or in embeddable widgets.

Now, don't get me wrong. Frameworks have their place, especially in  applications with more complicated workflows and state. This site,  however, was best served with the simplicity of servlets and JSPs. Most of all, there's a clean mapping between what the user sees on the screen and what's happening in the code.

Dare I say it: it makes the code beautiful.  It really was a joy to just sit down and write some beautiful code with a language I know well and love. Here's to another 15 years of great Java development.


A big part of my new job at Palm is education, in the form of  tutorials, blogs, and of course speaking at conferences. Two new  speaking engagements have recently come up. Palm Developer Day and  OSCON.

Palm Developer Day

This month I'll be doing the day long Introduction to WebOS session. In this session I'll take you from zero to 60 in about five hours, giving you everything you need to know to make great apps for the webOS.  This Developer Day is now sold out,(we've expanded. see below)  but we are planning to do it again later this year after we work out the kinks. We also plan to video record the sessions and put them on the web. Stay tuned for more details.


I thought we were sold out for the Palm Dev Day, I've just heard that we have expanded the capacity and reopened registration.  Space is going fast, so sign up now!


Yes, I'll be at O'Reilly's Open Source Convention again this summer. In addition to attending (a scant 2 hours from my house this time!) I'll also be speaking on Marketing your Open Source Project on a Shoestring Budget.  I'll discuss different ways you can get the word out without breaking your budget, and throw in a few case studies.

If you've never been to OSCON before and live in the Pacific NorthWest I highly recommend attending. It's a great opportunity to get out of your particular technology bubble and experience what the rest of the tech world has to offer.  I went two years ago and learned about Jython, Arduino, Trac, an extreme unit testing; all worlds away from my usual Java / JavaFX background.

The conference is July 19th-23rd, and I'll be speaking Friday morning. If you make it here be sure to let me know so I can buy you a beer. (Oh yeah, Portland has some of the best microbrews in the country).

A splendid time is guaranteed for all!

Lots of people have opined on Apple's iPad, many deriding it's closed nature and lack of features.  The thing is, those problems don't matter to most people. The iPad isn't for you or me. It's for everyone else. I've spent the last 20 years hoping we would have the technology to build such a device, even though I knew it was a device I would not personally use. But that doesn't matter..

Make no mistake, the simplified and locked down iPhone OS (running on both the iPhone and the iPad) is the future. Eventually at least 90% of people will use an iPhone, Chrome Pad, netbook, or similar device as their primary computing interface. Don't focus on the form factor. A netbook will simply an iPad with a built in keyboard.  The point is the simplified computing experience that leaves a lot out. It does what 90% of people want to do and without 90% of the headaches you get from a general purpose computing device.

The iPad doesn't represent something that augments your laptop. For 90% of people, this will replace their laptop. It's the end of carrying many pounds of textbooks. It's the end of segfaults, finding files, navigating 20 overlapping windows, dreading system upgrades, and network configuration. It's the end of general purpose operating systems for the masses.

Sure, Apple may say it's occupying a 3rd space between the phone and laptop. And the iPad may currently be slaved to a master computer, but one day it won't be. And I bet that day will come sooner than we expect.  Apple is just waiting for the right time to make the iPad go independent.

The problem? So let me ask you this: What if Microsoft in 2000 had decided that WindowsXP would only be available on a Microsoft PC, and the only apps, videos, and ebooks you could install on it would be sold by a Microsoft online store, and developers could only write apps in Visual Studio with .NET, and certain APIs and features would be reserved only for Microsoft's own apps, and certain kinds of apps will not be allowed at all.  Would we have accepted this?  Certainly not. Yet Apple is doing the same thing, and the world will love them for it. Because a simplified computing experience is what 90% of people really want.

In the long run, this is good. Apple is pushing forward the state of the art and will force the industry to follow it.  I don't begrudge Apple their winnings. What they've done in the last 10 years is astonishing and we are all better off for it.  They have worked incredibly hard and earned their success . But there's a downside.  In their quest to put the user experience first over all else they have created a locked down system where Apple controls everything. We put up with this from the iPhone because it was still more open than the typical feature phones that preceded it. But when we see something that will replace the laptops we have today, and the nice open general purpose computing environments we take for granted, then it starts to be worrisome.

The answer, however, is not to bitch on mailing lists and blogs.  Most people don't care about the 'openness' of their devices. It provides no tangible benefit to they, so we shouldn't expect them to care. They simply want to get stuff done with a minimum of fuss. And be snappy. Complaining about Apple's lock-in or lamenting the lack of iPad features won't change anything.  There's only one thing that will make a difference: create a alternative that is more open but still provides a good experience; starting with a viable competitor to the iPhone.

And that's exactly what I've decided to do:



Filter Blog

By date: