ClassViewer | ClassViewer v3 is a lightweight Java class file viewer

First off, JD-GUI is not a very good decompiler. You'll almost certainly get better results using other decompilers.

That being said, it is important to learn how to understand bytecode if you want to become serious about Java reverse engineering.

There are actually two different bytecode "languages". The first is the Java classfile format, which is executed by the JVM. This is what you get when you run a Java desktop application or applet. You can find the specification here: http://docs.oracle.com/javase/specs/jvms/se8/html/index.html

However, Android does not use Java bytecode at all. Instead, it uses its own system, known as Dex bytecode, which is similar, but subtly different. You can find the specification for Dex bytecode here: https://source.android.com/devices/tech/dalvik/dalvik-bytecode

APKs consist of Dex bytecode. However, the listing you showed is Java bytecode. Presumably, you either ran it through Dex2Jar first to translate the Dex file into Java bytecode or you used a tool that did this for you. (You can also use Enjarify to do this, but the bytecode you posted doesn't look like the output of Enjarify).

At any rate, if you're trying to understand an obfuscated binary, you might as well go straight to the source and look at the Dex bytecode, rather than the output of an imperfect conversion tool. I'd recommend checking out smali/baksmali and apktool, which are the best tools I know of for working with dex files.

Update: Now that you've provided the apk, I decompiled it myself, and it really doesn't look like anything nefarious is going on. The code just happens to have a try/catch with multiple catch blocks, which confuses the decompilers you used.

Since there were multiple classes with a loginV2 method in your apk, I decided to focus on com/ipanel/join/homed/utils/APIManager.

Using Enjarify + Krakatau, I get the following decompiled code.