No, it’s a required part of the construct and cannot simply be omitted.

But, you have a few options.

Futureland: _

Java is moving towards treating _ as the official “this one does not matter” name. For quite a few JDK releases, _ as identifier (because, per the Java 1.0 spec, _ is a name, same as ‘$’, or ‘varName’) gets you a warning, recently even an error. It’s being transitioned by the OpenJDK team to wean all existing code off of using it, so that it can then be reused for something else. And the intended ‘something else’ is: No-name unaccessible param.

The idea is that eventually you can do something like this:

BiFunction<String, Integer, Integer> always0 = (_, _) -> 0;

Right now that’s not legal (_ cannot be used; even if it could, you can’t have the same name for both parameters.

Presumably once this feature is fully introduced into java (which isn’t yet today; java is still moving towards this) eventually the principle is extended everywhere. Including there. So, presumably, you can eventually write:

for (Object _ : List.of(1,2,3)) {
  System.out.print("p");
}

and you, the compiler, any linting tools, and any other human looking at it knows that the author of that code block fully intended to never use the actual parameter.

If you want to use this, JDK456 says you can do that starting with JDK23 which is hot off the presses!

Before JDK23, you can’t do this, though.

for (int i = 0; i < size; i++)

The for (Object elem : list) style of for loop is fundamentally defined as ‘do something with each element in a collection’ and the code you wrote isn’t really doing that. This is starting to turn into philosophy, but, I’d say its better described as ‘do this thing as many times as this collection has elements in it’. For example, there is no actual need to retrieve each element separately from the collection. Imagine that doing so is expensive for some reason (could be, after all – Collection is an interface and the spec does not demand that advancing through it via an iterator is fast!) – but asking for the size isn’t. Trivially the case if, say, the collection is simply a light abstraction over DB access, and iterating through requires actually fetching and marshalling each and every row, whereas ‘do something as many times as there are rows in this table’ simply requires a single SELECT COUNT(*) query. Even with Object _, the language as designed isn’t going to allow the collection interface to know that it doesn’t actually have to fetch the data. You’re paying the considerable cost of having the db and JDBC driver system fetch all that data from the database’s stores, relay it to your JVM, package it up and marshal it into objects, only for you to then toss that object into the bin immediately. That’s a waste.

So, with that in mind, I’d just write it like this:

var list = List.of(1, 2, 3);
for (int i = 0; i < list.size(); i++) {
  System.out.print("p");
}

The major downside is that this basic for syntax is a bit confusing, perhaps. But that’s not a good argument: “I am a java programmer” implies the above code instantly registers in your brain as ‘right, do this thing X times where X is.. list.size’.

This is a conceptual thing in language of any stripe, even human languages. In english, there’s the phrasing ‘Be that as it may’. In dutch, we have a similar thing and it’s even written smushed together: desalniettemin which is literally the phrasing ‘des al niet te min’, where ‘des’ is an archaic form that hasn’t been used for decades, and the rest means something like ‘nevertheless, it is still the case that’. The point is, this breakdown of exactly what that says by analysing it word for word is not something any listener or reader ever does. They see ‘desalniettemin’ and know what it means, instantly. Nobody’s brain goes through the motions of analysing it one word at a time. Same in english: You read ‘be that as it may’ and your brain just treats that as a single atomic unit.

In other words, taking something that is generally interpreted as a single unit, breaking it down into parts, and going: Whoa, waaaay too complicated we must simplify! – is not a good idea. The fact that it is near universally treated as an atom means that is an unfair conclusion.

So, keep in mind that the java community is inherently aware of certain patterns and has absolutely no problem reading them very very quickly. for (int i = 0; i < size; i++) is one such pattern. Everybody will instantly know it what that means, and it means exactly what you want: Do a a pre-defined amount of times.

In Java, the enhanced for loop requires the iteration variable (such as the FormalParameter) to be defined. If you don’t need the variable but still want to iterate over the elements, you’re faced with either using it (which doesn’t suit your case) or suppressing the warning (as you’ve done), which feels inelegant.

Unfortunately, there’s no direct way in Java to omit the formal parameter in the enhanced for loop, as it’s part of the loop’s syntax. However, you can make the code clearer by using an alternative approach such as an indexed loop or functional constructs like forEach, which avoid having to declare a variable that you don’t use. For instance:

Using forEach with a lambda

List.of("1", "2", "3").forEach(item -> System.out.print("p"));

This approach doesn’t declare any unused variables, and the lambda function omits the need for any warnings or suppressions. It’s also quite readable and avoids clutter.

Extract the logic into a separate method

If the complexity of nested loops is the main concern, you can refactor the logic into a separate method to handle the iterations more cleanly:

List<String> list = List.of("1", "2", "3");
repeatPrint(list.size(), "p");

private void repeatPrint(int times, String message) {
    for (int i = 0; i < times; i++) {
        System.out.print(message);
    }
}