The other answers are all correct, but they take your design problem as a given. And simply spoken: I think that is wrong.
The point is: as soon as you start naming variables like L1, L2, L3, ... you are doing something very wrong. Especially when your next idea is to write specific code that deals with L1, and code that deals with L2; and so on. Maybe the other answers help you to fix this portion of your code. But sooner or later, you will have numerous pieces of deficient code; all dealing with those Lx guys in their own ways. Or maybe not even those labels, in this program. but some other piece of code where you start of with the same mistake of organizing your (UI) elements in an inefficient way.
The real solution here: you should use some sort of collection mechanism; either a List; or maybe a plain old array. Because then you can iterate that collection and have exactly one line of code to setup all elements in that collection the same way.
Or the other way round: you query the panel that holds all the label for its elements; and if an element matches a certain condition, then you update its properties as you need to. If you follow that path, you might not even have to keep any references to your elements in your "own code"; you simply use means that already exist; and could be as simply as this.
What I am saying: all nice ideas in those other solutions, but I think they go into the wrong direction. They try to use nice ideas to fix a broken apprach. To follow a mem that is pretty famous nowadays: consider such UI elements to be cattle, not pets. Meaning: they are mere "numbers" to you that you organize so that they can be accessed as a whole in an efficient (versus a pet that is seen as individual, having a name, and being addressed as "single entity" most of the time).
But just to add my short version; a slight variation of Peter's solution:
for (JLabel l : Arrays.asList( L1, L2, L3, L4, L5, L6, L7, L8 ))
would work, too.