Live data from Hacker News

Rating 26 years of Java changes

neilmadden.blog

151–160 of 327 posts

Re: Rating 26 years of Java changes

#151
post #87

Java is great, Spring ruined the platform.

Clearly someone who never knew EJBs.

(I know the irony of Spring is that it became what it replaced. But it got a good ten or fifteen years of productivity before it began getting high on its own supply. )

Re: Rating 26 years of Java changes

#152
post #78

Wow I can’t believe try with resources is so old! I’ve been working with Java for years and only learned this exists recently, I thought it must be relatively new. 14 years!

It was such a lifesaver for doing raw database stuff. The boilerplate for making sure Connection, PreparedStatement, ResultSet and so on were all released properly was a huge pain before that.

Despite it being available at the time I too didn’t learn it until much later. I really wish I had known.

Re: Rating 26 years of Java changes

#153

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?

It can. But seeing the text there is faster than having to hover to see what the type is.

It exists. It’s fine. People obviously like it.

Some don’t, I’m one of them. I don’t see the advantage is very big at all. I don’t think it’s worth the trouble.

But that’s me.

Re: Rating 26 years of Java changes

#154
post #87

Java is great, Spring ruined the platform.

As someone who has used Java pretty extensively for a few years (but in an environment where Spring was forbidden), why is that?

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 annotation to get a new component you can reference anywhere easily is great. Spring for controllers when making HHTP endpoints? And validation of the data? Love it!

Some of the other modules like Spring Security can be extremely confusing. You can use the Aspect Oriented Programming to go overboard and make it nearly impossible to figure out what the hell is happening in the program.

Spring is huge, and it gets criticized for tons of the more esoteric or poorly designed things it has. But the more basic stuff that you’re likely to get 90+ percent of the value out of really makes things a lot better. The relatively common stuff that you’ll see in any Spring Boot tutorial these days.

Re: Rating 26 years of Java changes

#155
post #148

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

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 doing less-common, low-level operations.

Re: Rating 26 years of Java changes

#156
post #63

Earlier quoted context omitted.

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

I assume it was the other way around, a slight twist to exceptions, only enforced by the compiler (the JVM doesn't care about checked/unchecked) probably seemed a cheap and reasonable way to implement explicit error handling. Given that Java ergonomics of the time didn't offer any convenient and performant way to return multiple values instead.

I always thought of it as a reaction to the “your program can throw anywhere for any reason due to an exception” nature of C++.

So they added checked exceptions. That way you can see that a function will only ever throw these two types of exceptions. Or maybe it never throws at all.

Of course a lot of people went really overboard early on creating a ton of different kinds of exceptions making everything a mess. Other people just got into the habit of using RuntimeExceptions for everything since they’re not checked, or the classic “throws Exception“ being added to the end of every method.

I tend to think it’s a good idea and useful. And I think a lot of people got a bad taste in their mouth early on. But if you’re going to have exceptions and you’re not going to give some better way of handling errors I think we’re probably better off than if there were no checked exceptions at all.

Re: Rating 26 years of Java changes

#157

Earlier quoted context omitted.

OCaml's type inference is truly amazing, makes it such a delight to write statically typed code - reading it on the other hand... But I think that's easily solved by adding type annotations for the return type of methods - annotating almost anything else is mostly just clutter imo.

Annotations would be a substitute for writing the return type. Extra code for a shortcut seems like the worst solution.

I don't mean Java annotations, those would be too clunky - in OCaml a type annotation is really just adding `: ` to variables, function return types, etc.

so fibonacci could look like this

```

let rec fib n =

  match n with

  | 0 -> 1

  | 1 -> 1

  | _ -> fib (n - 1) + fib (n - 2)
```

or with annotations it becomes this:

```

let rec fib (n: int): int =

  // Same as above :)
```

Re: Rating 26 years of Java changes

#158
post #154

Earlier quoted context omitted.

As someone who has used Java pretty extensively for a few years (but in an environment where Spring was forbidden), why is that?

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.

Re: Rating 26 years of Java changes

#159

Earlier quoted context omitted.

And then I realize I need to change that schedule. And would like to do it without recompiling my code. Oh, and I need to allow for environment specific scheduling, weekdays on one system, weekends on others. And I need other dependencies that are environment specific. I much prefer Spring's XML configuration from the old days. Yeah, XML sucks and all that. But still, with XML, the configuration is completely externa…

I do realize you were intending to give examples of why you don't think annotations aren't very extensible, but it is an odd example as all those things can still be achieved via annotation, since the annotations can accept values loaded from env specific properties.

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!

Re: Rating 26 years of Java changes

#160
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…

> For example they used checked exceptions. Those definitely do not seem like proven feature.

Checked exceptions are an awesome feature that more languages should have. Just like static typing is a good thing because it prevents errors, checked exceptions are a good thing because they prevent errors.

Post reply on HN