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

291–300 of 402 posts

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

#291

Post by spullara »

izacus wrote: post #123
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…

Hmm, what you write makes no sense.... even if Google would use Oracle Java, we'd still be stuck with devices running Java 1.6 JVMs. Having a different implementation doesn't change the limitations imposed by out of date VM running on a device.

Why would they run 1.6 JVMs? Why wouldn't they run the latest?

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

#292

Post by spullara »

sixbrx wrote: post #245
georgewfraser wrote: post #188

Earlier quoted context omitted.

Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.

I think you got it right. According to Grzegorz Kossakowski's comment (which is more accurate than the misleading article) : http://www.takipiblog.com/2014/01/16/compiling-lambda-expres... , Java 8's lambda's aren't particularly efficient. They do create an anonymous class instance at runtime, as you say. Scala closures are implemented in a similar way, without invokedynamic, and as he says, and currently there is no…

I don't think that person understands how it works at all.

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

#293

Post by zmmmmm »

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…

If Java forced you to handle the exception that would be convincing, but it doesn't. It merely says, if you don't want to handle it, add to your signature that you throw an exception so that at least someone upstream has a chance to know that the error might occur. I'm not arguing at all btw that the way Java does it is good. Merely that there's a case for checked exceptions, especially if you are actually trying to write "reliable" software.

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

#294

Post by sbilstein »

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.)

Yes, even something trivial like "fixes whitespace" is better then nothing, but even better is squashing or amending a previous commit. Some systems prevent this...at my workplace once you've pushed to origin, there is no changing the past so saying something like "Added derp.java to fix broken build from " is very helpful.

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

#295

Post by userbinator »

bsaul wrote: post #6

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 think that to a certain extent, the standard library also encourages this culture, since that's the most prominent and arguably widely used piece of software that's written in Java and it will be used as an example of "good" code.

The continuing notion that CS classes teach objects first (I've heard recommendations that it be before even conditionals and loops, shockingly enough) I think is also a contributing factor: "When all you have are classes, everything turns into an object."

But as things like Java4K suggest, the bloat may not be inherent in the language itself; it's certainly possible to write concise, efficient Java code.

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

#296

Post by ryanobjc »

pswenson wrote: post #263
altcognito wrote: post #254

Earlier quoted context omitted.

What kinds of logic are you putting in your builds? That's a sign you are doing things wrong.

hmm I wonder why this got created? http://ant-contrib.sourceforge.net/tasks/tasks/ 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…

I often find that "can be declarative" means that over the long term in a big project means "isn't declarative"

After all you can do functional programming in any language. Why do you need another.

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

#297

Post by virtualwhys »

the_af wrote: post #264
steveklabnik wrote: post #87

Earlier quoted context omitted.

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.

Indeed, Option in Scala has the same problem. I understand null is needed for backwards compatibility, but it makes Option the poor man's Maybe...

> Indeed, Option in Scala has the same problem

eh?

    scala> val safe = Option(null)
    safe: Option[Null] = None

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

#298

Post by emsy »

vorg wrote: post #235
emsy wrote: post #193

Earlier 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.

> you can see Groovy as "Java without semicolons" Only a very small subset of Groovy is used by the typical Gradle build script, the very subset of Groovy that's least like Java . What part of this build script from the linked article bears any resemblance to Java?... apply plugin: 'java' apply plugin: 'application' sourceCompatibility = '1.8' mainClassName = 'jmodern.Main' repositories { mavenCentral() } dependencie…

I understood the post I replied to as if the author wanted to configure something custom and thus needs to write code. I didn't assume that the original argument was supposed to address the configuration of a standard build. Because you'll always have to learn a new syntax for the tool. Use Make-> Learn make syntax. Use Maven-> Learn POM syntax. Use Gradle -> learn the DSL syntax. Want to extend Gradle -> learn Groovy, a "superset" of Java.

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

#299

Post by levosmetalo »

benjaminpv wrote: post #22
kodablah wrote: post #12

One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some c…

Seconded. I always bristle when I see javadocs that include things like 'returns an object of [x] type that...' You're dealing with strong types, the signature provides all this information already. That, combined with good variable names, should do a lot of the documentation for you. If you wanna document a method, document what problem it solves. Document any gotchas (or better yet, redesign them out o_~). Don't ju…

I've been guilty of that kind of comments you despise when I had to work in environments where software "quality" metrics were applied to all checked in code as a part of build process and your code was marked as "low quality" because you missed @return document entry in your Javadoc. You can bet that, with few IDE templates to autogenerate all missing JavaDoc on save my metric was quite good. In addition to that, I completely stopped trying to write good docs. What you measure is what you get in the end.

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

#300

Post by mateuszf »

cdmckay wrote: post #260
mateuszf wrote: post #209

Earlier quoted context omitted.

Yep, the thing is that Date is immutable. I think that this public final immutable rule is ok, but one has to ensure the fields themself are really not modifiable.

The Java Date class is not immutable.

So you can use a wrapper or Joda time library.
Post reply on HN