Legacy Code – How to Introduce New Language Features?

do you also tend to select a preferred programming paradigm when coding and stick to it, or do you tend to explore more and mix different paradigms?

• Constantly exploring alternative solutions makes you a better programmer. You must be aware of available tools, it doesn't mean that you have to use them each time.

• Mixing paradigms is fine as long as it doesn't have a negative impact on quality of your code.

If you mix different paradigms, do you have the feeling that there is some overhead in terms of how fast you can write and debug code (added complexity, switching between different mindsets) or is it just a matter of learning how to do it and then you can even be more productive?

• If this is your project and nobody else will work on it, then it's absolutely fine. It might cost you later, but the good thing is that it won't affect anybody else.

• Generally, I think that teams will try not to use multi-paradigm as it is likely to have a negative impact on team's productivity. On other hand, experimenting, such as going from one paradigm to another is a great way to learn.

Or do you mix different paradigms in a more structured way, e.g. you apply each paradigm to a specific class of problems (e.g. functional for queries, object-oriented for architectural aspects, and so on)?

• No matter what you do, you need to plan for it and think what effect it might have in future. Therefore, yes, whatever you decide to do, it must be structured and planned for.

• My team has agreed on code guidelines and we have always been using these guidelines with very little if any paradigm-shifts. We also have tools that enforce these guidelines. In your specific example, ReSharper would suggest us to convert a foreach statement into a more readable LINQ statement.

To summarise, I think that exploring paradigm-shifts is a great way to learn, but it should be strictly controlled in a work environment.

Actually Java 8 doesn't introduce much that will be detrimental to other JVM languages that interop with Java. The work done on Lambdas helped fix a number of small issues around invokedynamic, MethodHandles , MethodReferences etc - but apart from that it's carry on as normal. That said, there's a whole new bunch of APIs that the other JVM languages could potentially call into now. Which ones they'll use by default or not is up to them.

The largest change impacting interop actually came in with Java 7 - with the invokedynamic bytecode that allows dynamic/late binding calls within the JVM - something that was initially designed for the other languages on the JVM. It's since been very usefully adapted for Lamdbas, so as of Java 8, Java will actually start emitting these bytecodes.

Some languages (JRuby for example) are already heavily using invokedynamic, whilst others (Scala, Groovy et al) are still investigating its use or are in the early stages of patching it in. In theory it makes their dynamic calls almost as performant as existing Java invokestatic calls, as opposed to the myriad of slower workarounds they were forced to use in the past.

Java 9 will bring more challenges for JVM languages with project Jigsaw coming into the platform which will be the beginning of the end for traditionally class loading and classpaths for the JVM. The JVM language folks are pretty aware of this and I expect some sensible collaboration to take place.