Este tópico fornece informações sobre a migração do código Java do VisualAge para Java.
Quando você faz alterações em um componente Java utilizando o editor visual para Java, o código fonte é atualizado para refletir as alterações. As alterações do código fonte são refletidas nos métodos set que alteram os valores de propriedade. No entanto, algumas informações utilizadas pelo editor visual para Java não são armazenadas nas propriedades porque elas são requeridas apenas no tempo de design. Isso inclui a posição de um Java bean na superfície livre.
Para armazenar essas informações para que o editor visual para Java possa ser reaberto com o Java bean na mesma posição, elas são colocadas em um comentário na linha que declara o Java bean. A seguinte instrução mostra um componente JFrame que está posicionado em 16,17:
private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info decl-index=0 visual-constraint="16,17"
O comentário que representa a posição de um componente não é requerido e, se nenhum comentário estiver presente, uma posição padrão será alocada quando o editor visual para Java for aberto. Esse posicionamento padrão aplica-se apenas aos Java beans de nível superior que não estão contidos em outro e não afeta o posicionamento de componentes em um contêiner. O local de componentes dentro de um contêiner é determinado pelo gerenciador de layout do contêiner e pelas limitações ou restrições do componente.
No VisualAge para Java, a posição dos Java beans de nível superior (também referido como partes livres) não está presente no código fonte. Se você migrar um arquivo que tenha sido gravado utilizando o VCE (Visual Composition Editor) do VisualAge para Java, serão utilizadas as posições padrão. Para manter as informações de posição, é possível obter um utilitário de migração que seja carregado no VisualAge para Java. Ele permite regenerar suas classes com a posição armazenada em formato de comentário. Para obter o utilitário, faça download da Ferramenta de conversão para aplicativos do Visual Composition Editor do VisualAge para Java mais recente a partir de www.ibm.com/support/us/
Esse utilitário de migração está disponível como uma correção temporária que pode ser instalada utilizando o FixManager do VisualAge para Java (em Espaço de Trabalho > Ferramentas > FixManager). O utilitário migra e exporta classes que foram desenvolvidas por meio do VCE do VisualAge para Java para um formato adequado do editor visual. Depois de instalar essa correção, você poderá selecionar Geração de Código do VCE/Exportar... no menu pop-up de projetos, pacotes ou classes. A seleção desse item ativa um assistente que pode regenerar o código para classes que foram salvas anteriormente com o VCE. As posições livres são salvas no formato de comentário utilizado pelo editor visual.
Se você tiver conexões, será possível regenerar esse código primeiro, selecionando a opção de geração de código do VCE Utilizar uma Classe Interna para cada Evento antes de executar esse utilitário. No entanto, algumas classes não poderão ser convertidas para esse estilo devido a um erro no VisualAge para Java. Nesse caso, você deverá utilizar a opção de geração de código do VCE Utilizar uma Classe Interna para todos os Eventos. O assistente também fornece a opção para exportar as classes para um diretório após a conclusão da geração de código. O suporte do editor visual para eventos Java não analisará o estilo de geração de código do VCE Não utilizar classes internas.
Como o VCE mantinha seu próprio modelo de Java beans e seus valores de propriedade e relacionamentos, ele sempre regenerava a origem de cima para baixo a partir desse modelo. Quaisquer modificações feitas pelo usuário na origem eram limitadas para pontos de código do usuário predefinidos na origem delimitada por comentários //user code begin {1} e //user code end. Além disso, para indicar que os métodos para os Java beans fossem regenerados toda vez que a geração de código fosse executada, a linha /* AVISO: ESTE MÉTODO SERÁ REGENERADO. */ era incluída no comentário do método. O utilitário de migração tem uma opção que remove esses comentários gerados pelo VCE do código exportado (não do código fonte no VisualAge para Java), uma vez que eles não são mais aplicáveis fora do VCE. No entanto, depois dos comentários para os pontos de código do usuário serem removidos da origem, o código do usuário não poderá ser utilizando no VisualAge para Java. A razão é que a presença desses comentários é o que protege o código do usuário de ser sobrescrito.
O editor visual para Java não utiliza um modelo de objeto persistente para seus Java beans e seus valores de propriedade e relacionamentos mas, em vez disso, analisa sempre a origem. Por essa razão, os comentários para os pontos de código do usuário e para especificar a regeneração do método não se aplicam mais e as modificações podem ser feitas livremente no código fonte. Se as modificações alterarem a estrutura do código fonte de forma que o editor visual para Java não possa mais reconhecer a estrutura dos Java beans, você poderá não vê-los na visualização Design ou na visualização Java Beans. No entanto, a origem não será alterada para se ajustar ao estilo do editor e suas alterações serão preservadas.
Tópico pai: Editando Java no Editor Visual