Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

Post reply on HN
Print view View original

291–300 of 327 posts

Re: Rating 26 years of Java changes

#291

Post by peterashford »

rectang wrote: post #260
samus wrote: post #197

Earlier quoted context omitted.

> * "Invisible control flow", where you can't tell from the call site whether or not a call might throw (you need to check the signature, which is off in some other file, or perhaps visible in an IDE if you hover). Never found this this to be a problem. It is really common to all implementations of exceptions, not just checked ones. And when you write code the compiler will yell at you. In monadic code,

Invisible control flow is common to all implementations of unchecked exceptions (Java, C#, C++, Python, Ruby, etc). It means that any code, anywhere, at any time, can throw an exception which may represent a recoverable error. People are used to that, and one common strategy is to not worry too much about handling individual exceptions but to instead wrap a big `try` block around everything near the outer boundary of…

As someone who uses Go professionally now and Java previously, I disagree with your take on unchecked exceptions. I think that Panics and errors is worse than just using exceptions. I think the latter is just simpler to deal with. At the end of the day, when error handling is complex, its complex with either approach - you have to think carefully about what's happening in the problem domain and come up with a robust solution. What the code level adds is complexity: the Go approach is more complex and consequently worse. I love Go coding but its error handling sucks and I would gladly have the Java approach instead.

Re: Rating 26 years of Java changes

#292

Post by peterashford »

JavierFlores09 wrote: post #77
vbezhenar wrote: post #45

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…

Stuart Marks and Nicolai Parlog recently had a discussion about checked exceptions in the Java channel [0]. In short, while they mentioned that there are certainly some things to improve about checked exceptions, like the confusing hierarchy as well as the boilerplate-y way of handling them, they're not necessarily a failed concept. I do hope they get to work on them in the near future. 0: https://www.youtube.com/wat…

I agree. The only issue for me is that they could be less verbose but given that I'm always using an IDE, this is in practice a non-issue

Re: Rating 26 years of Java changes

#293

Post by peterashford »

_ea1k wrote: post #171
vbezhenar wrote: post #45

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…

I agree with you w/r/t the streaming parallelization. I remember huge arguments about this on some of the lists back in the day, because that design decision had lots of ridiculous consequences. Eg, mutable state capture in lambdas is largely restricted because of the thought that people would use parallel threads within the stream processing blocks. That decision lead to lots of ugly code, IMO. I've also never seen…

I've used Streams before to good effect but I can't say I'm in love with the design. Seems overly verbose.

Re: Rating 26 years of Java changes

#294

Post by peterashford »

MBCook wrote: post #141
MarkMarine wrote: post #52

I’m sure there are better ways to do streams on the JVM, scala being a great example, but however imperfect the implementation is streams are such a net positive I can’t imagine the language without them. I pine for the streams API when I write go.

I totally agree with the criticism about exceptions. If you need exceptions inside a stream it turns into a mess. Overall I agree with you. They are significantly better, even if a little verbose, than not having them. Love cleaning up old loops with a tiny stream that expresses the same thing more compactly and readably. He’s also right on the parallel benefits not really being a thing I’ve ever seen used.

I'm in agreement, too. The intersection of streams and exceptions was not pretty. Streams are still good, but the feature is a little ugly

Re: Rating 26 years of Java changes

#295

Post by peterashford »

b_e_n_t_o_n wrote: post #44

I haven't written much Java but I am learning Kotlin and I really appreciate the language and the whole JVM ecosystem. Yeah yeah, Gradle is complicated but it's waaaaay easier to figure out than my adventures with Cmake, and when I read Java code there is a certain comfort I feel that I don't get with other languages, even ones I'm experienced with like Go. Java feels a bit like a stranger I've known my whole life, s…

I think you might be getting at one of my favourite features of Java. It's a pretty straightforward simple language. It deals with complexity well by not being too clever. I think Go has that too, except for its error handling and perhaps channels

Re: Rating 26 years of Java changes

#296

Post by peterashford »

parallax_error wrote: post #109

I can’t believe lambdas got a 4/10! I’m a student so maybe my opinion will change when I work on “real” code but I really like their conciseness

I've been a developer for over three decades now and I agree with you - Lambdas are really good.

Re: Rating 26 years of Java changes

#297

Post by peterashford »

agos wrote: post #63
marginalia_nu wrote: post #35

Earlier quoted context omitted.

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…

What other language made them think checked exceptions were a good idea?

Checked exceptions are a good idea.

Re: Rating 26 years of Java changes

#298

Post by _ea1k »

lenkite wrote: post #212
_ea1k wrote: post #170

Earlier quoted context omitted.

In theory, yes. In practice, I've found that things get really complicated as soon as you start trying to interact with the spring lifecycle. Figuring out how to customize things and manage priority is the trickiest thing in Spring, IMO.

Please use the facilities of the framework for debugging any lifecycle issues. I was surprised when I found out that people did not use `--debug` for example or enabled logging of application startup events. If you prefer GUI, Intellij even has a Spring Debugger: https://www.jetbrains.com/help/idea/spring-debugger.html

Fair point, honestly. It could easily be a skill issue from not doing this particular type of thing all that often.

Re: Rating 26 years of Java changes

#299

Post by fleventynine »

mightyham wrote: post #250
fleventynine wrote: post #106

Still no unsigned integer types in the standard library after 26 years?

In one of James Gosling's talks he tells a funny story about the origin of this design decision. He went around the office at Sun and gave a bunch of seasoned C programmers a written assessment on signed/unsigned integer behaviors. They all got horrible scores, so he decided the feature would be too complicated for a non-systems programming language.

Non-systems languages still need to interact with systems languages, over the network or directly. The lack of unsigned types makes this way more painful and error-prone than necessary.

Re: Rating 26 years of Java changes

#300

Post by tpmoney »

taftster wrote: post #173
le-mark wrote: post #159

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…

> Annotation configuration makes this (near?) impossible to dynamically wire and configure these scenarios and make them tailored to the environment or deployment scenario. Annotations are generally "static" and do not follow a configuration-as-code approach to application deployment.

Off the top of my head, you could drop a `@Profile` or `@ConditionalOnProperty` annotation on each of your different schedulers and pick them at launch time simply by adding the profile you want to the arguments or the environment. That assumes you want to choose one for the whole app. If you want to have different ones in different locations, you can dynamically load beans in code. Or if you want them loaded entirely with annotations, you could define differently named beans for each context, and include `@Qualifier`s on them and in the locations they're being used.

Which isn't to say that annotations are perfect, but dynamic runtime configuration is sort of core to how spring operates, and annotations are no exception to that.

Post reply on HN