[MyEclipse] Hot code replace probleem

[JKVA]

Sinds een tijdje werk ik nu met MyEclipse voor J2EE ontwikkeling. Als applicatieserver draai ik JBoss. Het idee van hot code replace is allemaal leuk en aardig, maar als ik een klasse save, krijg ik meteen een melding in de trant van "Scheme change not implemented" en meer van die meldingen.

Aan de hand van wat bronnen op internet heb ik begrepen dat het een fout is in de implementatie van Java. En dit zal ook niet op korte termijn opgelost worden.

Nu is mijn vraag: heeft iemand een oplossing of workaround voor dit probleem? Of is het iets waar je maar mee moet leren leven?

[ronaldmathies]

Je doet wel een exploded deployment?

[JKVA]

Jup, maar ik denk al een "workaround" gevonden te hebben. Namelijk het project cleanen waardoor alles opnieuw gedeployed wordt. Het is wel traag en tijdens debuggen minder fijn dan hotswappen, maar in ieder geval meer werkbaar dan de server restarten.

[flowerp]

JKVA schreef op dinsdag 07 maart 2006 @ 09:44:
Sinds een tijdje werk ik nu met MyEclipse voor J2EE ontwikkeling. Als applicatieserver draai ik JBoss. Het idee van hot code replace is allemaal leuk en aardig, maar als ik een klasse save, krijg ik meteen een melding in de trant van "Scheme change not implemented" en meer van die meldingen.

Wat MyEclipse in de eerste instantie doet is natuurlijk alleen hot deply (copieeren van files van je workspace naar je deploy locatie). Het is dan aan de AS en de VM of het die veranderingen pikt. De JVM is helaas erg slecht in het runtime doorvoeren van veranderingen. Het zit allemaal wel in de Java specificatie, maar is 'simpelweg' niet geimplementeerd. De volgende versie van Java zal wel 'iets' meer code hot kunnen replacen, maar het blijft erg weinig.

Wat wel altijd kan is code IN een method veranderen, dat kan altijd. Maar zodra je method signatures gaat veranderen, nieuwe methods gaat toevoegen etc, dan komt die dreaded "not implemented" exception.

[JKVA]

flowerp schreef op vrijdag 10 maart 2006 @ 23:12:
[...]


Wat MyEclipse in de eerste instantie doet is natuurlijk alleen hot deply (copieeren van files van je workspace naar je deploy locatie). Het is dan aan de AS en de VM of het die veranderingen pikt. De JVM is helaas erg slecht in het runtime doorvoeren van veranderingen. Het zit allemaal wel in de Java specificatie, maar is 'simpelweg' niet geimplementeerd. De volgende versie van Java zal wel 'iets' meer code hot kunnen replacen, maar het blijft erg weinig.

Wat wel altijd kan is code IN een method veranderen, dat kan altijd. Maar zodra je method signatures gaat veranderen, nieuwe methods gaat toevoegen etc, dan komt die dreaded "not implemented" exception.

Heeft iemand toevallig een idee hoe je die hot deployment kunt uitschakelen? Dan maar een complete klasse compilen, het is altijd beter dan een complete verse deployment van de webapp.

[flowerp]

JKVA schreef op zaterdag 11 maart 2006 @ 19:31:
[...]
Heeft iemand toevallig een idee hoe je die hot deployment kunt uitschakelen? Dan maar een complete klasse compilen, het is altijd beter dan een complete verse deployment van de webapp.

Ik zou het zelf niet handig vinden om hot deployment uit te schakelen. Je moet dan na elke verandering in 1 van je files met de hand 'delta' deployen. Daar wordt je snel moe van hoor. Maar als dat is wat je wilt, dan kun je dit op meerdere manieren bereiken. De makkelijkste manier is om je project niet meer op auto-build te zetten. Ook kun je als WAR deployen ipv als exploded.

Maar zelfs als je dat doet dan zal je draaiende AS niet opeens magisch wel de veranderingen hot accepteren hoor! Het is niet het feit dat MyEclipse incrementele veranderingen in class files naar de AS stuurt (dat gebeurd namelijk niet), maar het feit dat de VM classes al geladen heeft en dat deze in gebruik zijn. Code kan bijvoorbeeld 'functie pointers' (de Java reflection variant dus) naar classen opgeslagen hebben. Als jij ondertussen hot de method signature veranderd (bv een parameter type veranderd), of nog erger die hele method verwijders, dan zal die andere code hierop vastlopen.

Dus ook al zou je 'den hele class hercompileren' (wat dus al gebeurd!), dan nog moet je de AS herstarten.

MyEclipse heeft sinds 4.0 wel een shortcut hiervoor. Ipv de juiste AS opzoeken in je toolbar, dan stop clicken, vervolgens weer opzoeken en start clicken, hoef je nu alleen nog maar op het bijbehorende icon te clicken. Dit stopt en start (effectief een herstart dus) de laatst gestarte AS.

De echte fix voor dit probleem kan alleen door de JVM gedaan worden. Zoals gezegd, Versie 6 lost een paar kleine dingetjes op maar veel is het niet. Zowieso zul je nog een paar jaar moeten wachten voor je versie 6 mag gebruiken (tenzij je voor prive dingen programmeerd natuurlijk).

[JKVA]

Ok dank voor de uitgebreide uitleg. Dat scheelt mij veel zoekwerk in MyEclipse. (waar het probleem dus niet zit) Voortaan maar gewoon het project cleanen. Dat scheelt iig de startuptijd van de server en zo.

[flowerp]

JKVA schreef op zondag 12 maart 2006 @ 16:22:
Ok dank voor de uitgebreide uitleg. Dat scheelt mij veel zoekwerk in MyEclipse. (waar het probleem dus niet zit) Voortaan maar gewoon het project cleanen. Dat scheelt iig de startuptijd van de server en zo.

Afhankelijk van hoeveel JSP pagina's je in je project hebt is project cleanen nog wel het aller langzaamst. Dan kan namelijk elke JSP file overnieuw gevalideerd moeten worden. Zelfs op een P4 3.2Ghz duurt dat nog ongeveer 1 seconden per pagina. Heb je 1500 pagina's dan kun je wel even een rondje door het kantoor gaan socializen voordat ie klaas is.

Je kunt overigens ook gewoon de melding negeren als je niet perse de aangepaste code meteen wilt gebruiken. Scheme change failed etc kan opzich geen kwaad, betekend alleen dat je nog de oude class gebruikt in je draaiende server.

Tomcat met de standaard instellingen herstart bij elke verandering die je maakt in een class file. Druk je dus tussentijds uit gewoonte vaak op save, dan gaat ie telkens herstarten. Dit ligt dan weer bij Tomcat en niet bij de JVM en alleen indirect bij MyEclipse.