Go here to download ready-to-run and source distributions of Jangaroo. more...

Wednesday, December 10, 2008

IDEA 8 Supports ActionScript 3 and JetBrains Supports Jangaroo

One main point about Jangaroo is that it is based on a language being standardized, not inventing a new one. The main advantage is that all kinds of resources available for that language can be reused: documentation, know how, best practices, and last but not least tools.
As a Java developer, I've been using Jetbrains' IntelliJ IDEA since version 5, and I really like it. As far as I can tell, it offers the best code inspections and refactorings in the Java world.
As a Jangaroo developer, I switched to IDEA 8 when the first milestone was available, because to support Flex, IDEA's JavaScript and ActionScript 3 capabilities were boosted. This makes IDEA 8 the best Jangaroo development environment (and thus the best JavaScript IDE) available!
When version 8 became final, I started using an evaluation license, but became a bit nervous how I would continue after 30 days. So I applied for an Open Source license for IDEA, and voilà, after just three days, I received a free unlimited users license for Jangaroo development!
Thank you, Jetbrains, the Jangaroo team really appreciates your support of Open Source software! I can't wait to do a screencast on how to develop, build & debug (!) a Jangaroo application using IDEA 8!
To not seem too biased ;-), in the following, I'd like to give you pointers to other IDEs that can be used for Jangaroo development.
Of course, there is the Flex Builder by Adobe. It may be the best tool to develop Flex applications, but I have to admit I never tried it for Jangaroo. As far as I know, even as an Open Source developer, after the usual trial period, you have to buy a license.
Like Flex Builder, FDT 3 is Eclipse-based and has sophisticated ActionScript 3 support, but targets at Flash (not Flex) development . I tried it with a demo license, and it works really well with Jangaroo code. Although commercial, too, you can apply for an Open Source license as well, and I think I'll do that next.
The last candidate I had a look at is the only free Open Source ActionScript 3 IDE I could find. FlashDevelop 3 (FD) is based on .net and seems to be a quite fully-featured IDE for AS2, AS3 / MXML, and HTML. Being an Open Source project, it might be the right place to add a special Jangaroo mode, although .net is not really our favorite environment (we are a Java shop...).
What all these tools have in common is that they support ActionScript 3, not JavaScript 2 or even ECMAScript 4, and expect ActionScript 3 class files to have the .as extension, not .js2. (IDEA seems to be the only tool that cares about JS2/ES4.) This evidence and the impression that the ECMAScript specification committee seems to deal rather with their team harmony than with solving real-world JavaScript development problems made us move Jangaroo from JS2/ES4 towards ActionScript 3 -- stay tuned for a major update!

Tuesday, September 9, 2008

Sneak preview of the Jangaroo Maven plugin

Good news for Maven2 users: with the introduction of the jangaroo-maven-plugin, it will soon be easier than ever to compile Jangaroo sources as part of your build process.

The plugin is an alternative to the provided Ant task and will be part of the next Jangaroo tools release. In the meantime you can already try the 0.1.2-SNAPSHOT version from the Jangaroo snapshot repository. The following pom.xml demonstrates how to use the plugin to build the helloWorld example, which is included with the Jangaroo distribution. Simply create a file called pom.xml in the root directory of the example (the one containing the build.xml file) and paste the following to it:

<project xmlns=""

<name>Jangaroo repository</name>
<name>Jangaroo repository</name>



<!-- Default output directory is

<!-- All of the following configuration parameters are optional,
the values shown are the defaults.






Two mojos are available and will usually be run together: compile and copy-runtime. The latter one extracts the Jangaroo runtime joo/Class.js to the output directory.

To build the project, run mvn package in the directory containing pom.xml. Obviously, a working Maven2 installation is required to do so.

We still have some important homework to do before the plugin will be released, such as serious documentation or an option to concatenate all compiled output files into one compact JavaScript file. However, feedback to the plugin at this early stage is higly welcome. Just drop a comment below.

Wednesday, September 3, 2008

Jangaroo Applications Work on Google Chrome

Just a few days ago, Google released the first beta of their Chrome browser. Since the browser is based on WebKit, and Jangaroo has been tested on Safari, you could think Jangaroo should also work on Chrome. But WebKit is only the HTML rendering engine: Google created a completely different JavaScript engine called V8, including performance optimizations (among others, compilation to native code) and multi-tasking! So it was rather an open question whether there are any problems with Jangaroo applications or not.
We have good news for you: The largest Jangaroo application so far, Jangaron, runs without any problems and really fast and smoothly! Congratulations, Google, you did a great job!

P.S.: I wrote this post using Chrome...

Tuesday, August 5, 2008

Jangaroo 0.1.1 - iPhone support!

One of my most important personal goals concerning Jangaroo has been reached with brand new version 0.1.1: it now runs on Safari/iPhone!
As a side-effect, this also makes Jangaroo run on older browsers based on KHTML or WebKit (tested under Linux with Konqueror 3.4), and as an even better side effect, I was now able to get my Jangaroo-based Tron Lightcycle game Jangaron running on the iPhone, too! Since the iPhone is missing the keys needed to control your Lightcycle in the game, I have set up a special iPhone version with on-screen buttons -- feel invited to go ahead and try!

So what was the problem with Jangaroo and old KHTML / WebKit versions? There were several bugs in the KHTML / WebKit JavaScript engine we had to work around:
  1. When using new Function(), it was not possible to set the prototype property, while with function(){}, it works as expected.
  2. with() seems to behave differently when setting properties of the "withed" object. Avoid it to be really cross-browser compatible!
  3. delete showed strange behavior: it seems that in some cases, the property is deleted from the prototype (i.e. for all instances!) instead of from obj only. We also refrained from using it in the runtime.
  4. In order to keep compiled code as close as possible to the source code, we tried to retrieve the generated function's name at runtime. Unfortunately, in older KHTML / WebKit versions there seems no way to do so: Firefox's Function#name is not defined and Function#toString() returns the whole source code of the function save its name. Thus, we had to change the runtime method syntax slightly, sacrificing a bit code similarity for better browser compatibility. For example, the compilation output of a JS2 method
    public function foo(x) { }
    "public", function foo(x) { }
    and now looks like this:
    "public foo", function(x) { }
    or like this in debug mode:
    "public foo", function foo(x) { }
The mean thing about these bugs is that they are all fixed in "Desktop-Safari" (Mac and Windows), so they are really hard to reproduce and even harder to debug. While we didn't have an iPhone or iPod touch available for long-term testing and debugging (I had to ask a colleague for the final test), and not even a Mac, my good old Suse Linux 9.3 with Konquror 3.4 served me reasonably well for this task. It seems Konqueror (whose KHTML engine is the prime father of WebKit) is more similar to Safari/iPhone than Safari/Desktop! Konqueror's JavaScript debugger is... er... limited, and its German localization is incredible (for those who understand German: guess what "Umbruch bei nächster Feststellung" is supposed to mean...), but at least it exists. So I hunted them bugs down, and here you go. The quite complex Jangaron settings UI (implemented with Jangaroo Facelets, more about that another day), and its even more complex real-time 3D graphics now all work perfectly and with reasonable performance on the iPhone! Please use the special iPhone version already mentioned above.
Speaking of performance: the Jangaroo compiler update also increased performance for some common special cases. Sounds contradictory, but there are "common special cases", i.e. special code patters that still occur quite often, like the fly-weight pattern: simple classes that have many instances. We optimized the Jangaroo runtime (Class.js) so that for classes which refrain from using field initializers and/or inheritance, there is a measurable speed-up that leaves almost no performance penalty compared to manually created JavaScript 1.x code.
Have fun with the increased browser-compatible, performance-optimized new Jangaroo version! We are eager to hear about your opinion and discuss your suggestions, so please don't hesitate to comment!

Friday, July 18, 2008

Former Life and Birth of Jangaroo

Today, CoreMedia released a first version of the Jangaroo language and tools as Open Source. This was a wonderful moment for me, because this little project has a long history and played an important underpart in my professional life at CoreMedia over the last years. Please read about it, download, apply, spread the word! Be prepared to develop JavaScript like you never did before! The new Web site should offer you everything for a quick start. If not, feel free to ask! In this first blog post, however, you are going to hear Jangaroo's story, which covers its birth, coming of age, and reincarnation, if you want.
Trying Not to Be Eclectic
When in 2003, I had my first deeper dive into JavaScript, I never had thought it would become a passion. As most Java developers, I despised the style of eclectic programming that was then common among JavaScript hackers: To implement some requirement, they didn't use frameworks or libraries, but grabbed code snippets from other Web pages or forums and somehow assembled them to make them work on their Web pages. My impression was that it is hardly possible to implement serious business in such a patchwork language. But I had to, since a new Web application for CMS content entry waited to be designed and implemented.
Patching a Patchwork Language
My colleague Andreas Gawecki surely agreed on that and decided that, before even starting to dirty our hands on pure JavaScript, we needed a tool to transfer at least some of the amenities of Java to the JavaScript world. But because that was in the days before the Web 2.0 hype and the JavaScript Renaissance, there was no such tool. If you know Andreas, you may be able to imagine what happened: Within a week or so, he had gone through the JavaScript 2 / ECMAScript 4 standard proposals and came up with a compiler that could translate a subset of JavaScript 2 language features to JavaScript 1.x! Of course, Andreas had done research on how classes are usually simulated in JavaScript, and of course he had implemented those JS2-features a Java developer would need most desperately when having to program in JavaScript. I was one of his first Guinea Pigs, and also his primary sparring partner for the language. We started developing tons of JavaScript 2 code, because there were not even JavaScript 1 frameworks available, and we had to do all the cross-browser compatibility code ourselves. Andreas even implemented a Rich Text Editor that had features like table editing that were rare in 2003 - and all that using the JavaScript 2 subset and his compiler.
One Thing Leads to Another
This first shot of the compiler was simply named jscc (JavaScript Class Compiler), and the source file extension was .jsc, so the language was also called JSC. Soon, more tools and libraries followed: Holger Tewis implemented a javadoc-counterpart, naturally called jscdoc, that tricked Java doclets into generating HTML API documentation for JSC programs. I did a port of JsUnit to JSC, needless to say called JscUnit, in about two days (and of course its self-tests were green then). We experimented with writing IDE plug-ins for the unfinished language. Having learned from the WebEditor, we implemented another UI framework, which we so far only used for popping up a context menu on preview Web pages to let the user invoke content-related actions (sounds a bit like breaking a fly on the wheel, doesn't it?).
I loved working with JSC, but to be honest it had some serious drawbacks:
  • There was no real IDE support.
  • No type checker, types are just remarks used for API documentation.
  • Bugs and request were not fairly tracked and never really tackled.
  • No class dependencies or automatic class loading: each class file had to be listed, and even in the right sequence before all its depending classes.
Worst, there was almost no documentation and the build process was tied to our primary product. JSC was suffering the typical fate of an internal development tool that had no (paying) customer, although a lot of value or at least potential. At that time, our company grew, and even other projects in the very same company did not use JSC for their JavaScript development. I felt there was something going wrong.
Time for a Change
CoreMedia went through some changes, which opened up new possiblities. We evolved to a learning company, where all members are given time for "peer group" work, i.e. work in small groups of people who pursue a common goal and handle a topic of individual choice. Luckily, I found fellows who were, like me, interested in reanimating JSC. The new spirit and transparency of our company was the perfect breeding ground for the idea to release JSC to the public, as Open Source. It was the perfect candidate:
  • En vogue topic.
  • Focussed, general purpose tool.
  • Not too big to handle.
  • Nothing anyone would want to sell: development tools are hard to sell, anyway, and these are not our company's focus.
  • We had to document and clean up, anyway, so hardly any additional cost.
The main goal of the peer group, consisting of Andreas Gawecki, Olaf Kummer, Matthias Buse, Mark Michaelis, and myself, was to prepare a decision memo convincing CoreMedia to spend resources on our first real Open Source project.
At that time, JavaScript really enjoyed a renaissance and AJAX was a hype. Interesting new articles about JavaScript mushroomed and inspired me to create a new JSC runtime supporting features like private and protected members, lazy class initializing, and even better readable compiled code. After several iterations, we decided to skip "really private" and protected members for performance reasons, but nevertheless found a solution that does the job to avoid unexpected name clashes. We also updated the language syntax to the latest standard proposals. Suddenly, IDEs started to support ActionScript 3, which is also an ECMAScript 4 language, so we could benefit from that, too.
We were overcoming most disadvantages of JSC. In other words, we had even more to offer than what we had used successfully as an internal tool for years.
The peer-group found that JSC needed a proper name: it should be Web-2.0-ish, cool, foolish, looney (add your favorite adjectives containing oo-s), and artificial, so that we could still grab the domain, the blogger subdomain (sic!), the user ID for community xyz, and so on. All our peer groups have rather silly animal names, and we were True Kangaroo. Replacing the first letter by a JavaScript J and keeping the popular oo-s finally led to Jangaroo. I guess the cool name must have been the critical factor when CoreMedia decided to give us a go.
Walking the Talk
In the execution phase, Masiar Bostanipoor (Web site) and Dennis Homann (build infrastructure, tutorial) joined the team. Andreas and Olaf rounded off compiler (now coherently called jooc) and runtime (where I helped a bit). Olaf wrote most of the language and compiler documentation. Kudos to numerous CoreMedians who helped us with the project, in no particular order and surely not complete: Thomas Stegmann, Gunnar Klauberg, Uli Henningsen, Tobias Baier, Jan Brauer, Carsten Böttcher, Stefanie Wegener, and Christian Pesch.
We used the project time CoreMedia granted us mainly to come up with a stable infrastructure and an appealing presentation (at least we hope so), not to create more tools. We got the domain, created a Web home for Jangaroo, started this blog, wrote documentation, set up a proper build process involving a Maven repository, cared about license issues (German license jurisdiction is a nightmare!), and so on. Of course, some infrastructure is still missing, most importantly a forum and a bug tracker -- we are working on that, please bear with us! Until then, please comment in this blog for public discussions, and e-mail for direct communication. We also have a twitter user Jangaroo, feel free to follow if you like! Many of the tools and libraries mentioned here may follow jooc, so stay tuned!
I hope you have enjoyed hearing about Jangaroo's first life as JSC and its rebirth as an Open Source project. What I described is just the way I personally remember and feel about things. In the future, be prepared to find a bit more technological facts in my postings...