Live data from Hacker News

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

171–180 of 402 posts

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

#171
post #39

Not a single mention of Guice or even dependency injection? Seems like a gaping omission in a guide that claims to be about "modern" Java.

Dependency injection is an abomination. Working on DI code feels like slogging through the post-processed expansion of some more elegant language. It's hard to understand control flow, and DI adds exciting failure modes to otherwise-correct code. Don't forget that DI also bloats class and method counts. Substitution for testability should be done at the runtime level, substituting class references as needed, instead…

> Substitution for testability should be done at the runtime level, substituting class references as needed

That would require a Java agent. And that's a smell it its own right. (Cf JMockit)

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

#172
post #48

Earlier quoted context omitted.

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…

Guava works on it though, thank goodness!

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

#173

Earlier quoted context omitted.

The performance problems are definitely the most annoying part of using Gradle. The Gradle daemon helped a little but tended to break other things and Gradle was still pretty slow. If you are looking for something faster and more declarative, you may want to check out SBT[0]. It is way faster than any of the other JVM build tools. Also, in the future[1] it should have much better tooling support than anything else on…

SBT has a terrible habit of breaking backwards compatibility, which has put me off it.

I've never had to change anything between upgrades (aside from changing deprecated stuff). Are you referring to the jump between from 0.7 to 0.10 a few years ago or have you had more recent issues?

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

#174

Earlier quoted context omitted.

I agree. Hibernate has become a downright liability at times in our codebase. These days I only use it in new code for query parameterization and result row transforms into models. Speaking of which, if anyone knows of a good library for query parameterization alone, let me know...

JDBI is quite good: http://jdbi.org/

Cheers mate! That createQuery() call looks to be exactly what I need (query safety on a low level JDBC stream object).

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

#176
post #80

Earlier quoted context omitted.

I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse". Late edit: perhaps Oracle should make a phone ;)

> Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse" Try Intellij IDEA / Android Studio. I find them quite reliable.

Intellij IDEA, yes.

Android Studio seems to still have performance issues with Gradle on Windows, specially when indexing stuff.

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

#177
The biggest take I have from this post is that apparently they have created go-like lightweight threads for the JVM with Quasar (http://docs.paralleluniverse.co/quasar/) which is really interesting.

If I understand correctly, Quasar uses bytecode instrumentation to enable user-mode threads for the JVM, and they claim they did benchmarks that show X6 to X12 better performance than native JVM threads: http://blog.paralleluniverse.co/2014/02/06/fibers-threads-st...

This is really something that caught my attention.

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

#178
post #97

Earlier quoted context omitted.

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

Except those lambdas are not as efficient as the standard compliants VMs, as they make use of invokedynamic to generate better code, even inline calls for small lambdas.

Which might be fixable with ART as it's an on-device ahead-of-time compiler (I think it optimizes too? can't find references...). I have no idea if it actually does work for this in practice or not, though.

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

#179
post #80

Earlier quoted context omitted.

I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse". Late edit: perhaps Oracle should make a phone ;)

> Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse" Try Intellij IDEA / Android Studio. I find them quite reliable.

Agreed. I prefer IntelliJ IDEA Community Edition to Android Studio because I like using the same IDE for Android and Java development.

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

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

Project Lombok is your friend then: http://projectlombok.org/features/Data.html

Lombok is an anti-pattern for me. It creates a unholy mess of annotations for what should be language features.
Post reply on HN