5 ms·

I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... T

by y4mi 7y ago

I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... 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!"

provolone 7y ago
Just avoid bloated frameworks and your problem is solved.
- cryptos 7y ago
  This is not a balanced argument. Spring offers a lot of helpful things and can increase productivity. But it also has it's downsides like when something is not working because all the magic behind the scenes, making you more productive normally, just doesn't work in your case. 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.
  - provolone 7y ago
    That's fine. Use what works for you. There's more than one way to skin a cat. 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.
    - geodel 7y ago
      I do exactly same as you described. Use plain servlets with embedded tomcat in application. It all works very well for me. 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.
      - provolone 7y ago
        Feels like today there are some libraries that are only offered for Spring. Other than that I have been happy to do as you do with Jetty. I'll add that autoconfiguration is a symptom, not a solution.
- swsieber 7y ago
  Considered removing spring where I work to speed up startup times. Found the biggest bang for the buck was rewriting a bean factory to parallelize singleton preinstantion. 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)
twic 7y ago
I wonder if it's because there is such a sharp line between what a Java programmer can do in Java, and what the JVM does to make that possible. Much of what the JVM does is impossible to even describe in normal Java. That line doesn't exist in, say, C++, where the compiler is just another C++ program. With the caveat that there are JVMs written in Java, so that line can be crossed: https://www.jikesrvm.org/ https://www.jikesrvm.org/ 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.
- groestl 7y ago
  The JVM is not magic, neither are Java programmers magicians, but I think the reason magical terms are used to describe Java systems is that the ecosystem had lots and lots of time to develop libraries and abstractions (a few of which happen to be of the right kind, read: leak just the right amount). Your typical Java programmer is well aware what it takes to implement a battle-proof connection pool, and will not attempt to implement their own. To them, adding the config stanza to enable a connection pool indeed feels like magic. Other platforms, that come with preconfigured connection pools, do not leak this to the programmer, and 80% of their users will not know what a connection pool is.
  - james-mcelwain 7y ago
    The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms. 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.
    - groestl 7y ago
      > simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms. I think that's a good way to characterize it.
dtech 7y ago
It's because the Java ecosystem relies heavily on things automatically being done for you behind the scenes, like run-time reflection and classpath scanning.
AlEinstein 7y ago
Speaking as a dev who started with Java 1.2, I actually much prefer to write code that doesn’t rely on magic unseen effects. 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.
- raverbashing 7y ago
  Unless you're writing assembly or maybe C then "magic" is happening
  - saagarjha 7y ago
    Assembly and C have plenty of magic to go around, don't worry.
    - earenndil 7y ago
      C yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?
      - saagarjha 7y ago
        Yes, along with complications that arise as you interact with your OS and other programs.
      - kryptiskt 7y ago
        It's black magic that summons spectres.
      - EmpirePhoenix 7y ago
        Yeah, in the best case. In the worst case it is more like this: https://news.ycombinator.com/item?id=5261598 https://news.ycombinator.com/item?id=5261598 which is pretty magic.
      - 7y ago
rendaw 7y ago
I think that's the writer/Project Loom's technical lead's thing. I got into a discussion with him about how magical Quasar's docs make it seem here, but we didn't reach accord: https://www.reddit.com/r/java/comments/7ulmwn/coroutines_in_java/ 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).
mrighele 7y ago
It's magic because some frameworks that are used a lot offer quite a bit of functionality, terrible documentation and awful diagnostics, so when things go wrong your best recourse is randomly tweak snippets posted on stackoverflow by other hapless victims.
lmm 7y ago
> I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... 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.
noisy_boy 7y ago
Having used Spring Boot for a while, I made up an analogy: Spring boot is a like a room which has a 1000 switches and a staircase leading to the basement. Usually these switches are enough for most use people. However, if your use case isn't served by them, you can follow the stairs to a much bigger room. This room is called Spring MVC and it has 2 million switches which will let you do anything you please. Good luck.

by y4mi 7y ago

provolone 7y ago

Just avoid bloated frameworks and your problem is solved.

cryptos 7y ago
This is not a balanced argument. Spring offers a lot of helpful things and can increase productivity. But it also has it's downsides like when something is not working because all the magic behind the scenes, making you more productive normally, just doesn't work in your case. 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.
- provolone 7y ago
  That's fine. Use what works for you. There's more than one way to skin a cat. 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.
  - geodel 7y ago
    I do exactly same as you described. Use plain servlets with embedded tomcat in application. It all works very well for me. 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.
    - provolone 7y ago
      Feels like today there are some libraries that are only offered for Spring. Other than that I have been happy to do as you do with Jetty. I'll add that autoconfiguration is a symptom, not a solution.
swsieber 7y ago
Considered removing spring where I work to speed up startup times. Found the biggest bang for the buck was rewriting a bean factory to parallelize singleton preinstantion. 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)

twic 7y ago

I wonder if it's because there is such a sharp line between what a Java programmer can do in Java, and what the JVM does to make that possible. Much of what the JVM does is impossible to even describe in normal Java. That line doesn't exist in, say, C++, where the compiler is just another C++ program. With the caveat that there are JVMs written in Java, so that line can be crossed: https://www.jikesrvm.org/ https://www.jikesrvm.org/ 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.

groestl 7y ago
The JVM is not magic, neither are Java programmers magicians, but I think the reason magical terms are used to describe Java systems is that the ecosystem had lots and lots of time to develop libraries and abstractions (a few of which happen to be of the right kind, read: leak just the right amount). Your typical Java programmer is well aware what it takes to implement a battle-proof connection pool, and will not attempt to implement their own. To them, adding the config stanza to enable a connection pool indeed feels like magic. Other platforms, that come with preconfigured connection pools, do not leak this to the programmer, and 80% of their users will not know what a connection pool is.
- james-mcelwain 7y ago
  The way I would phrase it is that the Java ecosystem is simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms. 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.
  - groestl 7y ago
    > simultaneously both higher level and lower level (in terms of abstraction, not the machine) than many other platforms. I think that's a good way to characterize it.

dtech 7y ago

It's because the Java ecosystem relies heavily on things automatically being done for you behind the scenes, like run-time reflection and classpath scanning.

AlEinstein 7y ago

Speaking as a dev who started with Java 1.2, I actually much prefer to write code that doesn’t rely on magic unseen effects. 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.

raverbashing 7y ago
Unless you're writing assembly or maybe C then "magic" is happening
- saagarjha 7y ago
  Assembly and C have plenty of magic to go around, don't worry.
  - earenndil 7y ago
    C yes, assembly--where? Its mapping to machine code is relatively straightforward, and as is the mapping from machine code to ELF. Or do you mean all the magic the CPU does to make it go fast?
    - saagarjha 7y ago
      Yes, along with complications that arise as you interact with your OS and other programs.
    - kryptiskt 7y ago
      It's black magic that summons spectres.
    - EmpirePhoenix 7y ago
      Yeah, in the best case. In the worst case it is more like this: https://news.ycombinator.com/item?id=5261598 https://news.ycombinator.com/item?id=5261598 which is pretty magic.
    - 7y ago

rendaw 7y ago

I think that's the writer/Project Loom's technical lead's thing. I got into a discussion with him about how magical Quasar's docs make it seem here, but we didn't reach accord: https://www.reddit.com/r/java/comments/7ulmwn/coroutines_in_java/ 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).

mrighele 7y ago

It's magic because some frameworks that are used a lot offer quite a bit of functionality, terrible documentation and awful diagnostics, so when things go wrong your best recourse is randomly tweak snippets posted on stackoverflow by other hapless victims.

lmm 7y ago

> I find it amusing that whenever people talk about Java, they're somehow using magic to describe it. It's like Java programmers see themselves as magicians... 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.

noisy_boy 7y ago

Having used Spring Boot for a while, I made up an analogy: Spring boot is a like a room which has a 1000 switches and a staircase leading to the basement. Usually these switches are enough for most use people. However, if your use case isn't served by them, you can follow the stairs to a much bigger room. This room is called Spring MVC and it has 2 million switches which will let you do anything you please. Good luck.