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

361–370 of 402 posts

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

#361

Post by dminor »

wil421 wrote: post #341
darylteo wrote: post #284

Earlier quoted context omitted.

What if I told you that Java code is perfectly compilable in Groovy and learning the required amount of Groovy isn't that much anyway? There's even a JavaDoc that you can reference at any time. And even now in Java 8, you have Lambdas... well guess what? Groovy uses Closures everywhere, and the syntax is similar too. So it really shouldn't be black magic.

What if I told you I am not a very experienced java programmer and learning something new wouldn't really help me become a better java programmer. That and my employer uses Java and randomly chooses PHP sometimes for no apparent reason.

All of the build tools have their own little DSL and none are going to help you become a better java programmer. Just pick what works best for you.

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

#362

Post by zenbowman »

pkolaczk wrote: post #342
zenbowman wrote: post #181

Earlier quoted context omitted.

Exactly. I'd argue C++ has a lot going for it, and I think the claim that Java's performance is only slightly slower is simply not true for the vast majority of situations where good memory organization can provide significant speedups - which includes any computer graphics, vision or audio application. I personally find C++11 more high-level than Java and significantly more optimizable for performance. You can wax p…

Java is fast enough now to compete with C++ in some categories of software traditionally viewed as "high performance" e.g. web-servers or database systems. Applications running like "turtle on anything short of server-class hardware" is a result of bad-coding, not Java itself.

In some categories, yes.

In many others, especially those requiring vector or matrix arithmetic (medical imaging, physical simulations, modeling, graphics, scientific computing, video games), there's simply no competition.

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

#363

Post by pjmlp »

vorg wrote: post #344
pjmlp wrote: post #307

Earlier quoted context omitted.

From the usual JUG discussion themes I also get the impression, if it wasn't for Gradle, the Groovy interest would be much lower nowadays. There was a Grails wave here in Germany, but now I seldom see anything related to it.

Yesterday's Who is hiring? ( https://news.ycombinator.com/item?id=7679431 ) only had 1 mention of Groovy or Grails (and none of Gradle) out of over 400 comments. And many (most?) of the projects tagged Groovy on Github are triggered by a single Gradle build script for a project that uses some other language. These Gradle build scripts are often 30 lines long. So I'm not sure how Groovy will fare in the future. Nothin…

I seldom used it.

Back in 2009 there was a big Grails wave here in Germany. Many JUGs had Groovy and Grails talks.

There was also some people trying to use Groovy with JSF. Myself I attended a session promoted by Sun hitting at possible official support after the JSF 2.0 release.

To the point we added support to it in our in-house JSF framework SDK, still JSF 1.x based.

Since late 2010 I have been doing .NET land mostly and now back on Java land, I hardly see any Groovy besides Gradle.

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

#364

Post by a8da6b0c91d »

zenbowman wrote: post #362
pkolaczk wrote: post #342

Earlier quoted context omitted.

Java is fast enough now to compete with C++ in some categories of software traditionally viewed as "high performance" e.g. web-servers or database systems. Applications running like "turtle on anything short of server-class hardware" is a result of bad-coding, not Java itself.

In some categories, yes. In many others, especially those requiring vector or matrix arithmetic (medical imaging, physical simulations, modeling, graphics, scientific computing, video games), there's simply no competition.

In anything where Java approximates the speed of C++ it uses two or three times as much RAM.

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

#365

Post by pkolaczk »

zenbowman wrote: post #362
pkolaczk wrote: post #342

Earlier quoted context omitted.

Java is fast enough now to compete with C++ in some categories of software traditionally viewed as "high performance" e.g. web-servers or database systems. Applications running like "turtle on anything short of server-class hardware" is a result of bad-coding, not Java itself.

In some categories, yes. In many others, especially those requiring vector or matrix arithmetic (medical imaging, physical simulations, modeling, graphics, scientific computing, video games), there's simply no competition.

Not sure of that. Some scientists from CERN would certainly disagree... Pure array-based arithmetic in Java is pretty damn fast, especially if you care to avoid dynamic allocations. It can be also very memory/cache friendly.

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

#366

Post by pkolaczk »

a8da6b0c91d wrote: post #364
zenbowman wrote: post #362

Earlier quoted context omitted.

In some categories, yes. In many others, especially those requiring vector or matrix arithmetic (medical imaging, physical simulations, modeling, graphics, scientific computing, video games), there's simply no competition.

In anything where Java approximates the speed of C++ it uses two or three times as much RAM.

10 millions element array of doubles/ints/bytes takes almost exactly same amount of bytes in Java as in C++. Java can blow your memory if you do stupid things like wrapping every point 2D into a separate object, but you know, good Java programmers know this. Other than that, its memory usage is quite reasonable, including some room for GC (typically 20-30% of total is enough).

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

#367

Post by oh_sigh »

kyberias wrote: post #75
oh_sigh wrote: post #19

Earlier quoted context omitted.

Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.

Wikipedia article on dependency injection, section titled "Advantages", _first_ bullet: "The result is more independent clients that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test." Would you like to try again?

The OP said "I mean, what's the point of being able to replace an implementation outside the source code itself."

Where, in what you posted, does it reference being able to replace implementations outside of the source code itself?

Would you like to try again?

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

#368

Post by virtualwhys »

the_af wrote: post #353
virtualwhys wrote: post #297

Earlier quoted context omitted.

> Indeed, Option in Scala has the same problem eh? scala> val safe = Option(null) safe: Option[Null] = None

I don't understand your objection: // The type of 'unsafe' is Option[String] var unsafe = Option("some string") unsafe = null unsafe map println gives Exception in thread "main" scala.MatchError: null effectively a NullPointerException. This would be impossible for a true Option (aka Maybe) type. The problem is introduced because Scala, for backwards compatibility reasons, still allows the assignment of null; this lo…

    // The type of 'unsafe' is Option[String]
    var unsafe = Option("some string")
    unsafe = null
    unsafe map println
Is complete contrived nonsense, var? Seriously, quit trolling, in Scala (immutable) val is king.

Next:

    def unsafeFunction(x: Option[String]): Option[String] = {
      x orElse null
    }
Oh yeah, that's brilliant, let's just try our hardest to come up with scenarios that never occur in the "real" world (unless we try really hard to create nullthing out of nonething).

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

#369

Post by strictfp »

tieTYT wrote: post #69

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

You can at least add runtime assertions automatically with jwtbrains annotation processor (maven plugin). I don't know about compiler errors,

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

#370

Post by spullara »

frowaway001 wrote: post #357
spullara wrote: post #349

Earlier quoted context omitted.

Well, for one, Lambdas are desugared into methods, not anonymous classes. Early on they used anonymous classes because it was convenient but that wasn't the final translation strategy. http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...

Yes, and these methods create an anonymous class at runtime. What's so hard to understand about this?

It was a misunderstanding on my part about where they were claiming the anonymous class was generated. Early versions of Lambda were nothing more than sugar on top of anonymous inner classes and the claim above sounded very similar to that. However, I see that inside the LambdaMetaFactory anonymous classes are generated based on the call site. Probably the biggest difference is that Java 8 can avoid an object allocation when the lambda doesn't capture. Not sure if Scala supports this but I'm sure that it could do it.
Post reply on HN