Daco Harkes

Crosslink, this is a question about the repo for: * https://github.com/dart-lang/native/issues/761

> Re: summarizer build happening concurrently, what's the best approach? > > Write a lock file, and other process poll repeatedly in fixed intervals until lock gets deleted? Yes, something...

The packaging issue will be solved by: * https://github.com/dart-lang/sdk/issues/50565 When the packaging issue is solved, can we suffice with a Dart-only implementation? Or are we hooking into some Flutter specific...

Note from discussion with @HosseinYousefi: We also have Java code in `package:jni`, so converting that to use native assets and making it a non-Flutter package will break the Java code...

> 1. We want to introduce the functionality but warn people about type erasure in docs I presume developers experienced with Java/Kotlin will know about type erasure. So mentioning it...

From discussion offline: Option 1: `list.isIntanceOf(ArrayList.jClass)` if we type check against the JClass, because the class handle has generics erased by definition. Possible downside: more handles. Option 2: Uninstantiated type...

The only way that I know of without `Dart_ExecuteInternalCommand` is to spawn a new isolate group, attach a `NativeFinalizer` to a `Finalizable` there, and shutdown that isolate group. And then...

I was thinking the atomic counter could also be useful for ensuring that we don't hit the 51200 global refs. I'd probably not make it part of the normal test...

We do the same for linker: ```dart abstract class Linker { Future run({ required LinkConfig config, required LinkOutput output, required Logger? logger, }); } class CLinker implements Linker { ```...

That would indeed be nice. 👍 We'd want to do this when we would like to move this project out of the experimental phase.