Well first of all, do-not-wall-yourself-in. Stay away from red herrings. You tested it directly in the database and it worked - fine. That does not prove that there are no problems with the procedure, it only proves that there are no problems with the specific test case you run.
So now you add a different execution path where Java is involved and boom, things blow up. Your first natural response is to want the problem to be outside of the procedure; "Its a Java thing". Don't make that assumption. Its not like Java is executing the procedure, its still the database doing it. That very same database where it previously worked, the only thing that changed here is the way the procedure is triggered to be invoked. So the easiest answer is: there is something different in the way that procedure is invoked. I spot a ton of parameters, start by investigating that you're feeding the procedure properly.
I'm going to suggest this last so its only a footnote and not a poke at your intelligence: before you do anything be 100% positive your Java code is connecting to the database / schema you're expecting it to connect to. You wouldn't believe how many people fall into that easiest of deadly traps!
IF CTR!=0 THEN
P_OR_2:=SUBSTR(P_OR,1,CTR); --here is the line where the error is.
How do you know that line is where the error is? Why didn't you post the actual results and the exception trace?
You have SEVERAL flaws in your code.
You decrement CTR so it could be zero. Then the SUBSTR would return null. Then you would try to use TO_NUMBER on a NULL.
The standard way to troubleshoot PL/SQL code is to either use a debugger (e.g. sql developer) and examine the value of the variables involved or add instrumentation to print out the values so you can SEE what values the code is working with.