Moin,

was ist der Vorteil von dem Keyword transient?

ich nutze seit kurzem PMD mit einem Standard ruleset und bei Instanz Variablen wird immer markiert das diese nicht transient oder statisch sind. statisch geht nicht weil Instanz variable, aber transient?

nun frage ich mich was ist der Vorteil davon?

transient heißt doch, soweit ich weiß, nur das diese Variable nicht serialisiert werden darf.

also warum markt PMD das so, es gibt fälle da dürfen die Felder Serialisiert werden oder es ist da schlicht egal. Zumal ich in keiner Klasse Serializable implementiere und dadurch die frage erübrigt ob die Variable Serialisiert werden darf oder nicht.

Nun ... da wir grade in einem anderen Thread auch übers serialisieren gesprochen haben kommt die Frage : von was leitest du ab ? Wenn du z.B. von Component ableitest wird das dort implementierte Serializable Interface mit vererbt. Das geschiet auch bei vielen anderen Klassen.

Ohne Source werden wir dir so nicht weiterhelfen können.

Was aber bis hier her stimmt : das Keyword transient bedeutet das der Inhalt einer Variable beim serialisieren nicht mit gespeichert wird ... und dementsprechend beim deserialisieren auch nicht vorliegt und man also dafür sorgen muss das dieser Inhalt beim deserialisieren neu berechnet wird. Das Sun-Tut hilft da ein ganzes Stück weiter.

ps : was ist PMD ?

Hi

http://openbook.galileodesign.de/jav...0004041F0461E4

...zu lange gesucht...

Moin,

Zitat von SPiKEe

ps : was ist PMD ?

vermutlich dies hier : http://de.wikipedia.org/wiki/PMD_%28Software%29

Gruß
Klaus

@sheel
Thema verfehlt, das transient zum aussparen bei Serialisierung ist schrieb ich eingangs bereits.
Mir ging es darum ob es noch weitere Vorteile bringt.

@vfl_freak
genau

@SPiKEe
Zu PMD, das ist ein Code Check zur sauberen Implementierung. CleanCoding

Und bei Jungfräulichen Klassen die nichts extenden oder Implementieren meckert der Code Check das transient oder static fehlt.

static macht keinen sinn da wie Eingags beschrieben es sich um Instanz variablen handelt.
transient eigentlich auch nicht, da 1. die Klasse selber nicht zu Serialisieren ist und 2. die Felder serialisiert werden dürfen, wenn man irgend wann die Klasse Serialisieren will.


Oder ist diese Markierung nur als Vorschlag zu betrachten der zu vernachlässigen ist? Wie diese Unshecked Cast Warning wenn man Listen etc aus APIs holt die mit JDK < 1.5 sind und man selber mit JDK >= 1.5 arbeitet


PS: Es handelt sich lediglich um ein Verständnis Thema, nicht hilfe mein Prog Funktioniert nicht

Zitat von wakoz

@sheel
Thema verfehlt, das transient zum aussparen bei Serialisierung ist schrieb ich eingangs bereits.
Mir ging es darum ob es noch weitere Vorteile bringt.

Auch das wird beantwortet.

Zitat von sheel

Auch das wird beantwortet.

Hast du das gelesen was du da Verlinkst? mal davon abgesehen das im Link Version 5 des Buches ist, steht in Version 8 zu dem Thema auch nichts neues.

Und es geht da nur um das aussparen von Variablen und Objekten, bezüglich Sicherheit (Daten Schutz) und undefinierter Zustände von Objekten (Threads und Streams) die nicht serialisiert werden können. Für mich nichts Neues

Ansonsten steht da nichts, oder hast du in einem anderen Bereich der Erklärung der Serialisierung etwas zu weiteren Vorteilen des transient modifiers gelesen?

wird dadurch die Performance erhöht? oder Speicher Verbrauch der Anwendung minimiert? Oder etwas anders?

Die Große Frage bei mir ist, Warum Markiert PMD meine Instanz variablen mit es Fehlt transient. Eine Instanz Variable die Serialisiert werden kann und dessen Inhalt in gewissen Klassen meines Programmes auch Serialisiert wird, um diese in eine OracleDB zu schreiben oder über eine Internet Verbindung zu Übertragen.

Bringt transient Vorteile? Wenn nein, dann ist die Markierung unwichtig und kann aus dem Rulset gelöscht werden. So markert PMD nie wieder eine variable mit dieser Meldung.

Und es ist kein Vorteil wenn ich aus Grund der Nicht Serialisierbarkeit eines Objektes oder eines Attributes dieses Ausspare. Es ist schlicht weg eine Notwendigkeit die ich zu beachten habe wenn ich eine klasse serialisieren will, die Felder enthält die nicht Serialisiert werden können oder aus Datenschutz Gründen nicht Serialisiert werden sollten.

Also da ich nur mal schnell über den Wiki-Artikel von PMD geflogen bin würde ich vermuten das hier das Ruleset von PMD versagt / ziemlich schlecht implementiert ist. Was ich mir vorstellen könnte wäre das er meckert weil er einige Abhängigkeiten nicht auflösen kann um zu merken das gewissen Variablen irgendwann irgendwo doch serialisiert werden (können). Was das mit dem static-Fehler angeht : FAIL *sorry ... anderst kann ich es gerade nicht ausdrücken*. Ich glaube das einige Rulesets nicht ganz so arbeiten wie es mal von den Entwicklern gedacht war ... von daher würde ich ganz einfach sämtliche Rules die "schwachsinn" sind schlicht löschen ... weil was wäre das denn für ne "Optimierung" wenn ich ne Instanzvariable STATIC makiere ? Da würde dann am Ende noch der Compiler meckern.


Um aber deine konkrete Frage zu beantworten : NEIN ! transient hat KEINE Vorteile. transient dient *wie von uns mehrfach erwähnt* lediglich dazu zur Runtime der VM mitzuteilen : dieses Objekt darf nicht serialisiert werden ... nicht mehr und nicht weniger. Warum PMD trotzdem meckert : Fehlerhafte Rules ...

Zitat von SPiKEe

transient dient *wie von uns mehrfach erwähnt* lediglich dazu zur Runtime der VM mitzuteilen : dieses Objekt darf nicht serialisiert werden ... nicht mehr und nicht weniger.

Von uns allen

Zitat von SPiKEe

Um aber deine konkrete Frage zu beantworten : NEIN ! transient hat KEINE Vorteile.

Danke.

Zitat von SPiKEe

Warum PMD trotzdem meckert : Fehlerhafte Rules ...

Nun ja es ein Warning und ich lasse ungern Warnings im Code
Nun da ich weiß das es unwichtig ist kann ich es ruhig aus dem Ruleset Löschen, wer Öfters Serialisiert sollte dies aber nicht tun! Da es dann doch ein netter Hinweis sein kann um Fehler zu vermeiden.

Danke

Generell sollte man PMD, FindBugs und Co. immer auf seine Bedürfnisse anpassen, da das Standardruleset nicht in jedem Stück Software sinnvoll ist, aber in den meisten Fällen imo. Ich hatte auch schon den Fall, dass verschiedene Tools sich gegenseitig gestört haben, weil man es nicht beiden recht machen konnte.

Diese Regel um die es hier geht, es sicherlich nur sinnvoll zu benutzen, wenn man irgendwo überhaupt serialisiert.
Aber anders herum kann man auch argumentieren, dass das Interface Serializable direkt oder indirekt implementiert ist und somit die Klasse generell serialsierbar sein muss und somit man den "Fehler" beheben soll. Ähnlich wie eclipse standardmäßig meckert die serialVersionUID zu setzen.
Aber mehr will ich dazu auch nicht sagen, ich wollte nur eine andere Sichtweise darauf aufzeigen. Im Endeffekt muss man selbst entscheiden was Sinn macht und was nicht.

P.S.: Die Variable statisch zu machen ist auch ein Weg die Serialisierung zu umgehen, da statische Variablen nicht serialisiert werden.