Spring's Java Configuration can mean a few different things.

One is using @Autowired, @Component, and friends to build up your context. One could argue this violates IoC, although I disagree, but that's actually not the interesting meaning.

The interesting meaning is the use of @Configuration and @Bean to replace XML-driven config with Java-driven config. Basically you can replace a Spring XML file with a Java class that creates the same beans and assembles them in the same way, but in cases where you need to do something awkward to create a Bean instance that would be trivial in Java, you just do the trivial thing in Java.

So you haven't lost any of the abstractness provided by IoC. Bean classes don't change at all. It's simply how they're assembled that changes. Instead of writing a giant set of XML files to create a giant set of POJOs and wire them together, you write a similar set of Java classes and have one less language to deal with.

> Instead of writing a giant set of XML files to create a giant set of POJOs and wire them together, you write a similar set of Java classes

This is how you would do it without spring. I suppose there must be an advantage of using @Configuration and @Bean instead of plain java, but what is it?

They give you automatic proxied/intercepted objects for things like Transaction management, asynchronous execution, general AOP, etc. If you're not using any of that, there's probably little to no advantage to using pure Java DI. But those things are really nice to have.