Skip to content

Release Notes (Jangaroo 1)

Jump to bottom Edit New page
Frank Wienberg edited this page Nov 8, 2017 · 1 revision

Version 1.0.3

08/20/2014

Fixed issues

Version 1.0.2

03/07/2014

Fixed issues

Version 1.0.1

02/25/2013

Fixed issues

As the 1.0.1 release only contains fixes in the Maven plugin, not in the compiler itself, jangaroo-libs has not been updated and stays at 1.0.0. Please do take care though to use version 1.0.1 of jangaroo-runtime, because jangaroo-runtime 1.0.0 will refuse to load classes built with jangaroo-tools 1.0.1 (runtime version check fails).

Version 1.0.0

11/16/2012

Although we already have a next major Jangaroo version, namely 2.0, the 1.0 release was still pending.
Here it is! It accumulates all compiler and library bug fixes and features from preceding 2.0 releases, excluding everything that deals with the new packaging / build process.
Everybody should update their projects to Jangaroo 1.0.x (or 2.0.x, if you run Jangaroo in a Java Servlet 3 container).
We will continue to provide bug fixes for both Jangaroo 1 and 2.

Fixed issues

Version 0.9.16

06/28/2012

  • New way of generating AS3 API stubs from a common API model

Fixed issues

Version 0.9.15

04/26/2012

Fixed issues

Version 0.9.14

04/06/2012

Fixed issues

Jangaroo

  • Compiler: The compiler now re-checks class file names for upper-/lower-case spelling, because under Windows, getting a file Foo.as also returns a file called foo.as. This makes the behavior of jooc more predictable when used under *nix and Windows.

Version 0.9.13

03/23/2012

Fixed issues

Version 0.9.12

03/16/2012

Fixed issues

Jangaroo

  • Runtime: Feature: new joo.localization configuration option: preferredLocales
    This allows Jangaroo applications to select the best fit between the user’s browser settings and the locales supported by the Jangaroo application. All you need is a simple service that “mirrors” the “Accept-Language” request header as a JSONP response (see ASDoc of joo.localization.preferredLocales).
    Also corrected when Jangaroo stores the locale Cookie: no longer when it is retrieved, but only when set explicitly via ResourceBundleAwareClassLoader.INSTANCE.setLocale().
  • Compiler: Feature: you can now suppress the warning “‘this’ may be unbound and is untyped in functions, even inside methods” if you explicitly cast this to the expected type. You may use an “old-style” type cast (Type(this)) or this as Type. Note that type casts currently do not introduce any runtime overhead (they are just kept as comment), while as expressions actually check the type at runtime (and evaluate to null if the runtime type is incompatible).
  • Compiler: internal refactorings to separate AST classes and code generation more cleanly

EXML

  • Compiler: Fix: import for type of <exml:var> was not generated automatically
  • Compiler: Feature: Allow providing a custom EXML target class implementation, so that only a config class is generated from the EXML source file. Simply provide a target class of the same name, starting with an upper-case letter. This is especially useful for plugins, for which there is no class to extend (only an interface), and there is usually not much declarative about a plugin save the config attributes it defines.
  • Compiler: Feature: The EXML target element that specifies which EXML config/target class to extend is now optional, because if the config class is not supposed to extend any other class (inherits from joo.JavaScriptObject directly), you can still use the baseClass attribute to specify the super class of the generated target class.
  • Compiler: Change: AS3 code generated from EXML no longer has compile-time dependencies on target classes, only on config classes. While for components and plugins, it has always been like this, Actions and all other classes were created using the target class constructor. Now, there is a generic EXML factory net.jangaroo.ext.create() that takes the config class and an untyped config object and creates an instance of the target class. Because the target class is read from the [ExtConfig(target="...")] annotation at runtime, there is no compile-time dependency anymore. This allows to define more concise public APIs.

Version 0.9.11

02/24/2012

Fixed issues

Jangaroo

  • Compiler: New Feature “public API definition and checking”. You can now annotate classes with [PublicApi], and set the compiler flag --publicApiViolations to configure how the compiler reacts on usage of classes from other modules that are not annotated as [PublicApi]. error means to stop the build with an error, warn to only report a warning, and allow to ignore usage of non-public-API classes.
  • Compiler: some fixes for API stub generation, especially concerning constants.

EXML

  • Compiler: Supports the public API definition by the new attribute publicApi, which can be false (both generated classes are not public API), config (only the generated config class is public API), or true (both generated classes are public API).

Version 0.9.10

02/15/2012

Fixed issues

Jangaroo

Version 0.9.9

01/10/2012

Fixed issues

Jangaroo

  • Build process: Fix: bad combination of dependencies lead to broken Selenium test runner

Version 0.9.8

01/09/2012

Fixed issues

Jangaroo:

EXML:

Version 0.9.7

12/20/2011

Fixed issues

Jangaroo:

  • Compiler: Closure compatibility (at least for SIMPLE_OPTIMIZATIONS)
    • don’t add init code for primitive / built-in classes (this is also a small optimization): Closure does not like reserved words like int to appear in JavaScript code
    • neutralize extra comma in the array of class members by adding an undefined item
  • Compiler: The constructor function is no longer renamed (the function name used to be class name + $), as in the meantime, it is longer wrapped and thus may be called directly.
  • Maven: Feature: In addition to jangaroo-application.js, the package goal now creates a file jangaroo-application-all.js, which contains the complete JavaScript code for the whole application.
  • Maven: Fix: Since there were problems with running unit tests with “normal” phantom.js runner, made “page runner” the default.

EXML:

  • Feature: EXML constants can now be of any type and be initialized with arbitrary expressions
  • Feature: You can now define local variables in EXML, using <exml:var name="..." type="..." value="{...}"/>. These are convenient for re-occurring expressions in AS3 fragments embedded in EXML.
  • Fix: </p> was missing for non-component EXML classes (ASDoc still does not like unmatched tags).

Version 0.9.6

11/21/2011

EXML:

  • Fix: Some config classes generated from EXML contained a superfluous </p>, which ASDoc does not like.

Version 0.9.5

11/17/2011

EXML:

  • Fix: custom grid columns defined in EXML now work as intended

Version 0.9.4

11/17/2011

EXML:

  • The type attribute of exml:cfg can be a fully qualified class name of the type and not only primitive types.

Version 0.9.3

11/16/2011

EXML:

  • New baseClass attribute, that can be used to specify the base class of an exml component
  • With exml:constant you can now define constants in your exml component and reuse that constant through out the code.
  • GridColumns, plugins and layouts can now be defined in exml, too

Version 0.9.2

11/15/2011

  • Several compiler fixes
  • Experimental support for PhantomJS. Instead of selenium you can use PhantomJS to run JooUnit tests.
  • IDEA Plugin: For all compilers with version 0.9.x, there is a new unified IDEA plugin “Jangaroo 0.9”. Please disable or uninstall “Jangaroo”, “Jangaroo Language”, and “Jangaroo EXML”.

Version 0.8.7

09/30/2011

Jangaroo:

  • Compiler: fix: incorrect cyclic dependency warnings. Compiler added init code when a class uses its own constants. This resulted in unnecessary runtime overhead and incorrect “cyclic static dependency” warnings.
  • Compiler: fix: in API stubs, certain initializers (negative numbers, NaN) were suppressed, resulting in errors like “parameters following optional parameter must be optional, too” when building ASDoc. This was because the compiler did not recognize compile time constants correctly.
  • Runtime: fix: JooClassDeclaration’s afterInitMembers event not sent to listeners that attach when members are already initialized. That broke Ext AS component registration in some corner cases.

EXML:

  • Better support for Ext’s grid columns. Although they use xtype, they are not components, but registered differently. Introduced a new ExtConfig annotation parameter gctype (grid column type). As JSON, it renders as xtype, and at runtime, such classes are registered appropriately with ext.grid.Column by Ext AS.
  • fix: In exml.xsd, the cfg element only allowed some built-in AS3 types for attribute type. It now allows arbitrary strings to let you specify any AS3 type/class.

Version 0.8.6

08/29/2011

Jangaroo:

  • Compiler: fixed corner case: a variable declaration with a type that exactly equals the variable name (yes: lower case classes are despised, but not forbidden!) led to an endless recursion (stack overflow) instead of a compiler error message.

EXML:

  • exml-converter tool added, see Exml converter for details
  • fix: prevent infinite loop in exmlc for cyclic inheritance
  • extracted Jangaroo IDEA Plugin to https://github.com/CoreMedia/jangaroo-idea
  • If you prefer, you now may write your EXML files in lower case. The name of the generated component class is the name of the EXML file without the .exml suffix, with upper-case first letter.
  • The logic to create a lower-case config class from the EXML file name is smarter now. Consecutive upper-case letters are converted to lower-case unless the last one. E.g. HTMLEditor.exml becomes config/htmlEditor.as.

Version 0.8.5

08/15/2011

Jangaroo:

  • “this” in functions is unbound and untyped, even if the function is inside a non-static method. However, Jangaroo issues a warning for exactly that case, because Jangaroo’s semantic changes with this fix and the AS3-compatible behavior comes rather unexpected.

EXML:

  • To specify a custom Ext JS object that may be used in a EXML component, you no longer specify configuration attributes by means of ASDoc annotations like @cfg. Instead, you provide a separate configuration class that specifies the configuration interface of your component. The following rules for developing config classes apply:
    • The config class must directly or indirectly inherit from joo.JavaScriptObject, so that it does not receive the `constructor` property present in normal Jangaroo classes.
    • It may be used as the type of the constructor of the configured class.
    • In the case of components, it must contain an ActionScript class annotation of the form [ExtConfig(target="mypackage.MyComponent", xtype)] to declare the component class instantiated by way of the config class. This makes sure that the component is registered with Ext JS as soon as the config class is first accessed.
    • In the case of plugins, it must contain an ActionScript class annotation of the form [ExtConfig(target="mypackage.MyPlugin", ptype)] to declare the plugin class instantiated by way of the config class. This makes sure that the plugin is registered with Ext JS as soon as the config class is first accessed.
    • For each configuration attribute, it must define a native getter function with the name of the configuration attribute, like public native function get myProperty():String with an appropriate type.
    • At your option, it may also define a matching native setter function for updating the config object in a type-safe way.
    • It must define a constructor with a argument typed as Object, which it passes to its superclass constructor.
    • At your option, you may also specify config classes for actions or arbitrary other classes that use a config object in their constructor. Use [ExtConfig(target="mypackage.MyAction")] as the class annotation in this case.
    • By convention, the config classes of one module should be placed in a single package. Config class names should start with a lower-case character, whereas component or plugin class names should start with an upper-case character. Where possible, the names of the classes should be identical except for capitalization.
  • For each EXML file, both an ActionScript component class and an ActionScript config class are generated.
    • The component class is placed in the same package as the EXML file.
    • The name of the component class is the name of the EXML file without the .exml suffix.
    • The config class is placed in a central package that is configured in the configClassPackage attribute of the EXML Maven plugin.
    • The name of the config class is the name of the EXML file without the .exml suffix with the first character converted to lower case.
    • The component class is registered with the Ext JS ComponentMgr when the config class is initialized, not when the component class is initialized. The reason is that in many cases only the config class is accessed from other ActionScript classes. However, this means that legacy code might not automatically register the component as a side effect of using the component class.
  • When writing EXML files, the namespace URI for component references is exml: followed by the package in which the config class of the component is placed. Specifically:
    • The namespace URI for Ext JS components in EXML files has changed from http://extjs.com/ext3 to exml:ext.config.
  • The EXML namespace URI has changed from http://net.jangaroo.com/extxml/0.1 to http://www.jangaroo.net/exml/0.8.
  • For Maven modules including EXML source files, the configClassPackage attribute must be specified for the EXML Maven plugin. Additionally, the extensions attribute must be set to true for the EXML Maven plugin and not for the Jangaroo Maven plugin.

Version 0.8.4

04/06/2011

  • EXML: Generated code now uses AS3-compatible initializer, allowing to generate ASDoc.
  • Compiler: Even if the rest parameter is the only one, use Array.prototype.slice, so that the arguments object is always converted to a real Array.
  • Runtime: fix: Vector$object not defined in non-debug mode.

Version 0.8.3

03/11/2011

  • Runtime: fix: broken boundMethod works again, and better as before (see “correctly binding non-existent…” below)

Version 0.8.2

03/11/2011

  • Runtime: broken: boundMethod broken. It no longer returns the same function when invoked twice with the same object and method name.
  • Compiler+Runtime: support for Vector.<Type>: type annotations, initializers (both Vector.<String>(["foo", "bar"]) and new <String>["foo", "bar"]). At runtime, a Vector is simply an Array, but you don’t need to change your Flash 10 source code and profit when using static type checking tools (IDE, Flex compiler, ASDoc).
  • Runtime: fix: correctly binding non-existent or non-function members, which now returns the original member (usually undefined), not a broken function.
  • Compiler: change: package all dependencies into compiler jar
  • Compiler: fix super invocation bug (occurred when using super.x() without overriding method x)
  • Compiler: fix: absolute [Embed(...)] paths were interpreted as relative to the current directory
  • Compiler: fix: in variable declaration a:*=undefined without white-space, *= was mistakenly parsed as the “multiply-and-assign” operator. To fix this, :* is now parsed as a single token and handled as “any type”. Note that a: *= undefined still incorrectly produces a syntax error.
  • Compiler: fix: incorrect syntax error on return ++x;
  • Runtime: fix is (and thus as) for int and uint
  • Runtime: new: experimental support for embedding text resources (loaded via XHR)
  • Maven: change: default of properties goal to look for .properties files under src/main/joo instead of src/main/resources. This is consistent with EXML, which also places files that generate AS3 code under src/main/joo.
  • Maven: new: EXML Maven goal: test-extxml, bound to phase generate-test-sources, compiles *.exml files in ${project.build.testSourceDirectory} into target/generates-test-sources/joo. Thus, you can write AS3 test code in EXML!
  • Maven: fix: do not re-compile production sources in goal testCompile, instead compile generated test sources.
  • EXML: change: Ext AS code generated from EXML now applies the handed-in configuration over its own defaults, not the other way round as previously. Thus, you can override a component default configuration when using it.
  • EXML: change: declarative Ext Actions now work much more predictably: they no longer lose their identity (get copied) or force early creation of the containing component.

Version 0.8.1

02/04/2011

  • Compiler: fix: correct API code generation for namespaces and for constructors to make API stubs work with ASDoc
  • Runtime: fix: cleaned up and documented Jangaroo bootstrap API. Now debugging mode also works in IE, since we no longer use nester document.write() scripts
  • Runtime: Got rid of separate publicConstructor that delegates to the supplied constructor function. Now, the initializing constructor is replaced directly by the supplied constructor function and all static members are attached to the new constructor. This eliminates the function call overhead that used to be there when constructing Jangaroo objects (runtime performance) and makes stack traces and JavaScript profiles more readable, since the supplied constructor function actually has the class name as function name. Instead of setting the “constructor” property on every single instance creation, we now set it in the corresponding prototype (like Ext JS does), which is more efficient.
  • Runtime: fix: joo.classLoader.complete() callbacks might be called more than once in IE
  • Runtime: change: also allow #joo.debug=true (not only #joo.debug) to activate single-class-loading debug mode
  • Runtime: fix helper classes in IE (broke in 0.8.0)
  • Runtime: change: complemented built-in classes and updated their ASDoc from the Adobe live docs
  • Maven: change: moved jangaroo-lifecycle into jangaroo-maven-plugin. You have to remove jangaroo-lifecycle from your Maven POM and add <extensions>true</extensions> to the jangaroo-maven-plugin.
  • Maven: cleaned up Maven build process, especially configuration of (intermediate) output directories. Now, typical projects work with minimal configuration in pom.xml
  • Maven: fix: unit tests of modules with custom *.module.js forgot to add it to jangaroo-application.js
  • Maven: fix: when there is no joo/<artifactId>.module.js, but a joo/<groupId>.<artifactId>.classes.js, PackageMojo now correctly creates one loading the complete generated module code in non-debug mode.

Version 0.8.0

01/17/2011

  • Revamped modular build process. Stay tuned for extensive documentation.
    • target directory scripts => joo
    • custom JavaScript module code scripts/jangaroo-module.js => joo/<artifactId>.module.js
    • all modules’ custom JavaScript code scripts/jangaroo-modules.js => joo/jangaroo-application.js (also includes Runtime bootstrap!)
    • generated JavaScript module code scripts/<artifactId>.js => joo/<groupId>.<artifactId>.classes.js
    • simple switch to debug via appending #joo.debug to the Web app URL
  • Compiler+Runtime: exploit the now known inheritance hierarchy/depth to simplify private members in runtime. Compatibility after framework refactorings: when increasing dependency version number, you will rebuild your project, anyway.

Version 0.7

Version 0.7.12

11/18/2010

  • change runtime compatibility check to accept the same runtime version only if the compiler version is the same or higher. This allows backwards-compatible extensions to the runtime API without having to increment runtime API version.
  • implement getter and setter functions for IE 9 (different Syntax than FF & Co, following the new ECMA standard)

Version 0.7.8

11/04/2010

  • generate code for x as Y expression: as(x,Y), where as is implemented as is(x,Y) ? x : null
  • provide metadata / annotations at runtime
  • default values for uninitialized fields. Only untyped fields should be initialized with undefined!
  • add “local” classes, i.e. class declarations that can only be used inside the same file. These come after the package block and may not be public.

Version 0.7.2

  • anonymous function binding to this through renaming it to $this (a local variable copy of this) => one apply less, no more tampering with Function.prototype
  • get rid of with statements around all class members

Version 0.7.1

  • automatic method binding for all cases (well, not really all cases, but we’d need for type inference)
  • special treatment of built-in “Error” class: Error("foo") always creates new object. Let runtime use special Error super constructor call.
  • do not blindly package src/main/joo-api, because compilation errors are detected late (only when using the API). solved by adding joo-api to the classpath, so that the module can use its own API.

Version 0.7.0

  • implement finally correctly
Add a custom footer
Add a custom sidebar
Clone this wiki locally