I often need to execute multiple sub-jobs conditionally (e.g. based on context variables enabling/disabling specific features in a job) and to date have simply used an empty tJava component, as this achieves what I need, has no side effects and I'd expect it to be the most lightweight option. For example:
Whilst each tJava component only generates around 100 lines/2.8K of code, I wondered whether there was a more appropriate component to use as a dummy, or even a better approach that I've missed?
I appreciate that I could use a single (tJava) component with multiple Run Ifs, or even have these all coming from the previous component which will have executed, but having one per conditional sub-job is much easier to lay out and therefore read, especially as the sub-jobs can be quite big, and the run order is immediately apparent.
You don't really have a much more efficient way of doing this apart from using one tJava. If you set your connections to be straight lines (Preferences ---> Talend-->Appearance --> Designer) you can make use of only 1 tJava with your connections spaced out. As seen below...
Click on the tJava and select one of the squares surrounding it indicating it has been selected. Then just drag it to the size you want it.
It has to be said that the extra lines of code won't really harm your performance and should really be considered part of the requirement for your conditional logic.
Thanks @rhall_2_0. Good to know that I've probably not missed anything too obvious.
The example I pasted in is much simpler than any real world cases I'm likely to have, and whilst resizing a single tJava component (something I hadn't considered doing) would be a nice middle ground, the conditional sub-jobs could each fill the entire design area (although if they get too big, I split them out into separate jobs) and in such cases I feel the separate tJava components will be more readable. That said, maybe I'll give your approach a go and see how I feel about it each time I load the job up.
Yeah, appreciate that when it comes to the code generated by Talend, 100 lines is about as small as it gets per component, and it'll make little difference to performance, but I guess I was hoping there'd be a "dummy" component with a non-obvious name, buried somewhere in the palette.
It sounds like your job is maybe a bit crammed with components which will only be used depending on conditional logic. Have you considered using child jobs? If so, have you considered dynamic child jobs? This functionality is available in the tRunJob. Take a look here (https://help.talend.com/reader/WWQ40R_iTE5~~9VkUQrjgQ/ICv6hRE2pgpUtQFvQDmxkg) and look for the word "dynamic". What you can do is conditionally set the name of the job you want to run in a tJava (for example) and have it linked to 1 tRunJob. Therefore you can handle all of your scenarios with a much simpler look.
In most cases, as with the job I'm just starting from which the quick example was taken, these sub-jobs would normally all be enabled, but occasionally I need to be able to selectively disable some functionality, usually to deal with situations/issues that arise in testing/production environments, or to carry out testing myself. If it were just the latter, in my dev environment, then I'd simply disable the relevant sub-jobs in the editor.
I often need to be able to enable/disable things once the jobs have been deployed, usually on Linux servers without a GUI or certainly without Talend installed, and I've found the best way to do this is via context variables that can easily be changed as required post-deployment.
You can do all this using dynamic jobs. My current implementation makes use of dynamic jobs to run whole processes made up of multiple jobs, running in an order that is calculated at runtime. I have complete control over what runs and in what order, at runtime by using a simple database table that is read into the job. Doing this, I can get my data processed by 5 jobs (A,B,C,D,E) in whatever order I like, leaving out whichever jobs I do not want to run for whatever reason. Not too different from using Context variables, but far more dynamic and far easier to add new functionality.
I do already use tRunJob, although to date have never had a need to implemented the level of dynamic flow you're describing, and for basic feature/debug switches like this in what are otherwise pretty static jobs with fixed execution order, I just find boolean context variables simple and very easy for anyone who may pick up the jobs in future to understand and work with.
Certainly appreciate the suggestion and ideas though.