A typical Java program is compiled several times. In the first step of Java, the source code is converted to Java byte code . In the second step, the Java byte code is converted to machine code .
The details of this process, of course, depend on the virtual machine that runs the code. Earlier versions of Java, for example, did not include the so-called "exactly at time" compiler. In this case, the bytecode was interpreted by the instruction according to the instruction, where manipulation of the bytecode could, of course, have an impact on performance. But this is no longer the case. Both the OpenJDK HotSpot virtual machine and the battery life of Android ART and DEX perform byte-code optimization.
The javac compiler, which translates source code into byte code, performs very few optimizations. Normally, you should not worry about the effect of performance on the step of translating code into bytes. However, in some cases, the bytecode generated by the generation of the runtime code can affect performance. This happens when the compiler "at the exact time" notices byte code that is difficult to optimize. This is usually caused by unnecessary selection of objects that are difficult to optimize.
If you want to see the details of this question, I gave this presentation, where I’ll talk a little about the problem: https://www.youtube.com/watch?v=XMY6HA7_h5Y
As for security: as long as manipulating byte code does not damage the byte code, there is no problem. If this causes damage to the byte code, the Java virtual machine will refuse to load the class with the damaged code. This is true for HotSpot and Android, which check any byte code prior to loading the class.