Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

101–110 of 327 posts

Re: Rating 26 years of Java changes

#101
It's nice to review the features, but the history of Java isn't really about features or even programmer popularity.

(1) It was the first disruptive enterprise business model. They aimed to make everyone a Java programmer with free access (to reduce the cost of labor), but then charge for enterprise (and embedded and browser) VM's and containers. They did this to undercut the well-entrenched Microsoft and IBM. (IBM followed suit immediately by dumping their high-end IDE and supporting the free Eclipse. This destroyed competition from Borland and other IDE makers tying their own libraries and programming models.)

(2) As an interpreted language, Java became viable only with good JIT's. Borland's was the first (in JDK 1.1.7), but soon Urs Holzle, a UCSB professor, created the HotSpot compiler that has seeded generations of performance gains. The VM and JIT made it possible to navigate the many generations of hardware delivering and orders-of-magnitude improvements and putting software in every product. Decoupling hardware and software reduced the vertical integration that was killing customers (which also adversely affected Sun Microsystems).

btw, Urs Holzle went on to become Google employee #8 and was responsible for Google using massively parallel off-the-shelf hardware in its data centers. He made Google dreams possible.

Re: Rating 26 years of Java changes

#102
post #72

Earlier quoted context omitted.

To me var is what makes modern java somewhat readable and more bearable. It was always a joke that it takes too long to write anything in java because of the excessive syntax repetitions and formalities. To me that joke is heavily based on a reality that modern Java is tackling with this quality of life features.

I get the attraction to var, but I, personally, don't use it, as I feel it makes the code harder to read. Simply, I like (mind, I'm 25 year Java guy so this is all routine to me) to know the types of the variables, the types of what things are returning. var x = func(); doesn't tell me anything. And, yes, I appreciate all comments about verbosity and code clutter and FactoryProxyBuilderImpl, etc. But, for me, not hav…

1. Just because you can use var in a place, doesn't mean you should. Use it where the type would be obvious when reading code like

  var myPotato = new PotatoBuilder.build();
not like

  var myFood = buyFood();
where buyFood has Potato as return type.

2. Even if you don't follow 1, IDEs can show you the type like

  var Potato (in different font/color) myFood = buyFood();

Re: Rating 26 years of Java changes

#103
post #5

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…

The ratings are really all over the place. Jshell is a 6/10? What is the rubric?

Re: Rating 26 years of Java changes

#104
post #96
post #68

Earlier quoted context omitted.

Absolutely. It seems that the author never touched Spring, for instance, or a dependency-injection framework of any kind. Annotations allow to do things in a completely different way, removing tons of boilerplate. 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.)

and that's before even touching on the compilation steps they can add, which are a pluggable codegen and macro system that is also integrated into IDEs, which is completely missing from almost every other language.

Good stuff. If that excites you, check out Roslyn source generators too.

Re: Rating 26 years of Java changes

#105
post #7

I'm sorry, please don't hate me (I'm tired and don't have anything better to do) https://files.catbox.moe/ge4el3.png

Why so much hate for modules? They seem to be almost universally disliked by everyone on this thread and I don't understand why.

Modules are weird. In Java world there exists consensus on dependency management via Maven-style repositories (Maven Central is the primary distribution channel) and all tools support it. You handle your dependency tree outside of your code and just import packages from libraries available on classpath. It’s possible to continue doing that that without using modules, so the case for using them is still unclear to many people. Where the actual hate may have come from is an old story with migration from Java 8 to Java 9, where modules hidden the access to certain internal APIs, breaking some libraries which relied on them, making that migration painful. Today their value is probably 0/10, but there’s no reason to hate.

Re: Rating 26 years of Java changes

#107
post #5

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…

You're absolutely right about checked exceptions. However, I think they're an exception (forgive me) from the pattern of Java mostly sticking to the strategy of, we can build a practical, industrial, reasonably performant language that has all these nice bits from other languages: garbage collection, portable bytecode, no pointer arithmetic, collections in the standard library, etc.

I think streams are a great example of what I was saying about Java failing to take advantage of coming last. Scala (probably among others, but Scala was right there on the JVM) had already demonstrated that it was possible to enable simple, readable code for simple use cases, while also enabling complex and powerful usage. And the experience of Scala had shown that there's little demand for parallel collections outside of extremely niche use cases where people tend to use specialized solutions anyway. Somehow Java, with this example staring them in the face, managed to get the worst of both worlds.

Re: Rating 26 years of Java changes

#108
Joshua Bloch's work on Collections for Java2 was absolutely formative for me.

I was just starting real programming, I knew naming was hard so I was using thesaurus almost as extensively - if not more - than the reference manual.

But his work defined designing API for me for life. Stuff we take for granted, and we often overlook as seemingly trivial.

Let's say you have a collection type that has a method ``put``. It takes two arguments - an object you want to insert, and an index you want to put it at. Which argument should go first? Could index be optional? What value should it default to? Does the function returns anything? A boolean to indicate whether insertion was successful? Or the index at which the object was put? If latter how you indicate an error?

All of these seems seemingly trivial but he and his team worked on that library for over a year and he throughly documented their work in series of presentations.

And we can't forget about his java puzzlers, absolute gem.

Re: Rating 26 years of Java changes

#110

Earlier quoted context omitted.

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…

> For example they used checked exceptions. 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 'Eit…

I suppose you could actually solve it by having a promise that catches the exception like your suggesting with an either result. The C# Task API can do this. It has it's own headaches where now the developer has to pay attention to observing every exception.

Java could do something similar but they have enough promise types already.

Post reply on HN