Home

Welcome to the JSweet wiki!

Current target version

Current version: 1.2.0 (see all issues).

Next version (2.0) wishlist

ES6 core candy with Symbol.iterator / Iterable support

Better hashCode / equals handling

https://github.com/cincheo/jsweet/issues/199

Mixins

Current mixins are not standard and too complicated to use in a regular Java environment (they require a plugin or a specific classpath configuration). We need to make mixins easier. Something like:

public class MyClass extends jsweet.lang.Object { }

@Mixin
public class MyMixin extends MyClass {
  public void addedMethod();
  public String addedProperty
}

Usage:

MyClass o = ...;
((MyMixin)o).addedMethod();

Better jsweet.lang.Object and util APIs

Add/change the following utility methods:

• jsweet.lang.Object $get(String key)
• ? <T extends jsweet.lang.Object> T $getAs(String key)
• String $getString(String key)
• boolean $getBoolean(String key)
• double $getNumber(String key)
• Object $getObject(String key)
• jsweet.lang.Object $apply(Object... args)
• String $applyForString(Object... args)
• boolean $applyForBoolean(Object... args)
• double $applyForNumber(Object... args)
• Object $applyForObject(Object... args)
• ? <T extends jsweet.lang.Object> T $any()
• Object $macro(boolean condition, String typeScriptCode)
• Object $macro(String typeScriptCode)

Make annoying cast methods (Globals.object, Globals.string) less necessary

• JSweet APIs should rather return JSweet types than Java types (eg: jsweet.lang.String.substring(): jsweet.lang.String), as well as it should accept both versions in parameters to increase interop (eg: jsweet.lang.String concat(java.lang.String... strings) AND jsweet.lang.String concat(jsweet.lang.String... strings))
• Use CharSequence implementation for JSweet strings (?)
• Provide getAs methods: jsweet.lang.Object.toJava() => java.lang.Object, we could also use contravariance to make it easy:

jsweet.lang.String extends jsweet.lang.Object {
  java.lang.String toJava();
}

Add a cast method to jsweet.lang.Array:

• T[] toArray()

Change the current convention of apply() as $apply()

Remove the jsweet.util.Globals.$apply(), jsweet.util.Globals.$get(), jsweet.util.Globals.$set() utility methods (should use the new Object API instead).

Rename jsweet.util.Globals.object() to jsweet.util.Globals.$object() for consistency reason and avoid clashes with local variables. Same for string, number utility methods?

Handle system APIs as regular candies

• jsweet.dom -> def.dom
• jsweet.lang -> def.js

We then need to be able to declare the "system" packages to handle special cases (could be a transpiler option or an annotation on the package).

Candies generation tool

Useful for private or custom .d.ts definitions or to scaffold a not properly handled automatically generated candy Example:

mvn jsweet:generate-candy ./typings/myLib/myLib.d.ts ./typings/dependency/dep.d.ts

It could be pretty straightforward to implement by calling the existing online candy generator (simple ajax POST to a Web API: send the .d.ts and its dependencies to the given URL, and download the resulting candy JAR with javadoc)