Not really. The Eclipse compiler and javac are different implementations with different objectives, and sometimes bugs cause them to differ in results, but I wouldn’t really expect it to be a problem for a non-junior developer. These should be extremely rare edge cases (but perhaps less rare if the same code has been copy/pasted across multiple locations).
As far as rework, the IDE is a tool and accurate most of the time, but I would expect an experienced developer to at least run a quick check with the real compiler before committing to the repository. The IDE gives good feedback while you type, but it’s not a replacement for running a quick check once a batch of work seems done.
In Java 8, you can’t auto-box and widen in the same assignment. So, Long l = 0; is not valid, but Long l = 0L; or long l = 0; are since each only does one or the other. The Eclipse compiler seems to be confused by the ternary and doesn’t quite pick up that the second part of the ternary isn’t the same type as the first part. I would expect a developer to notice that the types don’t seem quite right anyway, but even if they don’t, I’d expect the worst case would be they spend a couple extra minutes learning something about Java 8 vs. 7 and then it wouldn’t be an issue again.
This is a Gradle forum though, and from that perspective, the result from Gradle is the same result you’d get with another build tool or javac directly, so there’s not much else that can be done about the unrelated tool. However, I do recommend when you’re using a build tool like Gradle, the Jenkins server should NOT be the first time a Gradle task runs in your developers’ workflow.