Almost every time the answer for me has been "it seems like they have, but they don't handle a critical edge case of some kind and cannot be extended to, and thus their solution is totally useless."
I have also found them responsive to feedback.
The idea that you would add a dependency to avoid writing a try-catch in a loop is absolutely bewildering to me. What next, Spring Pad? I can see it now:
@LeftPad(width = 50)
public String getNameForDisplay() {
return name;
}Reliable retry is very important in some cases, and it's easier to test a retry-agnostic unit of code.
Edit: and I also rather like that it's declarative, rather than needing to infer intention or write my own boilerplate to explicate intention.
Not as simple as you might think. And if you're gonna be writing microservices you're going to be intimately familiar with retries.
That doesn't make Oracle bad or Pivotal good.
Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...).
I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?"
Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe?
Or: I could use Spring-Retry[0].
That's just one example from my own experience.
It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1].
Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options.
Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense.
In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior.
I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry).
Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's.
In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal.
Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software.
[0] https://github.com/spring-projects/spring-retry
[1] You will often find companies accusing each other this.