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

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

Post reply on HN
Print view View original

321–330 of 402 posts

Re: An Opinionated Guide to Modern Java Development, Part 1

#321

Post by eonwe »

pswenson wrote: post #272
zmmmmm wrote: post #269

Earlier quoted context omitted.

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

Depending on the software and what it's used for, the first class or errors might and should be recoverable from.

Re: An Opinionated Guide to Modern Java Development, Part 1

#323

Post by adamwbarr »

virtualwhys wrote: post #313
adamwbarr wrote: post #310

Earlier quoted context omitted.

scala> val x = Some(null) x: Some[Null] = Some(null)

That's pretty contrived, when would you _ever_ wrap a thing that could be null in a Some? Even so, to continue with your example: scala> x foreach println null x.get res2: Null = null Hey, what do you know, no NPE. Try harder ;-)

Ok fair point re it being contrived!

Although (having just re-read it), the original post's complaint was actually that:

> the compiler (afaik) doesn't prevent you from setting an Optional field to null

ie

  scala> val option: Option[Any] = null
  option: Option[Any] = null

Re: An Opinionated Guide to Modern Java Development, Part 1

#324

Post by lmm »

lomnakkus wrote: post #229
lmm wrote: post #134

Earlier quoted context omitted.

I do that a lot, or rather my commit messages are usually "mumble" or "fixed this" or "awookga". I feel this is more justified than the javadoc case because you can always just leave out javadoc, whereas the VCS forces me to put a commit message.

Just a humble suggestion, but perhaps you should enter a message which states the intent or the functionality of the change more explicitly. (If you're just doing a topic branch, then sure, just say "wip" or "blah", but please clean it up with "git rebase -i" before merging.)

Always topic branches yeah. My team puts that kind of information in the pull request, which ends up playing the role that a commit would in SVN or the like. I guess we could squash our merges to achieve the same effect, but we haven't felt the need yet - the pull request is a nicer interface than a git log.

Re: An Opinionated Guide to Modern Java Development, Part 1

#325

Post by AmrMostafa »

If you have come to this post expecting to read something related to modern Java for the web, and have come back unsatisfied, then here is something to make up for that: yeoman's jhipster generator: http://jhipster.github.io/

Presentation: http://jhipster.github.io/presentation/

Re: An Opinionated Guide to Modern Java Development, Part 1

#326

Post by umut »

lmm wrote: post #36

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

Couldn't agree more.. But this comes with the most cliche discussion with a smartass looking at your code. Dude, I know what getters and setters are, I just don't agree

Re: An Opinionated Guide to Modern Java Development, Part 1

#327

Post by umut »

edwinnathaniel wrote: post #120
umut wrote: post #58

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.

Jetty is up to date, but Jersey is old yes. But the new jersey is also a bit problematic, more stuffy and slow (from the benchmarks of others, I haven't done it myself). But the good thing is, there is a big and passionate contributor community around dropwizard (check their github/google groups) and this means if the new versions of libraries are worth updating, they get in pretty quickly.

Re: An Opinionated Guide to Modern Java Development, Part 1

#328

Post by clumsysmurf »

mncolinlee wrote: post #82
cpprototypes wrote: post #29

I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvik is not "true Java" and is more like a VM that happens to implement a language very similar to Java 1.6). There's now a huge gap between 1.6 and 1.8. It's not just syntax like lambda and default methods. It's also the supporting API changes in collections (str…

Dalvik is being slowly replaced by ART (Android RunTime). Also, you can pretty easily hack Java 7 or even Java 8 into Android to use lambdas. Official, default support is coming soon. http://tools.android.com/tech-docs/new-build-system/user-gui... http://zserge.com/blog/android-lambda.html

>> Official, default support is coming soon.

Default support of ART or Java 8?

If Java 8, how do you know this? Citation needed ;)

Re: An Opinionated Guide to Modern Java Development, Part 1

#329

Post by uptownJimmy »

twic wrote: post #157
pjmlp wrote: post #114

Earlier quoted context omitted.

Some pruning is planned for Java 9, at least is was announced so at Java One last year.

It's not just the JDK that needs pruning, though. It's the ecosystem of third party libraries, and the millions of pages on blogs and StackOverflow (and shudder JavaRanch) that contain bad, outdated advice, following which will make people hate Java.

Yeah, as an obsessive newbie/student, I can attest that JavaRanch is almost enough to put you off Java forever...
Post reply on HN