spring-boot

Dotnet and java usually have similar libraries for most things, but sometimes it comes down to how different they are or what they support. Let's look at general distributed messaging abstractions. The most modern-featureful one for dotnet I know of is MassTransit: https://masstransit.io/documentation/concepts. You can see it supports a handful of queues and some interesting patterns. Compare this to the list of features in Apache Camel: https://camel.apache.org/components/4.4.x/eips/enterprise-in... Additionally, the _support_ of the libraries for common open-source (and closed-source infra) is usually vastly different: - https://pulsar.apache.org/client-feature-matrix/ - Small features being first party like https://github.com/awslabs/amazon-sqs-java-extended-client-l... vs https://github.com/raol/amazon-sqs-net-extended-client-lib - Mi

> The second point doesn't seem like a positive on the whole, except maybe for the company selling it, in the "there's good money to be made in being part of the problem" sense. No argument there (I don't miss those firm's doc standards). But you can make a lot of money being part of the problem in the business universe. > The comment gives the appearance of being helpful while actually just adding confusion and wasting everyone's time. That's definitely a concern; if the tool doesn't work it doesn't work, potential or no. I think the first comment (https://github.com/spring-projects/spring-boot/pull/39754/fi...) looks helpful, although it is repeating info you can find in the class docs, the fact you have to go to the class docs to find it is an issue. A tool that could on--the-fly generate "Give me context for this function" (and give t

I agree on that example. But contrast with this example: https://github.com/spring-projects/spring-boot/pull/39754/fi... A function named `apply` with no documentation; you have to go up to the class to find the docs. And yes, it's not DRY to repeat the docs, but the fact the tool can pull relevant context into this location is helpful if it could be used as an on-the-fly doc generator (assuming, of course, it gives true output). People (understandably) don't want to repeat themselves but they also can't predict what entrypoint a reader enters their class from. I've definitely bounced off APIs before because something like `apply` isn't doc'd even though it's doc'd in source twenty lines away (because I'm busy; I'm not scanning entire source files on the off chance that the thing I'm looking for is nearby).

Can someone familiar with the Spring Boot codebase confirm if these comments are useful or not? At a glance - and I'm not a java developer - a handful of the comments seem to add some specific context that's not obvious from the code alone: https://github.com/spring-projects/spring-boot/pull/39754/co...