[java] Hot code replace - add method not implemented

[Verwijderd]

De Java vm heeft de mogelijkheid om hot code te kunnen updaten. Dit is vooral makkelijk in de debug sessie of voor een application server (zoals tomcat).

Met de Java 5 VM en Tomcat 5.5 werkt dit goed als je code toevoegt aan een bestaande functie. Helaas krijg je bij het toevoegen van een gehele nieuwe functie aan een class die al geladen is door de class loader een exception met de melding dat "add method" nog niet geimplementeerd is.

M.a.w. het zit wel in de API, maar men heeft nog niet de tijd gevonden om die functie ook echt te implementeren.

Nu zit ik wat rond te zoeken, en kan eigenlijk nergens een ETA vinden voor wanneer men (wie dan ook), dit WEL gaat doen. Het staat op geen enkele roadmap lijkt het.

Wie weet meer?

[Macros]

Ik heb hetzelfde bekeken. Volgens mij gaat Mustang (versie 6.0) iets meer ondersteunen, maar niet drastisch meer.
Wat je niet kan doen (class inits en constructors zijn ook methods):
- class modifiers veranderen
- interfaces toevoegen, deleten of volgorde veranderen
- method modifiers veranderen
- method signatures veranderen
- methods toevoegen
- methods deleten
- field modifiers veranderen
- fields toevoegen
- fields verwijderen

Persoonlijk vind ik dat alles wat alleen dingen toevoegd toegestaan zou moeten zijn, maar de VM controleerd al deze dingen. Wat je wel kan doen is de Mustang source downloaden, de checks weghalen en kijken of het daarna in jouw applicatie nog werkt. Enige probleem is dat de build van de Java VM afschuwelijk ingewikkeld is en dat je wel een hele dag zoet bent om alles te builden.

[Verwijderd]

Macros schreef op vrijdag 07 oktober 2005 @ 16:58:
Ik heb hetzelfde bekeken. Volgens mij gaat Mustang (versie 6.0) iets meer ondersteunen, maar niet drastisch meer.
Wat je niet kan doen (class inits en constructors zijn ook methods):
- class modifiers veranderen
- interfaces toevoegen, deleten of volgorde veranderen

Interface toevoegen geeft een hierarcy changed not implemented melding. Goede diagnostics

Ik vind het wel erg veel dat niet implemented is. Blijkbaar is de spec iets te ruim opgezet. Mustang builden schijnt inderdaad complex te zijn (zoals elke java VM eigenlijk). Als ik het goed begreep is elke build ook alleen voor 1 specificieke versie van gcc geschikt.

[Macros]

Je hebt 2 verschillende versies van gcc nodig geloof ik, en nog een hele andere zwik van dependencies naar libs en bepaalde properties.

Ik zelf probeerde dingen te veranderen dmv java.lang.Instrumentation, maar ze gebruiken beide dezelfde techniek om classes te reloaden in de VM.

[misfire]

Hot code replace zal voorlopig niet uitgebreid worden door Sun. Het zal waarschijnlijk in de spec staan om het voor andere partijen mogelijk te maken een VM te maken die dit soort dingen wel ondersteunt. Helaas is geen enkele VM bouwer er tot nu toe in geslaagd om dit soort opties toe te voegen. Het is dan ook bijzonder complex en foutgevoelig om methodes en velden toe te voegen of te verwijderen.

Voor het debuggen is hot-code replace in code blocks in principe voldoende. Zodra je aan velden en methodes gaat sleutelen ben je in principe toch al aan het re-designen, tijdens het debuggen (zou) je dit niet vaak hoeven te doen.

Ik mis de hot-code replace mogelijkheid vooral voor just-in-time byte-code manipulaties. Dat lukt je nu dus in veel gevallen niet met hot-code replace. Het enige alternatief is callen naar een eigen classloader en die recyclen zodra je een klasse wilt wijzigen. Dat is niet zo efficiënt en er zitten haken en ogen aan.

In .NET kan het helaas ook niet, daar is het nog veel ingewikkelder om dit soort dingen te doen...

[Macros]

Smalltalk ondersteund al jaren het toevoegen en verwijderen van fields, methods en andere aspecten van classes. In Ruby zijn dit soort dingen ook mogelijk.
Nu zijn dit script talen, maar ik zie geen bezwaar om dit soort dingen ook in een JIT VM te implementeren. Ik denk dat de vraag ernaar gewoon niet voldoende is.

[misfire]

Dat het in Java veel moeilijker is heeft te maken met hoe de runtime is geïmplementeerd, het heeft niet zo veel met de taal Java te maken. De crux zit hem in het manipuleren van aanpassingen die tot gevolg hebben dat meerdere class definities moeten worden "hot replaced". Ook het toevoegen van fields en methodes kunnen dit als gevolg hebben, vanwege potentiële inheritance met andere super/subklasses. Voor field manipulaties moeten ook de object memory blocks van de objecten die al actief zijn worden aangepast.

Het is allemaal ook niet onmogelijk in Java, maar wel een stuk moeilijker dan alleen bodies vervangen. Als je denkt dat je een makkelijke manier weet hoe het moet dan kun je altijd de Mustang source pakken, het er even bij schrijven en submitten.

[Macros]

De meeste code om een class te reloaden is al aanwezig in Mustang. Als je een class replaced worden bijna alle classen die afhankelijk van die class zijn opnieuw door de JIT gehaald.
Smalltalk gebruikt ook een heap, en ja, als je een field toevoegd is dat een dure operatie. De geheugen layout van al die objecten op de heap moet worden vervangen, maar het is niet onmogelijk. Sun's dev team is waarschijnlijk te klein, en het staat niet hoog genoeg op de prioriteiten lijst.