Dette emnet omhandler migrering av Java-kode fra VisualAge for Java.
Når du endrer en Java-komponent ved hjelp av det visuelle redigeringsprogrammet for Java, blir kildekoden oppdatert, slik at endringene vises. Endringene i kildekoden gjenspeiles i set-metoder som endrer egenskapsverdiene. Noe av informasjonen som det visuelle redigeringsprogrammet for Java bruker, blir imidlertid ikke lagret i egenskaper, ettersom den bare kreves under designfasen. Denne informasjonen omfatter plasseringen av en Java-bønne på overflaten med fritt format.
Hvis denne informasjonen skal lagres, slik at det visuelle redigeringsprogrammet for Java kan åpnes på nytt med samme plassering av Java-bønnen, blir informasjonen plassert i en kommentar på linjen som deklarerer Java-bønnen. Følgende setning viser en JFrame-komponent som er plasser i 16,17:
private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info decl-index=0 visual-constraint="16,17"
Kommentaren som representerer plasseringen av en komponent, er ikke obligatorisk, og hvis det ikke er oppgitt en kommentar, blir det tildelt en standardplassering når det visuelle redigeringsprogrammet for Java blir åpnet. Standardplasseringen gjelder bare for Java-bønner på toppnivå som ikke ligger i hverandre, og har ingen innvirkning på plasseringen av komponenter i en container. Plasseringen av komponenter i en container blir bestemt av containerens layoutstyrer og komponentens grenser eller begrensninger.
I VisualAge for Java er ikke plasseringen av Java-bønner på toppnivå (også kalt deler i fritt format) oppgitt i kildekoden. Hvis du migrerer en fil som ble skrevet med VisualAge for Javas VCE (Visual Composition Editor), blir det brukt standardplasseringer. Hvis du vil beholde den posisjonsavhengige informasjonen, kan du få tak i et migreringsprogram som lastes inn i VisualAge for Java. Migreringsprogrammet genererer klassene på nytt med plasseringen som er lagret i et kommentarformat. Du får tak i dette programmet ved å laste ned siste Conversion tool for VisualAge for Java Visual Composition Editor applications fra www.ibm.com/support/us/
Migreringsprogrammet er tilgjengelig som en midlertidig rettelse som kan installeres ved hjelp av VisualAge for Javas FixManager (fra Workspace > Tools > FixManager). Programmet migrerer og eksporterer klasser som er utviklet med VisualAge for Javas VCE til et format som passer til det visuelle redigeringsprogrammet. Når rettelsen er installert, kan du velge VCE Code Generation/Export... fra hurtigmenyen til prosjekter, pakker eller klasser. Hvis du velger dette elementet, blir det startet en veiviser som kan generere koden for klassene som tidligere er lagret i VCE, på nytt. Plasseringene i fritt format blir lagret i kommentarformatet som det visuelle redigeringsprogrammet bruker.
Hvis du har tilkoblinger, kan du først generere denne koden på nytt ved å velge VCE-kodegenereringsalternativet Use an inner class for each event før du kjører dette programmet. Noen klasser kan imidlertid ikke konverteres til denne stilen, på grunn av en programfeil i VisualAge for Java. I dette tilfellet skal du bruke VCE-kodegenereringsalternativet Use one inner class for all events. Veiviseren lar deg også velge om du vil eksportere klassene til en katalog når kodegenereringen er utført. Støtten for hendelser i det visuelle redigeringsprogrammet for Java vil ikke analysere VCE-kodegenereringsstilen Do not use any inner classes.
Ettersom VCE vedlikeholdt sin egen modell av Java-bønnene og deres egenskapsverdier og forhold, ble koden alltid generert på nytt fra topp til bunn fra denne modellen. Eventuelle endringer som en bruker gjorde i kilden, var begrenset til forhåndsdefinerte brukerkodepunkter i kilden avgrenset av kommentarene //user code begin {1} og //user code end. For å vise at metodene for Java-bønnene ble generert på nytt hver gang kodegenerering ble utført, ble også linjen /* WARNING: THIS METHOD WILL BE REGENERATED. */ lagt til i kommentaren til metoden. Migreringsprogrammet har et alternativ som fjerner disse VCE-genererte kommentarene fra den eksporterte koden (ikke kildekoden i VisualAge for Java), siden de ikke lenger kan brukes utenfor VCE. Når kommentarene til brukerkodepunktene er fjernet fra kilden, kan imidlertid ikke brukerkoden brukes i VisualAge for Java. Årsaken er at det er disse kommentarene som beskytter brukerkoden slik at den ikke blir overskrevet.
Det visuelle redigeringsprogrammet for Java bruker ikke en permanent objektmodell til Java-bønnene og deres egenskapsverdier og forhold, men analyserer i stedet kilden hver gang. Kommentarene for brukerkodepunkter og for ny generering av metoder gjelder derfor ikke lenger, og kildekoden kan endres fritt. Hvis endringene gjør at kildekodestrukturen endres slik at det visuelle redigeringsprogrammet for Java ikke lenger gjenkjenner strukturen til Java-bønnene, ser du dem kanskje ikke i Design-visningen eller i visningen Java-bønner. Kilden blir imidlertid ikke endret for å passe til redigeringsprogrammets stil, og endringene blir bevart.