Solving the Fibonacci series using a for loop I have developed what I believe to be a novel way of coding the Fibonacci series in Java using a for loop. This code appears to work, but I was wondering if this is a good solution and how it could be improved.
 static int loopFibonacci(int num) {
        if(num &lt;1) {
            throw new IllegalArgumentException(&quot;this number is not valid for fibonacci series&quot;);
        }
        int sum = 1;
        int prev = 0;
        for (int i=1;i&lt;num;i++) {
            sum+=prev;
            prev = sum-prev;
//            System.out.println(&quot;sum=&quot;+sum+&quot; , prev = &quot;+prev);
        }
        return sum;
    }
}
...what I believe to be a novel way of coding the Fibonacci series...

Ahrm, no. Has been done like that forever.

static int loopFibonacci(int num) {

Do not shorten variables just because you can, it makes the code harder to read and harder to maintain.
Everything without visibility modifiers is by default package-private. In my opinion package-private should be avoided as it leads very easily to hard to maintain coupling of classes and interfaces, and it is very easy to make non-extendable constructs with it.

throw new IllegalArgumentException(&quot;this number is not valid for fibonacci series&quot;);

Good example of a bad error message. The error message should tell me why the number is not usable, what the not usable number was and what a usable number would be, for example:
throw new IllegalArgumentException(&quot;Input argument must be a positive number greater or equal to 1, given &lt;&quot; + Integer.toString(number) + &quot;&gt;.&quot;);


for (int i=1;i&lt;num;i++) {

I'm still a very persistent advocate of the rule to only use single-letter variable names when dealing with dimensions. For &quot;simple&quot; for loops using index or counter improve most of the time readability quite a bit.

sum+=prev;

As a note, a += b is not shorthand for a = a + b but for a = (TYPE_A)(a + b), which means that it might silently truncate data, for example when adding a float to an int.

        int sum = 1;
        int prev = 0;
        for (int i=1;i&lt;num;i++) {
            sum+=prev;
            prev = sum-prev;
//            System.out.println(&quot;sum=&quot;+sum+&quot; , prev = &quot;+prev);
        }

Your logic is rather hard to follow, that is because before you really read it it seems to be doing something completely different. So what you want to do is clear that up, partly by using better names and partly by making the logic easier to follow:
int current = 1;
int previous = 0;

for (int counter = 0; counter &lt; steps; counter++) {
    System.out.print(current);
    System.out.println(&quot; &quot;);
    
    int next = current + previous;
    
    previous = current;
    current = next;
}

That makes it rather clear how the logic operates.

Looking at possible performance implications is complicated, in my opinion, but let us look at the generated bytecode before jumping to conclusions:
This is the bytecode created for original solution:
0: iconst_1       
1: istore_1        /* sum */
2: iconst_0       
3: istore_2        /* prev */
4: iconst_1       
5: istore_3        /* i */
6: goto            20
9: iload_1         /* sum */
10: iload_2         /* prev */
11: iadd           
12: istore_1        /* sum */
13: iload_1         /* sum */
14: iload_2         /* prev */
15: isub           
16: istore_2        /* prev */
17: iinc            i, 1
20: iload_3         /* i */
21: iload_0         /* num */
22: if_icmplt       9
25: iload_1         /* sum */
26: ireturn

And here is the bytecode for my revised solution:
0: iconst_1       
1: istore_1        /* current */
2: iconst_0       
3: istore_2        /* previous */
4: iconst_0       
5: istore_3        /* counter */
6: goto            22
9: iload_1         /* current */
10: iload_2         /* previous */
11: iadd           
12: istore          next
14: iload_1         /* current */
15: istore_2        /* previous */
16: iload           next
18: istore_1        /* current */
19: iinc            counter, 1
22: iload_3         /* counter */
23: iload_0         /* steps */
24: if_icmplt       9
27: iload_1         /* current */
28: ireturn

So both solutions are using 22 instructions to accomplish their goals. After removing any noise, the difference boils down to this (original to the left):
13: iload_1         /* sum */        14: iload_1         /* current */
14: iload_2         /* prev */       15: istore_2        /* previous */
15: isub                             16: iload           next
16: istore_2        /* prev */       18: istore_1        /* current */

So the only difference is one sub operation, which we trade for a store operation. The performance difference here will be miniscule, in my opinion.