Earlier quoted context omitted.
Not quite. eg: public final Date date; date.setTime(1); That's not immutable.
Yeah, but getDate().setTime(1); works the same way.
Not if getDate() returns a copy of the underlying member.
An Opinionated Guide to Modern Java Development, Part 1
271–280 of 402 posts
Re: An Opinionated Guide to Modern Java Development, Part 1
#272Earlier quoted context omitted.
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…
> 1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods. 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…
I think you are falling into the trap of thinking you can usually recover from an exception. Exceptions are usually caused by one of two things:
1) system error (no more DB connections, hard drive full, etc)
2) a bug
neither of these are recoverable, you just need to stop the task at hand and notify someone that the situation needs to be fixed. Trying to handle it and recover is usually a fools errand that results in hiding the problem
There are cases that you do want to handle exceptions. In these cases, yes catch the exception and handle it. But these cases are the 10% case, hence the default behavior of making the caller handle the exception isn't desirable.
This link from 2003 articulates the point better than I can: http://www.artima.com/intv/handcuffs.html
Re: An Opinionated Guide to Modern Java Development, Part 1
#273Earlier quoted context omitted.
There is a good reason that Sun didn't want this to happen and tried to stop it in court — successful against Microsoft, failed against Google. If I remember right, most everyone on here was rooting for Google to win and continue to fragment the language.
I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat,…
> Even J2ME is more compatible with its big brother than Android.
Are you serious?
J2ME is even more crippled than Android's Java (no reflection, no Swing, no AWT and stuck in Java 1.4).
J2ME has been dead for more than half a decade and we have Android to thank for that. Good riddance.
Re: An Opinionated Guide to Modern Java Development, Part 1
#274The #1 thing you need to make Java usable is to abandon the JavaBean conventions. When every field requires 8 lines of boilerplate it's no wonder the code looks ugly (YAGNI, and if you do need it it's two keystrokes in your IDE to "encapsulate field"). public final fields are fine, and can get your data classes something close to readable. I'd stick with maven for the build rather than Gradle; it's completely declara…
For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.
> you can see Groovy as "Java without semicolons
I see it as "Java without types", myself.
I'm aware that Groovy now supports optional typing but if I'm going this path, I prefer to switch to Kotlin, which I describe as "Java with everything that's bad removed".
Re: An Opinionated Guide to Modern Java Development, Part 1
#275I love Java, especially Java 8. But as the article points out, what frustrates me is threading. You can't do much without quickly running into threading issues. I played audio files in a game I made and it created up to 2,000 threads and crashed. Once I wrapped audio in an explicitly created thread this issue magically went away. Any kind of UI, timers, file I/O and network activity also involves threads. The really…
Sounds like it's the implementation of the audio library using thread in the wrong way. Has nothing to do with threading in Java. Nodes could have the problem of starving the audio playback if other parts of your code hogging too long of processing time. It's just shifting the problem around.
I'm not using an audio library. I'm just using Clip and AudioInputStream
Re: An Opinionated Guide to Modern Java Development, Part 1
#276A lot of people love to hate on Java, but it's a surprisingly dynamic language and there is a ton of great testing, networking, and many other libraries available. One of the things I appreciate about Java is the ability to take large teams and just have their stuff work together, without having unhuman discipline around super subtle rules (eg: C++) Also, IntelliJ is a must have!
In what way is Java a "dynamic language" ?
"Dynamic language" != "Dynamically typed language".
Re: An Opinionated Guide to Modern Java Development, Part 1
#277What about dependency injection in modern java - is Guice or spring still the de facto standard?
I'll address that in part 3. Basically jsr330 is a good standard, and it's implemented by Guice, Dagger and Spring
If you're planning at least 3 parts, have you considered turning this tutorial into a Leanpub book? It's the perfect start to one... (Disclosure: I'm a Leanpub cofounder)
Re: An Opinionated Guide to Modern Java Development, Part 1
#278Re: An Opinionated Guide to Modern Java Development, Part 1
#279Earlier quoted context omitted.
For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.
> For starters, you can see Groovy as "Java without semicolons" Not if you have to read other people's code, or understand examples you find on the internet. > I went from Maven to Gradle and never looked back. It's superior in most ways. What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an a…
Maven is simple as long as your build is simple. As soon as you need to do something custom, it's a pain. Gradle is less painful.
Re: An Opinionated Guide to Modern Java Development, Part 1
#280Earlier quoted context omitted.
> super subtle rules (eg: C++) C++11/14 is in practice not that much more difficult to write well than Java. It's not 1998 anymore. The language is larger and more complex than Java, but it's also a lot more expressive and powerful, not to mention faster.
Having spent 5 years doing production C++, I don't believe you basically. All that shit that sucked in 2005 about C++ is still in there. It's just up to your discipline to not use it. Do you trust your coworkers enough?
Yes.
Basically, don't hire incompetent people and do code reviews.
Both rules apply independent of the language, of course.
Source: have spent 5 years doing production C++