When calling a generic constructor factory (the generated methods that start with _new), all parameters of type of a type variable are boxed implicitly. This should be avoided. Instead, get rid of the generic factory and call a specialized constructor directly (if it is fixed as described, it would probably also fix #4).

This only applies to constructors but not factories (Constructor factory != factory constructor)! Generic method specializations (#6) could be used to get rid of boxing when calling a factory constructor.

E.g.:

class A<T> {
    T variable;
    A(this.variable);
}

new A<int>(42);   // 42 is boxed

The following code does not compile correctly:

class A<T> {
    T variable;
}

void main() {
    print(new A<int>().variable);
}

There is something wrong with inserting type casts. The following variation works:

var result = new A<int>();
print(result.variable);

The implementation of DynamicHelper is very slow and does a method lookup using the Java Reflection API every time a method is invoked on an expression of dynamic type (see performance results of benchmark tracer).

Use caching, the Java Method Handle API, or generate byte code to take advantage of invokedynamic.

Due to the current translation of Dart constructors (generating an instance method with the constructor body), fields that are declared as final in Dart code are not final in Java code.

Not implemented at the moment.

throw ... will throw a RuntimeException. Exceptions cannot be caught at the moment.

Static methods in special core class such as int, String, or Number are not translated at the moment.

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Binary Artifacts policy: binaries present in source code

Rule Description
Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

Remediation Steps
To remediate, remove the generated executable artifacts from the repository.

Artifacts Found

• third_party/hamcrest-1.3/hamcrest-core-1.3-src.jar
• third_party/hamcrest-1.3/hamcrest-core-1.3.jar
• third_party/hamcrest-1.3/hamcrest-library-1.3-src.jar
• third_party/hamcrest-1.3/hamcrest-library-1.3.jar
• third_party/junit-4.12/junit-4.12.jar

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Only a zero/one field declarations are supported at the moment. This should be an easy fix in _JavaAstEmitter.

There is a TODO in visitSuperInitializer. The name mangling does not always produce the correct result.

Same as specialization for classes.

The following code does not compile:

List<int> list;
list[4] = list[3]++;

Generated Java code:

dart.core.List_interface__int __tempVar_4;
int __tempVar_5;
int __tempVar_6;
void __tempVar_7;
dart.core.List_interface__int list = null;
list.operatorAtPut_List__int(4, dart._runtime.helpers.LetExpressionHelper.comma(__tempVar_4 = ((dart.core.List_interface__int) list), dart._runtime.helpers.LetExpressionHelper.comma(__tempVar_5 = 3, dart._runtime.helpers.LetExpressionHelper.comma(__tempVar_6 = __tempVar_4.operatorAt_List__int(__tempVar_5), dart._runtime.helpers.LetExpressionHelper.comma(__tempVar_7 = __tempVar_4.operatorAtPut_List__int(__tempVar_5, (__tempVar_6 + 1)), __tempVar_6)))));

This is because of how we use LetExpressionHelper at the moment.

Note: Dart code can always be rewritten in a way such that the code compiles (using extra temp variables).

Generated interfaces of (abstract) SDK classes should be implemented by the following Java interfaces.

List_interface<T> extends java.util.List<T>
Map__interface<K, V> extends java.util.Map<K, V>
Iterable_interface<T> extends java.lang.Iterable<T>
Iterator_interface<T> extends java.lang.Iterator<T>
Comparable_interface<T> extends java.lang.Comparable<T>

(There might be more SDK classes, but these are the most important ones IMO.)

This means that additional methods must be inserted as soon as a class implements one of these Dart classes.

Named parameters are currently not supported. Check places like buildArguments etc.

The public runtime type system (e.g., is checks) is not well covered in Dart unit tests (but seems to be working fine!). Parts of the runtime type system are not exposed to the public API.

• Implementation of Type is missing (the logics is there)
• runtimeType not implemented on DartObject

Not implemented.

Most special classes in the Dart SDK are probably abstract (e.g. int, String). In those cases there should not be any explicit constructor invocations. At the very least, this is required for Java interoperability reasons (instantiating a Java class from Dart once we figured out interop details).

Mixins are currently not supported.