The example from @Mahesh_K_Sreenivas is perfectly reasonable, IMO. The comparison is helpful for learning. Certainly other algorithms would be useful as examples too, but this one seems okay to me.
Reasonable advice.
It is often the case that the argument for using Java is “when things get complex.” with the view that “FLOW is for simple things.” I usually disagree, to at least some degree. You still have to analyze and design appropriate components.
When writing FLOW, one must apply structured programming principles. One concept that often gets overlooked is simple modularity (subroutines). FLOW developers too often throw everything into a single FLOW service. It’s like coding everything in main(). Not good. There can also be a tendency to not define inputs/outputs. Also a tendency for “pipeline litter” and an (ill-advised) desire to use clearPipeline. FLOW provides lots of opportunity to shoot yourself in the foot. 
My guidance, FWIW: use Java for small, focused utilities. IME, creating a library/JAR is a rare need (I can think of only 1 time where we did that; using 3rd-party libraries and hooking them into IS via Java services is also relatively rare but a bit more frequent).
Another tidbit for consideration: if you’re Java developer, resist the urge to “go with what is familiar” and really strive to learn/understand FLOW. Most of the criticisms about FLOW are from C/C++/C#/Java developers who expect/want FLOW to have all the same behaviors/features of these languages. It doesn’t but it has enough, along with the built-in services and adapters, to do significant, “integration-y” things. 
#Command-Central#webMethods-General#webMethods#Integration-Server-and-ESB