This is redundant since basic constructor will be invoked automatically.

Similar exception handling is performed on the same level for VstCommunication.
This handling is taken from HttpProtocol that doesn't take care of it now.

It's bad practise to use final everywhere.
Having it for classes, methods and fields is good but not for variables and parameters.
We can pass parameters only by value in Java, so there is no way to modify the value of the parameter anyway.
Having final for variable and parameter reduces number of optimizations that JIT performs. So we loose in performance in the end.

That is shortly why it's bad practise. I fixed it only in affected lines and kept others as is.

Why is it bad practice to use final in method parameters ? Only reason I can think of is code clutter but if you keep the number of parameters low then it shouldn't be a big problem.

Java is pass by value yes so you don't modify the value of the outside variable but if you don't put final in method parameter you can modify the value of the copy inside the method as it is simply a method variable. In some cases declaring method parameters as final can prevent some bugs when you mistakenly use the method parameter for assignment instead of a newly declared variable. Also if you use the method parameter inside an anonymous local class then you must declare it final.

Having final parameters should lead to more optimizations on JIT because you don't have to synchronize on them or you can have them cached in the CPU registers. So final should increase the performance instead.

Hi @ataugur
I wrote why on a high level. It's enough to dive deeper if you'd like.
This is Java, not C++.

Further reading:

• Coding guidelines used in OpenJDK development http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html Search for "Method parameters and local variables should not be declared final"
• This book will help you to understand how JIT works https://www.amazon.com/Java-Performance-Definitive-Guide-Getting-ebook/dp/B00JLTOZVQ
• Other books on Java internals from Oracle/Sun.

Yes I agree with you on a high level. I don't put final in front of method parameters very often either. Yet we should also give the reasoning while giving the rule.

Like for example we should give the rule as:

• parameters and local variables should not be declared final unless it improves readability or documents an actual design decision.
• I am not an expert in byte code and JIT but I think I know a bit about them. I commented on general compiler writing perspective and caching behavior.

Thanks for the reply.

Hi @ataugur
I'm not the person who decides which rules should be used in this project :-)

I would suggest to look at a situation as is, without searching for a hidden sense.
This project is obviously written by C++ developer, not Java developer. You can see "destructors" used, "const" everywhere - these are signs of C++ guy, because these points are good for C++ and bad for Java (and any other non C++ language).

Having final parameters should lead to more optimizations on JIT because you don't have to synchronize on them or you can have them cached in the CPU registers

Do you remember happens before relation from Java memory model? It relates to optimisations that can be made with our code.
Since you mentioned it, having synchronize block limits the number of optimisations performed similar to having final used.
This is just an example from perspective of memory model, there are other cases.

Java is completely different from C++ and has only similar syntax (I worked with both heavily and know what I'm writing about). If we start using C++ practises in Java, we will have many problems and it will take lots of time to discuss each of them. So it's easier just to use Java paradigm.

Do you have merge permissions for this PR?
I'm afraid I will lose a focus some day and won't be able to help with this PR in some time, if it's not merged in a nearest future.