TJson.JsonToObject funktioniert unter Delphi 10.3 nicht mehr wie unter 10.2

[sh17]

Hi, ich nutze bisher immer TJson.JsonToObject und TJson.ObjectToJsonString um Objekte serialisieren und deserialisieren zu können.

Seit Delphi 10.3 kann ich mein Objekt aber nicht mehr laden und speichern. Es kommen folgende Meldungen:

... TJson.JsonToObject<TMyObjList>(hstr);
EConversionError "Value 0 cannot be converted into Pointer. You ma use a user-defined reverter"


... TJson.ObjectToJsonString(myobj);
EConversionError "Type tkPointer is not currently supportet"

Hat sich hier etwas geändert, weiß jemand etwas?

Das Objekt ist relativ simpel.

Code:

  TMyObj = class(TObject)
  private
    FDescription: String;
    FSubject: String;
    FBody: String;
  published
    property Description : String read FDescription write FDescription;
    property Subject : String read FSubject write FSubject;
    property Body : String read FBody write FBody;
  end;
  TMyObjList = class(TObjectList<TMyObj>);

[sh17]

OK, verdammt

https://community.embarcadero.com/fo...7-rio-and-json

https://quality.embarcadero.com/browse/RSP-21685

[Rollo62]

Ich benutze dafür TJSONMarshal, das funktioniert vor und nach Rio:

Delphi-Quellcode:

function TJson_Marshal_Base<T>.DoMarshal(const AMar : TJSONMarshal) : String;
var
  LValue: TJSONValue;

begin
    LValue := AMar.Marshal( Self );
    try
        Result := LValue.ToString;
    finally
        LValue.Free;  // New: LValue temp. obj. must be freed
    end;

end;


function TJson_Marshal_Base<T>.Internal_ToString : String;
var
  LMar : TJSONMarshal;

begin
  LMar := TJSONMarshal.Create(TJSONConverter.Create, True);  

  try
      Result := DoMarshal( LMar );  // To Avoid uncaught exceptions

  finally
      LMar.Free;
  end;

end;

Rollo

[rd3]

@sh17 Hast du eine Workaround dafür? Ich habe das gleiche Problem.

[sh17]

ne, bin etwas sauer auf Emba, wie kann so etwas passieren? Da verzichtet man schon auf externe libs und dann sowas. Hab jetzt allen JSON-Krempel rausgeworfen und mach die Persistenz wieder mit XML (OXML-lib), klappt wunderbar.

[rd3]

Mist, kann darauf nicht verzichten. Und mit einem eigenen Marshaller, der implizit die JSON-Libraries benutzt, klappt es auch nicht. K*cke!

[rd3]

Das ist immer so. Ob das die verkackten Reports (damals, QuickReport, Rave usw. Dann Unicode usw.) sind oder sonst was. In komplexen Applikationen ist fast nie was kompatibel mit einer neuen Version. Immer und immer wieder. Wieso ich Idiot nicht endlich bei Visual Studio und .NET bleibe...?! Bei so viel Bugs und Hinterherhinkerei hilft auch langsam eine viel zu spät kommende Community-Edition nicht mehr...

[sh17]

Verständlich
Deswegen Pro Open Source RTL/VCL

[rd3]

Naja, in kommerziellen Anwendungen benutzen wir kein Open-Source. Wir halten 3rd-Parties auch in Grenzen. Wir benutzen DevExpress. Es geht auch um Support, worauf du im Open-Source-Bereich lange warten kannst - manchmal jedenfalls.

[sh17]

Ich meinte auch eher so wie das .net Framework Open Source ist, schon unter Betreuung von Emba, da würden solche Fehler viel eher entdeckt und behoben werden können und nicht erst zur Auslieferung der IDE. Aber das ist ein anderes Thema.

[Neutral General]

Auch wenn es nicht schön ist, aber man kann eine Kopie der Unit machen, den Bug fixen und dann die korrigierte Unit in seinen Suchpfad aufnehmen.
So haben wir es gemacht. Ist nicht zu Open Source in dem Sinne, aber man kann sich damit auf jeden Fall selbst helfen bis zum nächsten Patch

[rd3]

Yo, da stimme ich zu. Man konzentriert sich darauf, wer der nächste Eigentümer von RAD-Studio & Co. ist, statt auf Produktqualität. Schlimm genug, dass die Verbreitung so gering ist, dass ich eine beantwortete(!) Frage zu diesem Thema nicht bei StackOverFlow finde. Im Delphi-Forum und bei Delphi Praxis war ich im letzten Jahrzehnt, als Kollege jaenicke, narses, luckie & Co. die Delphi-Welt noch bei Laune gehalten haben... So, um nicht weiter zu nerven und in Nostalgie mit Themen zu verfallen, die die echten Themen überwiegen, höre ich lieber auf... ;-)

EDIT: ja, das mit dem Kopie ziehen und in sein Projektverzeichnis legen wurde mir irgendwann dann zu dämlich. Dieses Projekt noch... Immerhin war ich 5 Jahre abstinent bei Delphipraxis und im Delphi-Forum und hatte sogar in beiden Foren meinen User gelöscht. Nun das wieder... ;-)

[Der schöne Günther]

Erinnert mich an In Which I Argue That Embarcadero Should Open Source Their Unit Tests.

[rd3]

Ja, so ungefähr... :D

[Uwe Raabe]

Der Grund für diesen Fehler liegt an dem veränderten Aufbau von TListHelper. In Delphi 10.3 Rio ist das Feld FItems am Anfang hinzu gekommen.

Delphi-Quellcode:

  private var
    FItems: Pointer;
    FCount: Integer;
    FTypeInfo: Pointer;
    [unsafe] FListObj: TObject;
    FNotify: TInternalNotifyProc;
    FCompare: TInternalCompareFunc;
    function GetElType: Pointer; inline;
    function GetElSize: NativeInt; inline;

In den davor liegenden Versionen war noch FCount das erste Feld:

Delphi-Quellcode:

  private var
    FCount: Integer;
    FTypeInfo: Pointer;
    FNotify: TInternalNotifyEvent;
    FCompare: TInternalCompareEvent;
    function GetFItems: PPointer; inline;
    function GetElType: Pointer; inline;
    function GetElSize: Integer; inline;

Was der Entwickler, der diese Änderung sicher guten Gewissens eingebaut hat, offenbar nicht wusste: Die Anordnung der Felder wird in REST.JsonReflect in Form eines Dirty-Hacks verwendet. Ihn trifft insofern auch keine Schuld.

So rächt es sich eben, wenn man bei der Implementierung eines Sonderfalls (hier TListHelper.FCount) zu hastig agiert und die Sorgfalt vernachlässigt (labil agile Softwareentwicklung). Eine stabile Lösung hätte sicher etwas mehr Planung erfordert.

Der fragwürdige Code ist übrigens schon seit Delphi 10 Seattle vorhanden (stammt also noch aus der Zeit vor Idera) und es hat sich seitdem offenbar noch niemand daran gestoßen. Bei einem Code-Review durch einen erfahrenen Delphi-Entwickler wäre das mit hoher Wahrscheinlichkeit durchgefallen. Ohne einen entsprechenden Regressiontest kann man sowas im Nachhinein aber einfach nicht finden.

Wenn als Fix nun auch noch lediglich der Array-Index von 0 auf 1 und der Wert für die Längenabfrage auf 2 verändert wird, dann ist der Entwicklungsabteilung aber wirklich nicht mehr zu helfen.

[rd3]

Delphi hat keine Existenzberechtigung mehr.

[sh17]

Herje, peinlich, danke Uwe

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1420498)

Wenn als Fix nun auch noch lediglich der Array-Index von 0 auf 1 und der Wert für die Längenabfrage auf 2 verändert wird (…)

Ich bin gespannt 😂

Ich meine, alle Unit-Tests werden grün, die Kunden sind zufrieden...

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1420510)

Ich meine, alle Unit-Tests werden grün, die Kunden sind zufrieden...

Das sehe ich als eine der größten Gefahren des test-basierten Bug-Fixings.

[Der schöne Günther]

Klar. Aber ich sehe zumindest den Vorteil dass, wenn Embarcadero einen Test für diesen exotischen Anwendungsfall hätte, er rot wird bevor sie ausliefern.

[sh17]

Hätten sie mal vorher getestet, wäre es nicht einmal aufgefallen.

[Schokohase]

Zitat:

Zitat von Uwe Raabe (Beitrag 1420498)

So rächt es sich eben, wenn man bei der Implementierung eines Sonderfalls (hier TListHelper.FCount) zu hastig agiert und die Sorgfalt vernachlässigt (labil agile Softwareentwicklung). Eine stabile Lösung hätte sicher etwas mehr Planung erfordert.

Das was sich rächt ist die Unwissenheit oder Gleichgültigkeit (was es auch immer ist, eins von beiden ist es) gerade zum Thema JSON.

Mir ist kein JSON-Serializer bekannt, der für eine Liste folgendes JSON ausspuckt:

Code:

{
    "ownsObjects": true,
    "listHelper": [2],
    "items": [{
        "firstname": "First",
        "lastname": "Last"
    },{
        "firstname": "First",
        "lastname": "Last"
    }]
}

Bei allen anderen (die mir unter die Füße gekommen sind) erhalte ich

Code:

[{
    "firstname": "First",
    "lastname": "Last"
},{
    "firstname": "First",
    "lastname": "Last"
}]

Aber es kompiliert ...

Wenn man sehen möchte, wie das funktionieren müsste, der schaut sich mal die Kopiervorlage für die Delphi-Implementierung an: https://www.newtonsoft.com/json

[Hobbycoder]

Ist dieser Fehler eigentlich in 10.3.2 behoben? Weiß das einer?

[sh17]

Das ticket ist zumindest geschlossen worden.

[Rolf Frei]

Gemäss der Patchliste zu 10.3.2 sollte das gefixt sein:

http://docwiki.embarcadero.com/RADSt..._Studio_10.3.2

[Hobbycoder]

Hoffentlich nachhaltig ;-)
Aber ich warte mit dem Update sicherheitshalber noch ein bischen, bis sich Delphi 10.3 Release 2 verfügbar (10.3.2) gelegt hat.