This is especially widespread with spring boot. I've even read sentences like "It's hard to say what it does, you can only see it's effects!"
With the caveat that there are JVMs written in Java, so that line can be crossed:
The same mechanism could apply at the Spring Boot boundary. Using Spring Boot (for simple applications) is easy enough. Implementing it takes code that is beyond bizarre.
The ability to swap out basically any component of a framework like Spring simply by including a different dependency or replacing a bean at runtime allows for fine grained tuning that isn't possible in many other frameworks.
But this flexibility and/or modularity is enabled by a heap of pretty magical abstractions that glues everything together.
This is the opposite emphasis to, say, the Ruby community, which values a simple, lickable, surface interface with a large amount of opaque magic hiding behind it.
I think that's a good way to characterize it.
You just need to master SFINAE, ADL, template metaprogrmming including tag dispatch, constexpr and eventually you will reach C++ Gandalf status.
https://www.reddit.com/r/java/comments/7ulmwn/coroutines_in_...
It's quite possible to make non-magical coroutines in Java. It's about how you document them (and perhaps how you try to hide implementation details).
The only exception to this is dependency injection via annotations but for god’s sake use it in moderation.
But then I still prefer to write for loops rather than streams because I know what the jit compiler is doing.
Dependency injection comes in two varieties: constructor injection and future pain injection.
Choose wisely.
Even the assembly language programmer is running on top of the OS. The OS is deep magic: runtime interrupts happening to make the floating point hardware handle certain edge cases correctly. Fork system calls that semantically provide a copy of the parent’s address space in almost no time by using virtual memory tricks (copy on write pages). Virtual memory itself.
The OS lets the user space assembly language programmer touch some of the hardware directly, but not all of it.
[1] https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down
Yes, plenty of magic.
And then I look at biological systems, not even the brain yet, just biochemical pathways. Also lots of structure, mixed in with lots of... mixing, and lots of molecules mix and sometimes match. The whole thing is much slower than man-made electronics - but many orders of magnitude more parallel. And probabilistic. And I wonder how to go from programming the man-made stuff to describing those machines in a similar way. Right now we are only tinkering at the far edges of it. Whenever somebody posts about a revolutionary new programming languages I think to myself, you are still just working with the exact same machine. It's like when you zoom in to a flat surface, that under a microscope looks ragged. The only reason we see a huge difference between various programming languages is because we are waaayyyyy zoomed into one paradigm.
In a biological system the elements doing the work are many different molecules with distinct shapes. In CPUs there only are shapeless electrons, so unlike the molecules which meet and match all the time based on probabilities the electrons don't actively contribute to the computing themselves. Also, the molecules are almost all active, all the time, in computers our "code" lies dormant and waiting in pools (memory) doing nothing most of the time. In comparison, only an incredibly tiny fraction of our human-made computing elements are actually doing something at any point!
In nature/biology shape and structure on the nano level are the major design factor. Shapes of molecules and shapes of the structures used to separate or guide or hold them. Most of the process is determined by those shapes. In human-made computing we are extremely limited in what shapes we use under the hood. We use higher frequencies and limiting ourselves to few goals, otherwise nature would outcompute us by many orders of magnitude (and that's only true because we decide to ignore most of the computation going on in biological systems as not relevant "it's just random noise with no purpose"). I see a disconnect between how we program and what is going on. We think it's a vital "abstraction". I think that abstraction is a blessing, sure, but also a great hindrance. In the end those shapes and structures matter a lot. If somehow we could get a translation into more and more flexible (nano) shapes/structures than now, where we have a 100% fixed structure and only electrons (so, no shapes)... even biological systems are actually quite limited in what kinds of shapes they use, there was a path-dependency on which random path evolution took. I think it would be possible to far exceed biological systems, but we would have to get down to the shapes (molecules and nano-structures). That is far away from now, where it takes us years to come up with one fixed structure and shapeless moving point-forms inside of it.
This room is called Spring MVC and it has 2 million switches which will let you do anything you please. Good luck.
It's just the opposite, Java programmers are doing something much more limited. Java has a deliberately simplified language design, but the result is that most serious Java systems have to use one or more frameworks that step outside of what's possible in Java proper (by using reflection, proxies, bytecode manipulation, JVM agents or other such shenanigans) to meet their requirements. And such frameworks are necessarily "magic" from the perspective of someone thinking in Java proper.
If I look at Go code, for example, I can hardly bear all the tedious repetition and dumb code! There is hardly any magic in Go, but the downside is, that you have to write every `filter`, `map` and `reduce` by hand.
It isn't particularly balanced to assume that the spring way is the only way to do things because magicians...
If the OP has that problem with spring then he can use the base servlet API or another solution.
But now I have to support multiple Spring boot projects. I can't help noticing one thing common in these projects that it is about 10% functionality and 90% of Spring turd nuggets strewn all over project repos.
I'll add that autoconfiguration is a symptom, not a solution.
That's what I thought the optimal route was. That's how much we benefit from the strong spring ecosystem.
(It was a little less of a pain than you might think because I didn't have to support all spring features, just the ones we use, which happen to mostly not be features used during singletons preinstantion)