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

61–70 of 402 posts

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

#61

Post by UK-AL »

wtetzner wrote: post #47
snikeris wrote: post #18

Earlier quoted context omitted.

I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.

So why not just pass its dependency as a constructor argument?

That's what IoC containers do, or via setter.

However a IoC container can automatically create, and send through the object based convention(IMessageQueue -> MappedTo -> MessageQueue) or configuration (IMessageQueue -> MappedTo -> APMQMessageQueue).

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

#62

Post by cpprototypes »

mhaymo wrote: post #48
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…

Android already supports most of Java 7 http://tools.android.com/tech-docs/new-build-system/user-gui... I'm not aware of any plans to support Java 8 yet, but I haven't been looking.

They support Java 7 syntax, however they do not have the API improvements in Java 7. For example, Java 7 introduced a much improved File IO API in the java.nio.file package. It has very useful classes like Files (http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...)

Android does not have any of this (http://developer.android.com/reference/packages.html) because the Apache Harmony project died before it could implement Java 7 API changes.

This is a much bigger issue for Java 8. Just supporting only Java 8 syntax changes greatly reduces the benefits of the new lambda and default methods. Much of the power of the changes, especially lambda, require the changes to the collections API.

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

#63

Post by nollidge »

AnimalMuppet wrote: post #27
nollidge wrote: post #14

Earlier quoted context omitted.

Yeah, I'm of the opinion that if you need a class/method comment to explain what it takes in or spits out, you probably named it badly.

Yes... mostly. I worked with a guy who, for every comment, asked "how can I eliminate the need for this comment?" Usually the answer is to name something better. But sometimes you really need a comment, not because something is named badly, but because, even with the right name, there's something not obvious about it.

Agree completely, that's why I said "probably" :)

EDIT: Comments are useful for explaining things like:

1. Non-obvious side effects

2. Code that's working around a bug in a 3rd party library

3. Code that calls into some non-intuitive 3rd party API

4. Citing your work (e.g. "adapted from stackoverflow.com/blah123")

5. Why you used pattern A instead of the more standard pattern B

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

#64

Post by UK-AL »

a8da6b0c91d wrote: post #24
ryanobjc wrote: post #10

A 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!

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

Its having the knowledge of what subset of features do you stick too, because C++ is quite large feature rich language. There are often many ways of doings things.

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

#65

Post by karlmdavis »

exabrial wrote: post #51
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. Use public, protected, private fields as they were meant to be used. I only dip into JavaBean anymore if I need a readable but non-writable field.

For me that's almost all fields: I try to make just about everything immutable by default. Makes reasoning about concurrency much simpler.

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

#66

Post by Terr_ »

leorocky wrote: post #53

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

> basic things like opening up encrypted TLS TCP connections

IIRC that's sort of a special-case: It's painful because the designers wanted to weave-in policies and integration with sys-admin stuff on the host OS. There's an impedance mismatch between how Enterprise IT wants to handle that versus what a lone-developer would like to create.

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

#67

Post by agibsonccc »

leorocky wrote: post #53

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

What's great about java is the number of libs out there for this. You don't have to use native java threads in this day and age with things like akka out there.

I find akka's java interface amazing to work with (yeah it's a bit odd in some parts)

You could also get used to thread pools and executors.

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

#68

Post by _pmf_ »

spullara wrote: post #42
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…

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.

The question is what Oracle would lose by licensing real Java to Google at reasonable conditions. Mobile non-Android Java is deader than dead.

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

#69

Post by tieTYT »

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

I believe Jetbrains/Intellij-IDEA has created annotations for @NotNull/@Nullable, but afaik these just create warnings in the IDE. Maybe you can configure IDEA to mark these as compiler errors, but I don't know if my peers using netbeans/sublime/whatever would be able to notice when they write code that IDEA will refuse to compile.

I want compilation to FAIL in these cases.

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

#70

Post by pjmlp »

spullara wrote: post #42
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…

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, one cannot use try-with-resources anyway.

Post reply on HN