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

331–340 of 402 posts

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

#331

Post by izacus »

donniezazen wrote: post #316
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.

Uhm... Android tools work just fine with the newsest stable JDK 7.

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

#332

Post by izacus »

pswenson wrote: post #221
izacus wrote: post #218

Earlier quoted context omitted.

After doing couple of Android projects with Gradle I've felt like Maven is a godsend. It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things). Also any compilation inside ID…

for normal dependency management you shouldn't need to write code. I've never done any android dev, so I can't comment on that. declaring a dependency is literally like this: dependencies { compile group: 'commons-collections', name: 'commons-collections', version: '3.2' testCompile group: 'junit', name: 'junit', version: '4.+' } But I am not going to be the great gradle defender :) I have many complaints..... I woul…

Yeah, for normal dependencies that's true. But on Android you quickly get some additional things that have to be handled by the build system:

* Code generation from annotations (reflection on Android is slow, so doing code generation is way better) * Attaching native .so libraries in proper directories of APK (Maven plugin does that automatically, Gradle needed writing code for that to work) * Properly handling RenderScript backwards compatibility library (there was no Gradle support for that at all)

* Testing - Robolectric is still not supported which throws a wrench into whole Jenkins/TeamCity autotest stack and needs fiddling with emulators

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

#333

Post by izacus »

vorg wrote: post #240
izacus wrote: post #218

Earlier quoted context omitted.

After doing couple of Android projects with Gradle I've felt like Maven is a godsend. It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things). Also any compilation inside ID…

> Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project Are the sparse features, slow executes, and bugginess due to Gradle or due to the scripting language it uses? www.gradle.org/overview says they will happily support any community effort to create additional build script engines for G…

I think it's just mostly the fact that tools aren't complete: e.g. IDEs will parse Maven pom.xml and use internal builders to speed up compilation while when using Gradle you're always spawning the external builder.

Same goes with other things: we had to write Groovy code to handle build cases which Maven plugins handle by default. That's mostly an ecosystem issue.

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

#335

Post by pron »

peterarmstrong wrote: post #277
pron wrote: post #5

Earlier quoted context omitted.

I'll address that in part 3. Basically jsr330 is a good standard, and it's implemented by Guice, Dagger and Spring

If you're planning at least 3 parts, have you considered turning this tutorial into a Leanpub book? It's the perfect start to one... (Disclosure: I'm a Leanpub cofounder)

I don't know. I'll give it a try.

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

#337

Post by jaegerpicker »

pjmlp wrote: post #102
higherpurpose wrote: post #81

Earlier quoted context omitted.

Especially since Google hasn't updated its Java language much lately. I think the solution for Google is to deprecate Java and start using Go. That would solve more than one problem for them.

Back when I was initially impressed by Go before the 1.0 release, I created a ticket for Go on Android, which is still open. I doubt it will ever happen.

There are a bunch of rumors that Google will announce expanded GoLang support on Android at IO. What that means I'm not sure and I can't find the link for it now. It was a somewhat credible source but not one I'd bet the farm on or anything. I suspect if anything is announced it would be GoLang ndk support but we can dream and hope for more. A python to Davlik compiler would be a very interesting move also.

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

#338

Post by umut »

turar wrote: post #283
Omnipresent wrote: post #253

Earlier quoted context omitted.

I'm using Dropwizard for the same reason. It is dead simple and gets me going out of the box. You should also give Grails a try if you plan on having a view layer

Dropwizard seems to have a view layer of its own that you can bolt on as well.

Yes it is just a binding between Jersey and templating engines (they maintain two of them: mustache.java and freemarker. I strongly recommend freemarker, since it is more complete in UI related transformations. This way it lets your Model layer to stay clean. But if you need something exotic, you can bind to your templating engine of choice easily)

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

#339

Post by umut »

ZitchDog wrote: post #170
EdwardDiego wrote: post #167

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/

We use JDBI @Truecaller together with Metrics library. Not only it is clean and tidy, it also gives you immediate profiling around your database calls. This is priceless in a big service oriented environment. With it, you can exactly see the rate of happening (mean/last 1/5/15 minutes average) and latency (mean/avg/std-dev/75/95/98/99/99,9percentiles) for each database query. I wouldn't want to go back to manual logging and optimization hell. JDBI+Metrics opens a totally new dimension to your monitoring/profiling/optimization!

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

#340

Post by donniezazen »

izacus wrote: post #331
donniezazen wrote: post #316

Earlier quoted context omitted.

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.

Uhm... Android tools work just fine with the newsest stable JDK 7.

I hear not all libraries are supported. developer.android.com and almost all tutorials/courses recommend using JDK 6.
Post reply on HN