[Java] VM niet volledig OO?

[Robtimus]

Ik zal het even uitleggen met een voorbeeldje.

Ik verstuur via het netwerk objecten van een bepaald type, Tuple. Dit kunnen instanties van Tuple zelf zijn, of instanties van subklassen. De ontvangende kant ontvangt deze als zijnde Tuple; het precieze type doet er niet toe.

Je zou denken dat de VM niet hoeft te weten dat het ontvangen object van type TupleSub (bv) is, alleen van type Tuple. Dus zou (in mijn ogen) de class file van TupleSub niet nodig moeten zijn. Hij heeft die echter wel nodig; zonder krijg je een ClassNotFoundException.
Dus zodra je tussen VM's gaat werken, dan verdwijnt juist het grote voordeel van supertypes en interfaces! De VM moet dan nml wel weten welk type het precies is.


Ik weet denk ik ook waardoor het komt: de definitie van een object ligt alleen opgeslagen in de betreffende class file. Niet alleen extra velden/methods (die in principe in dit geval onbelangrijk zijn), maar ook (en dit is wel belangrijk) de class name en supertype; de indentificatie van de class dus. Je zal ook nooit zonder deze kunnen.

Ik begrijp dus wel waarom het zo is, ik vind het alleen een beetje jammer.

Ben ik de enige die er zo over denkt?

(en kom alsjeblieft niet aan met URLClassLoaders etc, die ken ik al)

[Tuinhark]

Werk je met RMI ofzo?

Want dat heeft (tegenwoordig) als het goed is een methode om dynamisch skeleton classes te genereren om dit soort fratsen af te vangen. Voorheen moest je die dingen eerst zelf maken middels rmic.

Als je met pure Serialization werkt, dan ontkom je er niet aan dat de classes van de ontvangen objecten ook aanwezig zijn.

Correct me if I'm wrong.

[ACM]

De metadata die bij een Object hoort zit in het bijbehorende Class-object, idd niet in het Object zelf omdat je dan een enorme overhead per object hebt. Die metadata heb je in elke VM nodig waar je de betreffende Objecten gebruikt en inderdaad, die zal je zelf moeten verzorgen.
't Zou wel leuk zijn als de ontvangende VM bij een onbekend type de verzendende VM gaat vragen om de klasse-definities, maar echt de metadata in het Object zelf op gaan slaan lijkt me onverstandig.

[Verwijderd]

Het heeft ook nog eens security implicaties als de remote host lukraak dynamisch classes gaat importeren, (want zonder deze preciese classes weet de deserializer aan de andere kant niet wat hij met de data aan moet) maar natuurlijk is dit ook af te vangen met securitymanagers et al, maar vaak wil je gewoon helemaal niet dat er ineens vreemde objecten bij je server gegooid worden.

Edit: En het kan ook heel lastig worden, neem bijvoorbeeld het geval met meerdere clients. Twee clients hebben een totaal verschillende versie van Myprogram.ShinyNewTuple en willen objecten van die class naar de server sturen. De server gaat braaf objecten importeren van de client, waardoor je op zijn minst foutmeldingen krijgt of zelfs incorrecte resultaten.

[ Voor 34% gewijzigd door Verwijderd op 15-03-2004 13:19 ]

[martijn_brinkers]

Toch klopt het zoals java het doet. Hoe had jij gedacht dat het anders zou kunnen? Je wil nl een supertype van Tuple oversturen. Deze supertype kan bijv. methods overridden hebben om zodoende functionaliteit te veranderen van de base class (de Tuple class). Hoe wil je er nou voor zorgen dat je niet hoeft door te sturen hoe jouw supertype is geimplementeerd terwijl je wel gebruik wil maken van deze nieuwe functionaliteit? Misschien denk je dat je al die class door hebt gestuurd omdat je via serialization de volledige state hebt doorgestuurd. Echter moet er natuurlijk wel een class zijn die deze weer de-serialiseerd. Vandaar dat je dus de classe definitie nodig hebt van je super classe en dus een class not found krijgt als deze er niet is

[Robtimus]

Tuinhark schreef op 15 maart 2004 @ 13:05:
Werk je met RMI ofzo?

Ook, dus ik ben wel bekend met stubs van de RMI objecten. Echter de data die wordt verstuurd heeft dit voorbeeld niet (voor zover ik weet).

Verwijderd schreef op 15 maart 2004 @ 13:15:
Edit: En het kan ook heel lastig worden, neem bijvoorbeeld het geval met meerdere clients. Twee clients hebben een totaal verschillende versie van Myprogram.ShinyNewTuple en willen objecten van die class naar de server sturen. De server gaat braaf objecten importeren van de client, waardoor je op zijn minst foutmeldingen krijgt of zelfs incorrecte resultaten.

Volgens mij krijg je daar ook last van als je die classen dmv URLClassLoaders ophaalt; de eerste gaat wel goed, maar probeert de VM dan niet het tweede (andere) object ook te mappen op de dan aanwezige Myprogram.ShinyNewTuple class?


Verder begrijp ik het wel hoor, ik vind het alleen in dit geval een beetje jammer.

[Verwijderd]

voor complexe, arbitraire objecten zit je gauw vast aan pass-by-reference semantics inderdaad..

[Macros]

Ik heb niet alle replies gelezen, maar het is wel logisch dat hij de sub-classes nodig heeft. Anders werkt polymorphie helemaal niet.