Of course the second is better because it's much easier to understand.

Still I'd like to argue pro the nested assignment for the hypothetical case that no better solution is available.
The nested assignment is a common solution pattern, a common idiom, for condition expressions that need an update before they can be evaluated when init and update code are identical or can be made identical. It's the same as:
while ((c = getchar()) != EOF)
for (int c; (c = getchar()) != EOF; )
for (int c; (c = in.read()) != -1; )
for (String line; (line = in.readLine()) != null; )
for (int xPos = -1; (xPos = givenLine.indexOf('*', xPos + 1)) > 0; )
Otherwise the update would need to be there twice, in the initializer and in the update:
for (c = getchar(); c != EOF; c = getchar())
for (int c = getchar(); c != EOF; c = getchar())
for (int c = in.read(); c != -1; c = in.read())
for (String line = in.readLine(); line != null; line = in.radLine())
for (int xPos = givenLine.indexOf('*'); xPos > 0; xPos = givenLine.indexOf('*', xPos + 1))

This idiom isn't new. The first incident that I know of is "The C Programming Language" from Brian Kernighan and Dennis Ritchie, and I bet there are more incidents that predate that book.

It might look "not nice" at first sight, it seems to be violating a rule. The rule is that expressions should not have side-effects. But actually there is no explicit rule that expressions should not have side-effects. That is only an implicit rule that is a specialization of another, explicit, more generic rule. That other explicit more generic rule is that there should not be surprises. And we consider nested assignments as surprise - in general. Because the idiom of a nested assignment in a loop condition is a well known pattern, there is no surprise, and thus the code is clean.

Here's a few quotes on it - I'm a fan of quotes, you know...
"You know you are reading clean code when each routine that you read is pretty much what you expected." - Ward Cunningham as quoted by Uncle Bob in Clean Code Episode 1.
"You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem." - Ward Cunningham as quoted by Uncle Bob in Clean Code (book).
"10. Rule of Least Surprise: In interface design, always do the least surprising thing." - Eric S. Raymond in The Art of UNIX Programming. I tend to see the Rule of Least Surprise more generic than Eric.