181–190 of 327 posts
Earlier quoted context omitted.
It‘s a harmful code smell: It often obfuscates the type, forcing you to actively check for the type and should not be used.
Your IDE can do that?
Earlier quoted context omitted.
> env specific properties And then if you want to change a value at runtime you have to restart the executable?
Most web application servers work this way. It also works really well in practice using modern CD tools - update your configuration and perform a gradual rollout of all your application servers to reflect the updated configuration.
Earlier quoted context omitted.
You’ll find differing opinions. As someone who has worked on code bases that did not have spring that really should have and had to do everything manually: when used well it’s fantastic. Now people can certainly go majorly overboard and do the super enterprise-y AbstractBoxedSomethingFactoryFacadeManagerImpl junk. And that is horrible. But simple dependency injection is a godsend. Ease of coding my just adding an ann…
Actually I really dont like DI and its a core of my dislike. I can easily create objects directly and pass in dependencies, its a lot easier to debug and see what is going on as opposed to Spring magic.
Earlier quoted context omitted.
Exactly this, it’s great fun to have a surface level understanding of a topic and post derisively for internet points; rather then spend the time and effort to actually learn about the subject at hand!
I'm not digging for "internet points". Yes, superficial replacement values can be retrieved from the environment. But I guess we have to give you a more imagined or sophisticated example then to make the point to you? How about varying implementations of a service interface. Let's say I have a Scheduler interface and I want to have multiple implementations; maybe one is CronScheduler, another is RandomScheduler, anot…
all of your scenarios are trivial to implement with annotations
Earlier quoted context omitted.
Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa? Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when do…
> If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? The same way you pass a 64-bit integer to a function that expects a 32-bit integer: a conversion function that raises an error if it's out of range.
When trying to adapt a long to an int, the usual pattern is to overload the necessary methods to work with longs. Following the same pattern for uint/int conversions, the safe option is to work with longs, since it eliminates the possibility of having any conversion errors.
Now if we're taking about signed and unsigned 64-bit values, there's no 128-bit value to upgrade to. Personally, I've never had this issue considering that 63 bits of integer precision is massive. Unsigned longs don't seem that critical.
Earlier quoted context omitted.
You’ll find differing opinions. As someone who has worked on code bases that did not have spring that really should have and had to do everything manually: when used well it’s fantastic. Now people can certainly go majorly overboard and do the super enterprise-y AbstractBoxedSomethingFactoryFacadeManagerImpl junk. And that is horrible. But simple dependency injection is a godsend. Ease of coding my just adding an ann…
Actually I really dont like DI and its a core of my dislike. I can easily create objects directly and pass in dependencies, its a lot easier to debug and see what is going on as opposed to Spring magic.
Passing things down layer after layer gets old. High level stuff takes tons of parameters due to all the layers below.
You end up with God objects that mostly just contain every other object someone might want to reference.
And you know what? That object starts to feel like a great place to put state. Cause it’s already being passed everywhere.
So instead of using Spring to get a ThingService to work with your Thing at the spot you need it, suddenly all the code has access to all the stuff and states. And like the temptation of The One Ring programmers use it.
Now you have a spaghetti rats nest. Where is the code that deals with the state for a Gloop? It’s now everywhere. Intertwined with the code for a Thing. And a Zoob. It doesn’t need to be. But it is.
It becomes almost impossible to unit test things. Because everything can do/see everything. Untangling and extracting or replacing any part of the whole is a Herculean job.
You don’t need Spring for something tiny. And maybe it’s possible to go without dependency injection in a large app and keep things manageable and easy to understand.
In my career I’ve mostly seen the mess. I’ve helped try to untangle it by slowly introducing Spring.
I’d rather have it, with its organization and standard patterns, than the Wild West of whatever any programmer or junior decided to do over the last 15 years and how that has evolved. In a complex application with lots of programmers coming and going I find it a net benefit.
Earlier quoted context omitted.
It’s rare I have to do bit math but it’s so INCREDIBLY frustrating because you have to do everything while the values are signed. It is amazing they haven’t made a special type for that. I get they don’t want to make unsigned primitives, though I disagree, but at least makes something that makes this stuff possible without causing headaches.
Sometimes I'd like to have unsigned types too, but supporting it would actually make things more complicated overall. The main problem is the interaction between signed and unsigned types. If you call a method which returns an unsigned int, how do you safely pass it to a method which accepts a signed int? Or vice versa? Having more type conversion headaches is a worse problem than having to use `& 0xff` masks when do…
I think the only answer would be you can’t interact directly with signed stuff. “new uint(42)” or “ulong.valueOf(795364)” or “myUValue.tryToInt()” or something.
Of course if you’re gonna have that much friction it becomes questionable how useful the whole thing is.
It’s just my personal pain point. Like I said I haven’t had to do it much but when I have it’s about the most frustrating thing I’ve ever done in Java.
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty. I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Do…
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty. I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Do…
As mentioned in TFA, "The general advice seems to be that modules are (should be) an internal detail of the JRE and best ignored in application code"
So yeah, why expose it to those who are not the "main customer"?