Dalija Prasnikar

For me Tokyo works fine with JDK 1.8_60, but I don't have Java 9 installed, so I don't know whether this could be the problem or not.

Sorry. There was some other thing but I don't remember exactly. One thing that also does sound strange in your config is that you have selected platform-28 and it says Android SDK 25..x.x

Change the JDK paths back to 1.8 in Delphi Android SDK settings under Java tab. (Last screenshot)

This is due to inner TList structural changes. FItems were moved from TList<T> into ListHelper class and its type has been changed into a pointer. AFAIK this issue (limited debugging) has been reported, but report is not yet publicly available

As far as Beta bug reporting is concerned there are few things to know. 1. Not all bugs reported during Beta test are resolved during Beta test period. 2. Beta test bugs are tracked separately from main RSP tracker. 3. Beta test bugs that are still not resolved are moved to main RSP tracker project. 4. Moving issues to public tracker requires some administrative work - it is not just simple move all procedure - and it takes some time. At this moment unresolved Rio beta test issues are still not publicly available.

Delphi in VM and Android debugging don't work well together. Actually, I never managed to debug Android from VM. If not in VM debugging on Android works fine, most of the time.

Automatic invocation is the whole point of managed records. If they have constructors and destructors, you want them to run. Yes, you can do that manually, but then they would not be called managed records. If you don't want managed records, and you want to perform some initialization and finalization code manually, you can use plain record procedures. You don't need constructors and destructors in that case.

One of the problems with ARC enabled and having [unsafe] as default is that you cannot release object that has disabled reference counting. [unsafe] is only for marking additional references on objects whose memory is managed at some different place (reference). Of course, you can say that compiler would need some tweaking to allow destroying such objects, but it is very likely that at some point the whole construct would fall apart. I never gave mush thought to such "solution" because it seems pointless. Point is. ARC compiler was done right as far as its default behavior is concerned. There are few things around DisposeOf that could be polished, and some other minor bugs that are just bugs, not design flaws. ARC compiler fits the best into existing Delphi infrastructure and neatly fixes issues around object and interface references. Other solutions and workarounds will be poor substitutes and will not solve that duality problem. I wish I would be wrong on this one. I sincerely hope I am wrong and that there is another approach that will not be just a band aid, but full fledged solution.

But with normal var declarations you are forced to explicitly write the type for the variable. In this case, you can easily forget that you have to explicitly declare variable as interface and rely on type inference which will get it "wrong".

This is truly great and long missed feature. Truly great. But... I hate buts... there are things to watch out. Namely, type inference breaks reference counting. It is one of those don't mix objects and interfaces pitfalls. Should I say that this works perfectly on ARC compiler 🙂 If you have reference counted class, you cannot rely on type inference, you have to specify the interface type. // broken var Instance := TInterfacedObject.Create; // not broken var Instance: IInterface := TInterfacedObject.Create;

@Marco Cantu No matter how you turn it something is not quite right. I can certainly see why you made the choice you made. Both now, and back then when ARC was introduced. I hope that for the sake of present we (saying we because non-ARC is clearly what your customers want) didn't sacrifice the future.

@Sherlock If you get warnings, then this is kind of code that needs to be changed for ARC. But the change you do (depending on the actual code you need to change) will work across all compilers without warnings.

Just for the record, unless you have to change methods signatures - adding const param, and for some reason you need to keep old signature too, porting to ARC compiler itself does not require any IFDEFS. All needed changes are compatible with all compilers.

I found the report for Linux compiler that may have some impact on speed comparing to Windows (regardless of ARC) Linux x64 compiler produce very bloated code

1. Totally understandable. You cannot use ARC to its full potential and you are only paying the price. 2. I assume it was Linux vs Windows, It would be interesting to see how it compares with ARC removed. Comparing x86 with ARM is comparing apples with oranges - ARC or no ARC. AFAIK, LLVM backend has some influence on performance, too. There are some reports about inefficient code generation - something not ARC related. Performance mostly suffers because of existing code that is not written for ARC - unnecessary reference counting triggers are real performance killers. It is not fault of ARC per-se. 3. LOL - it is the same memory management model, (if you remove DisposeOf out of the picture) so pitfalls are exactly the same. Developing for ARC requires a bit different mindset.

I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure. More thoughts... ARC is dead, long live ARC