261–270 of 402 posts
Earlier quoted context omitted.
Not quite. eg: public final Date date; date.setTime(1); That's not immutable.
The bean convention doesn't help you with that one though; if you have private Date date; public Date getDate() {return date;} then people can still do getDate().setTime(1);
Earlier quoted context omitted.
> old, outdated info out there I'd love it if the JDK had a "learner mode" that disabled interned string literals . Then newbies experimenting with `assert(str1 == str2)` wouldn't leap to false conclusions.
== should never have been used for that method, which is very rarely what you want. The right thing is probably to deprecate == on nonprimitive types, replacing it with a longer name that's clearer about what it means.
This is what Scala and C# do.
Earlier quoted context omitted.
Agreed. On top of which XML has no capacity for logic, barring an incredibly contrived construct.
What kinds of logic are you putting in your builds? That's a sign you are doing things wrong.
I wonder if anyone said this about HTML when javascript was introduced?
once a system starts getting complicated you inevitably need code.
two points:
* gradle builds can be completely declarative. you write code only if you need it
* builds also are often used for very specific automation. in ant, you end up having to write custom ant tasks. this is fairly painful compared to just creating new classes, tasks, or scripts directly in gradle.
That pluggable type system looks amazing. One thing that's weird to me is how java included a new Optional type (seems similar to Haskell's Maybe), but the compiler (afaik) doesn't prevent you from setting an Optional field to null. Something about that doesn't feel right. (Side Note: Optional isn't serializeable. Also... what's the best practice for using Optional when I'm using JPA? Can it be used in my Entities?)…
It's certainly a bit strange, but it's how Scala works as well. I wonder if it's for backwards compatibility reasons, given that everything is nullable already. Have to give it more thought though.
Why do people seem to think "opinionated" is a virtue these days?
- Java is such a massive ecosystem that you need someone to guide you through the complexity and to show you the diamonds among the piles of dung.
- You're being honest. Really, my impression of Java has been so bad because of people that want "industry standard" and "enterprise" things that I welcome fresh perspectives from people in the field. Ultimately, if someone points out that a certain statement is they own opinion it's easier for you to judge it in a broader context, so even if you still disagree you don't feel like you're being misled.
I'd like to hear thoughts on CheckedExceptions in part 2. IMO, they are a disaster - most projects degrade into all methods having a "throws Exception" clause. But I'm not sure if there is any consensus on how the CheckedException haters like myself work around them. I use Runtime exceptions everywhere, but it's a pain/boilerplate to convert them.
I think some of the additions in Java7/8 will make them a little easier to work with. The worst thing used to be the necessity to nest multiple try/catch blocks, or repeat identical code between separate catch blocks because different components throw different errors. This is now dramatically helped by the multi-catch and other additions. Like you, I use a lot of RuntimeExceptions, but I think in it's important not…
2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now
3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs the exception and continues along as if nothing happened. If my bank deposit fails, I don't want the failure to just end up in a log file - I want to know it! Exceptions were designed to usually bubble up and be exposed/handled in a standard way at the top level thread. They are usually not recoverable.
4) they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.
5) if they are such a good idea, why does no other language ever created has them?
I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine. The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session. Add to that the fact that every s…
I was just recently trying to decide between "new" Spring MVC, Dropwizard, and Play. Spring now has a bunch of slick-looking guides and tutorials. But then I looked at the actual contents of their tutorial project, and it just turned me off. For an "example" REST project, they had over 50 classes not including tests: https://github.com/spring-guides/tut-rest/tree/master/6/comp... , with many being "event" classes of…
Earlier quoted context omitted.
For immutable you can just use public final fields. I assume GP must be talking about fields that are mutated but only by the object itself, where outside code needs to be able to read but not write.
Not quite. eg: public final Date date; date.setTime(1); That's not immutable.
Earlier quoted context omitted.
I think some of the additions in Java7/8 will make them a little easier to work with. The worst thing used to be the necessity to nest multiple try/catch blocks, or repeat identical code between separate catch blocks because different components throw different errors. This is now dramatically helped by the multi-catch and other additions. Like you, I use a lot of RuntimeExceptions, but I think in it's important not…
1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods. 2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now 3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble…
Try doing that in a code base without checked exceptions. You just created 100s or 1000s of unrecognised errors in other code without realising it. The problem is not the checked exception. The problem is you changed something 100s or 1000s of things are relying on to add a new failure mode.
> Checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs ....
Well, I agree up to a point. But that is much to do with how tedious and verbose the error handling itself is which is more about the language than the concept of checked exceptions.
> they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.
see above
> 5) if they are such a good idea, why does no other language ever created has them?
Well, you can also say, if they are such a bad idea, how come one of the world's most popular and used language builds them into all its core APIs? They can't be that terrible or Java would never have got so popular ....
Earlier quoted context omitted.
I can strongly recommend Dropwizard for the plan. It is much less stuffy/enterprisy and you can easily split big apps into smaller services. It is some glue code on top of Jersey run in embedded mode Jetty (thus very little ops work needed). Play Framework is also nice, but a bit too much opinionated! Meaning hard to make it do something in another way, which happens in real world big applications...
Jetty + Jersey that Dropwizard use is old (couple versions behind) AFAIK.