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 Packages.com.mydomain.

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.

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!

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:
http://groups.google.com/group/jangaroo-dev
http://groups.google.com/group/jangaroo-users
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!

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!

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="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                            http://maven.apache.org/maven-v4_0_0.xsd">
 <modelversion>4.0.0</modelversion>
 <groupid>net.jangaroo.examples</groupid>
 <artifactid>hello-world</artifactid>
 <packaging>war</packaging>
 <version>1.0-SNAPSHOT</version>
 <name>hello-world-example</name>

 <pluginrepositories>
   <pluginrepository>
     <id>jangaroo</id>
     <name>Jangaroo repository</name>
     <url>http://repo.jangaroo.net/maven2</url>
   </pluginrepository>
   <pluginrepository>
     <id>jangaroo-snapshots</id>
     <name>Jangaroo repository</name>
     <url>http://repo.jangaroo.net/maven2-snapshots</url>
     <snapshots>
       <enabled>true</enabled>
     </snapshots>
   </pluginrepository>
 </pluginrepositories>

 <build>

   <plugins>
     <plugin>
       <groupid>net.jangaroo</groupid>
       <artifactid>jangaroo-maven-plugin</artifactid>
       <version>0.1.2-SNAPSHOT</version>
       <executions>
         <execution>
           <id>compile-jangaroo-sources</id>
           <goals>
             <goal>compile</goal>
             <goal>copy-runtime</goal>
           </goals>
           <configuration>
         
             <!-- Default output directory is
                  {project.build.directory}/${project.build.finalName}/js
              -->              
             <outputdirectory>
               ${project.build.directory}/${project.build.finalName}
             </outputdirectory>            

             <!-- All of the following configuration parameters are optional,
                  the values shown are the defaults.
               -->              
             <sourcedirectory>
               ${basedir}/src/main/js2
             </sourcedirectory>            

             <verbose>false</verbose>
             <debug>true</debug>
             <debuglevel>source</debuglevel>
           
           </configuration>
         </execution>
       </executions>
     </plugin>

     <plugin>
       <artifactid>maven-war-plugin</artifactid>
       <version>2.1-alpha-2</version>
       <configuration>
         <failonmissingwebxml>false</failonmissingwebxml>
       </configuration>
     </plugin>

   </plugins>

 </build>
</project>

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.

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...

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 obj.property 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) { }
   was
   "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!