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

311–320 of 402 posts

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

#311

Post by squeaky-clean »

icebraining wrote: post #109
spullara wrote: post #42

Earlier 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 supported Google because the ends don't justify means. People should have the right to re-implement APIs, even if we sometimes wished they didn't.

Well put. Just because it wasn't a good idea doesn't mean it should be illegal.

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

#312

Post by pjmlp »

kazagistar wrote: post #206
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?)…

The main issue with non-nullable types in OOP, in my mind, seems to be defaults. Quite simply, when you don't initialize an primitive, you get a 0, and when you don't initialize an object, you get a null. Not all fields must be initialized by the time the constructor ends, so some kind of valid default exists. Enforcing non-nullability would involve somehow enforcing that the variable is always valid before use some…

Outside the JVM world, Eiffel does it.

In the JVM world, Kotlin and Ceylon do it as well.

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

#313

Post by virtualwhys »

adamwbarr wrote: post #310
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

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

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

#315

Post by mschulze »

turar wrote: post #202
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 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…

No, that example just covers more features, I guess typically you won't need events.

For a really quick start I would recommend https://github.com/spring-guides/gs-spring-boot/tree/master/.... 2 classes and you don't even need an external servlet container.

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

#316

Post by donniezazen »

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…

Not to mention debacle it creates on your system. Android requires/plays-well with JDK 6 and you probably want to be running the latest version of Java for security purposes. Maintaining multiple JDKs have been nothing but troubling for me.

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

#317

Post by mschulze »

levosmetalo wrote: post #303
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…

I used Project Lombok back in the days to get read of Javabeans boilerplate. Just declare your private fields and put @Data annotation on class, and it would generate at compile time all your getters, setters, equals, toString, constructor and hashCode methods. Really helps to keep the code lean and small. Don't know does it work with Java 8 though or it didn't yet catch up.

I used Lombok in a Java 8 project without problems.

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

#318

Post by llemiengre »

spullara wrote: post #292
sixbrx wrote: post #245

Earlier quoted context omitted.

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.

He knows what he is talking about & his description matches the explanation by Brian Goetz.

So unless I'm missing something, please be specific.

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

#319

Post by nvarsj »

pswenson wrote: post #195
tieTYT wrote: post #50

> But the modern Java developer uses Gradle I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.

I'd say Gradle is the least awful of the 3 major build systems. Ant degrades into an unmaintainable mess as soon as any complexity enters the system. XML is a horrible scripting language, simple imperative constructs are very awkward (loops/variables/conditionals). Maven also suffers from XML hell, but at least it has dependency management. I've used gradle extensively and it is quite difficult to figure out what is…

Actually, Maven uses XML right - as configuration, not code. This is where Ant was terrible - you ended up writing imperative code with XML statements.

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

#320

Post by nvarsj »

I have to agree with the first comment on the blog. Gradle is strictly worse than Maven - it's basically Ant reinvented with Groovy. It leads itself to poorly maintained, complex build files, and the only good parts are the bits that use Maven under the hood (so just use maven ;-)). It's also slow.

Also, if you seriously want to use an Actor framework in Java, you should use Akka - the lead devs really know their stuff, and are active in Java concurrency circles (JSR-166).

Post reply on HN