Live data from Hacker News

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

91–100 of 402 posts

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

#91
post #80
post #70

Earlier quoted context omitted.

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

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

I also did some J2ME stuff back in 2003, most with Sharp and Nokia devices.

I read somewhere that some in the Android team are C converts doing their first Java gig.

Have you seen how broken are the generated Renderscript bindings? They don't have anything to do with Java conventions and feel completely out of place.

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

#92
post #9
post #3

Earlier quoted context omitted.

I agree... can't live without Dependency Injection (one of the reasons I refuse to move off of Java). I've been using CDI and TomEE for small simple stuff (it just works). Can't stand Spring Framework anymore. It set out to replace the bloatware of Java EE 1.5 but it ended up becoming what it was meant to replace.

Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able to replace an implementation outside the source code itself ? You'd still have to extensively test the thing and recompile it... Is there more to it than just being able to replace a class by its mock up, for unit testing ?

It tries to disentangle two different problems:

1. Does my class work appropriately? Does it encapsulate/hide/abstract the right behavior? Does it function correctly with other classes that implement certain inferfaces?

2. Is my network of classes correctly defined so that I can use them all together in a particular way?

http://programmers.stackexchange.com/questions/92393/what-do...

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

#93
post #2

What about dependency injection in modern java - is Guice or spring still the de facto standard?

I try to avoid it as much as possible. It's confusing at least to me and makes maintaining code over a long haul an arduous dull process. I'm getting to the point where I prefer straight JDBC over Hibernate too. It takes longer to code but I've seen speed increases of several times over Hibernate in those situations. JDBC code is just linear but I feel it's easier to maintain in the long run.

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

#94
post #83

Good article, lots of opinions but the title forewarns. For me, Eclipse is still very good and if anything, more stable than in earlier years. I've tried NetBeans and the free IntelliJ but though those are fine, Eclipse is better for me. The real trick is to _not_ store your code in the workspace (which is ironically where the project wizards default to unless you change it). Store your code in as an example, svn for…

As an eclipse user this suggestion intrigues me, but I'm not sure what the workflow would actually look like. Do you have a pointer to an article or something? Thanks.

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

#95
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 of punishing all production code everywhere.

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

#96

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!

In what way is Java a "dynamic language" ?

I think he meant dynamic as in ability to adapt rather than a dynamic language like python

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

#97

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…

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.

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

#98
post #64

Earlier quoted context omitted.

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

One of the reasons I love programming in Python so much is the focus on idiomatic code and 'one obvious way to do something' means that unfamiliar codebases or APIs are easier to read, and patterns for common tasks are seen again and again.

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

#99
post #80
post #70

Earlier quoted context omitted.

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

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

> Late edit: perhaps Oracle should make a phone ;)

They did an open spec tablet with a raspberry pi tough.

https://wiki.openjdk.java.net/display/OpenJFX/DukePad

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

#100
post #68

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.

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

The billionaires at WhatsApp beg to differ. They got very very rich from "mobile non-Android Java".
Post reply on HN