61–70 of 327 posts
Earlier quoted context omitted.
That doesn't sound very pleasant.
Either the same of this feature or always hiding the boxing (e.g. a Python int is actually a wrapper object as well, with some optimizations for some cases like interning) is the case in almost all languages.
Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
I don't really feel that Java uses proven features. For example they used checked exceptions. Those definitely do not seem like proven feature. C++ has unchecked exceptions. Almost every other popular language has unchecked exceptions. Java went with checked exceptions and nowadays they are almost universally ignored by developers. I'd say that's a total failure. Streams another good example. Making functional API fo…
Those are from java 1.0 and thus don't appear to be relevant to the part of the discussion I think this part of the thread is about (namely: "Why doesn't java crib well designed features from other languages?").
> Java went with checked exceptions and nowadays they are almost universally ignored by developers.
They aren't.
Note that other languages invented for example 'Either' which is a different take on the same principle, namely: Explicit mention of all somewhat expectable alternative exit conditions + enforcing callers to deal with them, though also offering a relatively easy way to just throw that responsibility up the call chain.
The general tenet (lets lift plausible alternate exit conditions into the type system) is being done left and right.
Earlier quoted context omitted.
Or Scala. Or Kotlin. Or any of the other languages that had most of these features years if not decades before Java. ;)
Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful. It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in…
Autoboxing's evil twin, auto-unboxing should knock the score down a few points. Integer a = null; int b = 42; if (a == b) {} // throws NullPointerException
I feel this is overly harsh on Collections. You have to take into account just how awful that which it replaced was. > Java Time: Much better than what came before, but I have barely had to use much of this API at all, so I’m not in a position to really judge how good this is. Again, it is hard to overstate just _how_ bad the previous version is. Though honestly I still just use joda time.
The original Java Time classes were likely a last-minute addition to Java. They were obviously a direct copy of C language time.h. It feels as if the Java team had a conversation like this: "Darn, we ship Java 1.0 in a month but we forgot to include any time functions!" "Oh no! We must do something!" "I know, let's just port C time.h!"
Autoboxing's evil twin, auto-unboxing should knock the score down a few points. Integer a = null; int b = 42; if (a == b) {} // throws NullPointerException
Short w = 42;
Short x = 42;
out.println(w == x); // true
Short y = 1042;
Short z = 1042;
out.println(y == z); // false(Today, even though I still C++, C, along with Java, I'll challenge anyone who claims that Java is slower then C++.)
Definitely underrates the impact of annotations. I'm personally not a fan of the way annotations are used to implicitly wire together applications, but I have to admit the impact. Maybe 5/10 is fair in light of the wide range of positive and extremely negative ways annotations can be used. So many of these features were adopted after they were proven in other languages. You would expect that since Java took such a sl…
I'd give annotations 9/10 at least.
(And I lost the interest in the rest of the article, given such a level of familiarity with the subject matter.)
> if you wanted to store an integer in a collection, you had to manually convert to and from the primitive int type and the Integer “boxed” class I have never worked with Java. What is this? Why would one want to have a class for an Integer?
Primitive variables in Java, such as `int`, `boolean`, and `double`, store their actual values directly in memory. When they are local variables inside a method, this memory is typically allocated on the thread's stack. These primitives do not have the structure or overhead of an object, including the object header used by the Garbage Collector (GC) to manage heap-allocated objects. If a primitive value must be treat…
Earlier quoted context omitted.
this is exactly why spring succeeded. I need to run a scheduled job, @EnableScheduling then @Scheduled(cron = “xxxxxx”) - done. I need XYZ, @EnableXYZ the @XYZ… sh*t just works…
Then you need to deploy it on multiple nodes and neex to make sure it only runs once for each run of the cron, etc.