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

Saturday, August 1, 2009

Jangaroo 0.3.1: Less Imports, More Rhino

We just released version 0.3.1 with some nice updates:

No more same-package imports

With Jangaroo 0.3.1, you no longer need to import classes of the same package to enable automatic class loading. The compiler now scans the directory of the current source file for all *.as files, so that it knows about all declarations in the same package. The limitation that you have to import top-level Jangaroo classes for automatic class loading to work remains---hopefully only until the next release! For more info about Jangaroo and top-level classes, read on below.

Oh, behave, Rhino!

Jangaroo works in many environments: in most browsers, and also in Rhino. For example, to run automated Jangaroo unit tests, the easiest way is to start a cross-platform, stand-alone JavaScript engine like Rhino.
While in principle, the Jangaroo runtime worked inside Rhino, some classes were not loaded and there were strange error messages. After some investigation, we found out that Rhino behaves badly in polluting the global namespace with [JavaPackage] objects for all imported top-level Java package name prefixes. You cannot get rid of some Java packages imported by default, among which are com and net, and even more badly, any property of Rhino's [JavaPackage] objects is claimed to be defined, and they are all again [JavaPackage]. For example, if Rhino knows of a Java class in com.mydomain, the JavaScript expression com.foobar also returns a [Java package] object, even if there is no such package!
This odd behavior made the Jangaroo runtime think that any Jangaroo class in a package starting with com or net is already defined. It seems Rhino cannot be configured to behave less obtrusive, so we had to find a workaround in the Jangaroo runtime. The solution was to treat any JavaScript object whose string representation contains "[JavaPackage" as non-existent and overwrite it with a clean Jangaroo package object. If you still need to access the overwritten Java packages, Rhino also places them under the top-level object Packages, so simply use

Alias for top-level package
The updated Jangaroo runtime defines the alias js for the top-level package. Why?
ActionScript seems to have a problem with top-level classes. Say you have a top-level class Node, and some framework defines a class org.w3c.dom.Node. In your client code, you need to use both classes, so you have to import org.w3c.dom.Node (the top-level class is in scope by default). With asdoc (which is based on the Flex ActionScript compiler), this situation leads to the error that Node is not defined (I also tried importing the top-level Node explicitly). Whether this is a compiler bug or a conceptual problem in ActionScript, I don't really care, since we cannot wait for asdoc to be fixed. My theory is that the import mapping is removed as a result of the name clash, as there is a rule that two imports with the same local name cancel each other out, which means that both classes have to be used with their fully qualified names. But what is the fully qualified name of a top-level class?!
We ran into this situation when trying to provide built-in browser APIs as ActionScript 3 classes and interfaces. Most JavaScript frameworks define wrapper classes for top-level types and put them into their own package (e.g. Ext.Element). So our solution now is to declare the API for a top-level JavaScript type in the package js, which at runtime is the same as the top-level package. Then, to come back to my example, you can use both js.Node and org.w3c.dom.Node in the same class. You can find an alpha of the Jangaroo library defining most built-in browser APIs as ActionScript classes and interfaces under the name "js2native" in the Jangaroo Maven snapshot repository.

Wednesday, July 1, 2009

Jangaroo 0.3: Amplified ActionScript 3 Compatibility

It's been quite a while, but eventually, I am proud to announce Jangaroo 0.3, featuring highly improved ActionScript 3 compatibility and better build and deployment support:
  • interfaces, is
  • type casts (as and support for the legacy syntax)
  • bound methods (get this right!)
  • no more need to always use this.x instead of x
  • *-imports
  • fully AS3 compatible Array class
  • include directive
  • annotations (syntax only)
  • getter and setter methods (unfortunately not in IE)
  • automatic loading of dependent classes
  • Maven plugin provides Jangaroo with a flexible and powerful build system
Actually, many of these features were already introduced with the 0.2.x versions, but these were only released in the Jangaroo Maven repository. Now, the main effort was to round things off and update all documentation, so please go ahead and re-visit the Jangaroo Web site to find an updated story ("JavaScript 2 is dead, long live ActionScript 3!") and many new technical details.
Jangaroo Tool Support
Jangaroo has always used a subset of AS3, so that all AS3 tools like asdoc and IDEs can be used with Jangaroo code. As mentioned before, IntelliJ IDEA 8 supports ActionScript 3 and thus Jangaroo very well. To top that, we have implemented a Jangaroo IDEA plugin that will be released in the near future.
Porting AS3 Libraries to Jangaroo
Now that we have added all these nice AS3 language features, it is possible to translate most existing AS3 code with the Jangaroo compiler and run it in the browser (without any Flash plug-in!).
For example, we work on a port of FlexUnit and, with very few code changes, can already run its self-test-suite successfully in the browser. Our FlexUnit variant (of course called JooUnit!) will be released shortly, and some of the changes (missing semicolons, mixed DOS/UNIX line end encodings, asdoc glitches) will be submitted back to FlexUnit's main branch.
Of course, making the browser understand AS3 natively is only half the truth: Most AS3 code relies on standard libraries, namely Adobe's Flash API. Thus, another running project is to re-implement the Adobe Flash 9 API in Jangaroo as an adapter to native browser APIs (including canvas for drawing), so that most Flash code and even programs that draw and animate can be run, and as always when using Jangaroo: without a Flash plugin, thus seamlessly embedded into any HTML page!
Based on the Flash API, we recently also managed to compile the whole open source Flex 3.3 framework after some Jangaroo-friendly changes, but it is still quite some way to go until it would actually work, so we hope to get you ActionScript whiz people to contribute soon...
Have fun with a new way of experiencing JavaScript and ActionScript 3! We can't wait for your feedback!

Thursday, January 22, 2009

Jangaroo Discussion Groups Started

Latest news: We have started two discussion groups for Jangaroo, one for developers and one for "users", i.e. appliers of Jangaroo language and tools:
We felt that commenting in this blog and e-mailing does not really compensate for real discussion groups. The idea of two groups was that tool developer discussions could be quite boring for people who just want to use the tools and see new features. Discussions about new features should be started in the users group, and if the feature is supported by the user community, developers could take over and discuss how to implement the feature.
To get started, I reposted some e-mail discussions in the users group. Please go ahead and read what's there, and feel free to post your comments and opinion!