Port Java components

Embedded Java is where most of a Talend migration's hand work is. The importer translates what it recognises, keeps everything else, and flags every Java component in the report, so none is missed.

What the importer did

Talend	In Hop	What you do
tJavaRow	User Defined Java Class	Recognised idioms are translated; check them. Code it could not translate is listed per idiom in the report, with its line, and kept as a comment.
tJavaFlex main part	User Defined Java Class	As tJavaRow.
tJavaFlex start and end parts	Comment in the same class	They run once, not per row. Port them by hand.
tJava	User Defined Java Class	Code is translated where possible, otherwise commented out; always flagged.

For each flagged component

1. Find it in the report's Needs review table: the reason names the code that was not translated.
2. Open the User Defined Java Class in Hop GUI. The original code is in the class, as a comment where it was not translated.
3. Decide whether it needs Java at all. Much Talend Java code does what a Hop transform does: string handling (Calculator, String operations), date formatting (Select values), lookups (Stream lookup, Database lookup), counters (Add sequence). A transform is easier to maintain than a class.
4. If it does need code, port it into the class. Talend's globalMap and context become Hop variables (getVariable, setVariable); Talend routines have to be ported or replaced.
5. Re-run the comparison from Validate a migration for that job.

Code that runs once

tJava and the start and end parts of tJavaFlex usually set variables, open resources or log. In Hop those belong in the workflow around the pipeline: a JavaScript action, a Set variables action, or a Write to log action. Move them there rather than into a transform that runs per row.