Since jwvh already has a great solution to your problem, I'll point out a few things in your original code.
One thing that immediately caught my eye was the use of
Breaks.break(). This does not work the same as in Java. It throws a
BreakControl exception that can stop your program if not caught by the
breakable block encasing your while loop. Throwing and catching exceptions often can hurt performance, so I would strongly encourage you to stay away from
scala.util.control.Breaks. I believe you can eliminate the first break by making the condition of the inner while loop
j < k, but the second break would still remain.
Another thing is that you're using
Arrays to represent triplets and the resulting list of triplets. Perhaps using an array for holding three numbers may be okay in Java, but even there, using an array for a collection that must grow in size is a bad idea.
In Java, you may use a class that implements
List, such as an
ArrayList, but in Scala, I'd suggest using a
List, an immutable linked list for
resultsArrayOfTriplets. Appending to an array isn't a great idea, since it requires creating a new array and copying elements of the old array to that (an O(n) operation). Instead, you can prepend new triplets to the existing list of triplets (a constant time operation).
For the triplets themselves, I would suggest using a tuple
(Int, Int, Int) even though it's homogeneous and you can use an
Array. This is both because
Arrays are mutable, and you don't want to be able to modify the triplets later, and because an
Array could be of any size, whereas here, the size of a triplet is fixed.
A couple smaller things -
resultsArrayOfTriplets could be just
target could either be a parameter to allow the caller to generalize to triplets summing to any number or a "magic number."
However, making these changes would just be putting a bandaid on a much bigger problem. As jwvh pointed out, you're essentially writing C code in Scala.
vars (and mutability),
Arrays, while loops, and the like are not idiomatic in Scala.
To answer the question in the title, no, it appears your code would be O(n^2) in the worst case, since for every ith element of the array, the maximum number of times you would go through the array again is n-i.