Rename delete to release - ready for 0.6.0

[HosseinYousefi]

Closes dart-lang/native#707 – the final issue of 0.6.0 milestone to get ready for the this month's release.

Also changed the changelog/pubspec to reflect the new 0.6.0 version.

---

Final questions before merging:

• Any alternative to releaseOriginal, since it can be verbose?
• Is releasedIn(arena) a good name?

[coveralls]

Pull Request Test Coverage Report for Build 6025380788

• 53 of 58 (91.38%) changed or added relevant lines in 11 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.009%) to 90.327%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
jni/lib/src/util/jlist.dart	1	2	50.0%
jni/lib/src/jexceptions.dart	2	4	50.0%
jni/lib/src/jreference.dart	10	12	83.33%

Totals
Change from base Build 6011397165:	-0.009%
Covered Lines:	2979
Relevant Lines:	3298

---

💛 - Coveralls

[dcharkes]

• Is releasedIn(arena) a good name?

managedIn or releasedBy maybe?

• Any alternative to releaseOriginal, since it can be verbose?

No good ideas here.

While looking at the code though, I see unnecessary verboseness in some places:

      array[0] = "حس".toJString()..deletedIn(arena);
      array[1] = "\$".toJString()..deletedIn(arena);
      array[2] = "33".toJString()..deletedIn(arena);
      expect(array[0].toDartString(deleteOriginal: true), "حس");
      expect(array[1].toDartString(deleteOriginal: true), "\$");
      expect(array[2].toDartString(deleteOriginal: true), "33");

This deletes the Java strings twice.

Probably, if there is already an arena, releaseOriginal can most likely be ignored and the original object can be using releasedIn. It doesn't matter if one executes 20 Dart statements extra before releasing.

Same here:

    using((arena) {
      expect(JLong(val).longValue(deleteOriginal: true), val);
      expect((-val).toJLong().longValue(deleteOriginal: true), -val);
    });

The using can be removed or the JObjects can be ..releasedIn(arena).

It's likely a smell if there's an Arena and releaseOriginal are in the same place.

[HosseinYousefi]

While looking at the code though, I see unnecessary verboseness in some places:

It is unnecessary to delete period, since we have finalizers. However it's not redundant.

      array[0] = "حس".toJString()..deletedIn(arena);
      array[1] = "\$".toJString()..deletedIn(arena);
      array[2] = "33".toJString()..deletedIn(arena);
      expect(array[0].toDartString(deleteOriginal: true), "حس");
      expect(array[1].toDartString(deleteOriginal: true), "\$");
      expect(array[2].toDartString(deleteOriginal: true), "33");

This deletes the Java strings twice.

No, it doesn't. If it would then we'd get a DoubleReleaseException. The array here is a Java array, so operator [] creates a new global reference every time it's called. Now we could say (array[0]..deletedIn(arena)).toDartString() but that seems more verbose.

---

Yes, in the other example using can be removed. I guess it has been there as a result of me just copy pasting the "test + using" template for all the tests and this one in particular not having any releasedIn.

[dcharkes]

While looking at the code though, I see unnecessary verboseness in some places:

It is unnecessary to delete period, since we have finalizers. However it's not redundant.

      array[0] = "حس".toJString()..deletedIn(arena);
      array[1] = "\$".toJString()..deletedIn(arena);
      array[2] = "33".toJString()..deletedIn(arena);
      expect(array[0].toDartString(deleteOriginal: true), "حس");
      expect(array[1].toDartString(deleteOriginal: true), "\$");
      expect(array[2].toDartString(deleteOriginal: true), "33");

This deletes the Java strings twice.

No, it doesn't. If it would then we'd get a DoubleReleaseException. The array here is a Java array, so operator [] creates a new global reference every time it's called. Now we could say (array[0]..deletedIn(arena)).toDartString() but that seems more verbose.

Oh right, the list is a Java list, so the indexed access creates a new reference. 🤓

(Side note:
I wonder if we should support assignment into handles to limit the amount of handles:

var jstring = "حس".toJString();
array[0] = jstring;
// jstring ^= "\$".toJString(); // This is what we use for handles in the C++ code but we can't do that in Dart.
jstring.set("\$".toJString()); // always does deleteOriginal. This doesn't actually reduce the amount of handles. In our C++ code we have the handles and the references you put into handles as two different types.
array[1] = jstring;
// ...
jstring.set(array[0]);
expect(jstring.toDartString(), "حس");
// ...

Maybe this approach doesn't really work in Dart because we can't overload operators and use destructors. The destructors free the handles at the end of the syntactic scope when stack allocated.
)

[dcharkes]

lgtm

I don't have any bright ideas for releaseOriginal, but I'd liked releasedIn to be releasedBy. Released in sounds like it will be released in the arena, but it is released by the arena. (Releasing in sounds like we release the original reference but the object can still run around in the arena.)