Juergen Hoeller

Loom goes into preview as of JDK 19: https://twitter.com/OpenJDK/status/1519749893253861376

We are aware of our rather wide-spread dependencies across the traditional JDK-scoped libraries. Some of those are entirely optional (e.g. JNDI, JMX, RMI and JSR-223 Scripting are only used on...

Our JNDI support and therefore the `java.naming` module is being referenced in two common places, it seems: `CommonAnnotationBeanPostProcessor` and `StandardServletEnvironment`. The JNDI support itself is totally optional, we're only really...

Closing this one based on the assumption that #27375 covers all occurrences of this leak (as a regression in the 5.3.x line). Please give the 5.3.10 release a try, it's...

I would generally recommend an approach that does not require an individual runtime bean registration per endpoint, e.g. a central endpoint registry bean that accepts every such endpoint (as e.g....

Runtime registration and removal of bean definitions isn't going away but unfortunately it is just not ideal for AOT processing, by the very nature of the approach. From my perspective,...

With some custom treatment, we can restore the original intent of #27716 as well as preserve square brackets for index/key expressions. Finally making it into RC2...

After a lot of consideration, we have realized that this is a problem that is not practical to solve at the core framework level. Our generated configuration needs to have...

@mp911de any advice on this?

I've slightly repurposed this issue for revisiting our fallback parsing behavior there. Based on the scenario described above, we should indeed leniently accept the default `parse` format of every `java.time`...