An Opinionated Guide to Modern Java Development, Part 1

http://blog.paralleluniverse.co/2014/05/01/modern-java/

by pron • 12 years ago

553 396 12 years ago

blog.paralleluniverse.co

netcraft• 12 years ago

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

exabrial2• 12 years ago

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.

jmgtan• 12 years ago

You should give the latest version a try. Spring implemented JavaConfig, which allows you to avoid XML altogether. Coupled with the ComponentScan annotation, it can't get any simpler.

bsaul2• 12 years ago

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 ?

AnimalMuppet2• 12 years ago

It occurs to me that dependency injection has this strange similarity to functional programming. I mean, clearly, you're playing with objects instead of functions, and they can have state, and so on, so it's not functional. But still, there's a similarity in how you're breaking things apart.

Spring: Maybe the problem is that Jave EE 1.5 was a reasonably good solution for the problems it was trying to solve? Maybe you can't do radically better and still actually solve the problems?

UK-AL5• 12 years ago

What web framework can use that works with CDI, and standard EE stuff that is request-repoonse based?

veeti• 12 years ago

I only do Java on Android, but Dagger (https://square.github.io/dagger/) might be a nice lightweight alternative.

ddeck2• 12 years ago

Dagger is definitely more appropriate for Android applications and was developed specifically to address the issues with using something like Guice on mobile. That said, I love Guice and use it exclusively as it has a superset of features and startup performance is irrelevant in my area.

As Christian Gruber from the development team put it:

Dagger is a joint effort by Square, Google, some individual contributors from other places such as Nextflix, and is descended conceptually from Guice - specifically from MiniGuice. It addresses some key challenges our users faced with Guice. From Square’s side (/u/swankjesse can clarify this) it was the need to get high-performance, low-startup dependency injection on Android. From our side, it was that and the desire to trim the API weight of dependency injection, to reduce the user confusion that comes from reflection and bytecode generation in stack traces and debugging environments, and to get early validation of your graph’s wiring.

Dagger is a substantial direction shift for Google, and we are investing time and resources in it. Guice will always have a superset of features compared to Dagger, though we do have projects using Dagger on the server and in stand-alone java apps. But Dagger is not as evolved in terms of the surrounding "scaffolding" code (servlet support, etc.) as Guice, and won’t be for quite some time. Additionally, some teams will need or want some advanced Guice features that will never make it in to Dagger. [1]

[1] http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_go...

pron10• 12 years ago

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

peterarmstrong2• 12 years ago

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)

jebblue4• 12 years ago

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.

edwinnathaniel2• 12 years ago

Speed is not the only concern when it comes to JDBC vs ORM (JPA/Hibernate).

The more complex the data model, the more one needs to know the inner working of JPA. I've shared my struggle understanding how JPA works even for a medium-level complexity of the JPA entities.

Some of the problems I've encountered using JPA:

- The whole EntityManager act as L1 cache occasionally tripped me when writing Integration-Tests

- The relationship direction (owning, etc) can be confusing to learn

- Reference vs Lazy vs Eager load

Having said that, HBM2DDL is a nice tool that can work as maven plugin such that changes on the JPA entities can resulted the DDL to be updated properly thus maintaining consistency between Java Data Model and the DB schema.

JustSomeNobody• 12 years ago

Thankfully I am seeing more and more comments like this. I really think we off the deep end with all this. Simple is key.

EdwardDiego8• 12 years ago

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

pjmlp28• 12 years ago

Back in 2007 we had a developer pissing one architect as he replaced a few J2EE 1.3 entity beans by pure JDBC calls.

The modified code ran in a fraction of the time the pure architecture was running.

craigching• 12 years ago

My preference for DI is Declarative Services in OSGi. OSGi is a nice specification for creating modular Java systems.

osi• 12 years ago

i've seen a resurgence of 'new'

bsaul2• 12 years ago

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 single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.

twistedpair2• 12 years ago

How's Play! compare to Spring? I'm working on a bloated Spring whale (1.5M LoC, 485 Spring XML config files) and wondering if something like Play! can do it better, or if complexity is simply a beast that will inevitably turn any project into a turgid mass.

I ask since friends at Google will laugh at a bar if you even say "Spring," but I'm curious what else can do it all (Guice/Gin?). Perhaps nothing can and the trick is to simply have small, cohesive projects linked by common REST (et al) API's and to merely skirt complexity entirely. However, for workflow and state management, you'll inevitably need some common integration point.

pdevr• 12 years ago

Not sure what version of Spring you are using, but the newer versions allow you to annotate your way out of the need to have so many XML files.

Code bloat is a different beast. Unless the company decides to refactor and redesign the whole thing, you probably have to live with it, like the rest of us.

ramkalari• 12 years ago

Play is simpler compared to Spring but idiomatic Play code also requires you to learn reactive programming, something you probably won't do in Spring MVC.

neverminder• 12 years ago

I while ago I had to choose a JVM based MVC framework to work with and originally I was looking at Spring. Needless to say it's a Mount Everest of frameworks, so by looking for alternatives I've stumbled upon Play. I decided to go the whole way and use Scala with it. Never looked back since. Typesafe stack offered me a rock solid Scala/Play/Akka/Slick stack with type safety, scalability, immutability, concurency that few others have (if any).

umut5• 12 years ago

I can strongly recommend Dropwizard for the plan. It is much less stuffy/enterprisy and you can easily split big apps into smaller services. It is some glue code on top of Jersey run in embedded mode Jetty (thus very little ops work needed). Play Framework is also nice, but a bit too much opinionated! Meaning hard to make it do something in another way, which happens in real world big applications...

andyroid• 12 years ago

I did a side project in Play! some time ago. While it was generally OK to use, Java in Play is definitely a second class citizen compared to Scala. Most documentation (which btw is sorely lacking) concerns how to do stuff with Scala and you'll have to figure out how to do the same in Java yourself.

Even worse, breaking backwards compatibility between even minor releases seems to be standard for this framework. So once you've finally managed to find some piece of documentation from some random source on the net (as again, the official documentation is pretty much a joke) you'll find that it doesn't work at all because it was written with Play! 2.0 in mind which is different from 2.1 which is different from 2.2 and so on.

Once you figure it out, it's a pretty nice framework. It's a shame so little attention seems to be paid to exposing that in a better fashion.

lmm16• 12 years ago

Spring is a huge umbrella project that contains many parts, some good, some not so good. Guice or picocontainer work well, but you can achieve the same effect by using spring's Java configuration and avoiding silly things (AOP, shudder), and that way you can migrate existing spring XML piece by piece.

If you're writing an actual webapp (i.e. something that outputs html) then I highly recommend Wicket; it's the most beautiful framework I've ever used, in any language. If it's just REST APIs I can't really recommend anything - by the time I started writing those I'd switched to Scala (in which Spray is wonderful).

ishbits• 12 years ago

Modern Spring is quite nice, and after having tried Play, I go back to Spring MVC, but use Spring-Boot with Jetty was the embedded container.

Its much like Dropwizard, but better integrated with Spring if that is what you are used to or like.

No XML, and I can produce a usable web API with a minimal amount of boiler plate (its all wrapped up in Spring boot, much like Play wraps up a lot of stuff for you).

kitd• 12 years ago

Guice and SiteBricks [1] work very well together.

[1] http://sitebricks.org/

grkvlt• 12 years ago

Note that Play is only really comparable to Spring MVC, it's not a general-purpose dependency-injection framework. In the DI space Guice is more of a competitor to Spring.

Consultant32452• 12 years ago

I kind of like that things are standardized/regulated in the Java space. If you're using anything close to industry standard tools and methodologies I can come in and be an effective member of your team faster. I know it can sometimes be more exciting to build something in a way no one else has ever built it before, but it's usually a bad business decision to do so.

This is one of the reasons why I still lament javascript. It seems like everyone and their mother is using a different framework to accomplish essentially the same task. The flavor of the week last exactly that long: a week.

turar3• 12 years ago

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 some sort. I mean, WTF, is this really the "idiomatic" way to build Spring REST/MVC projects nowadays? I'm trying Dropwizard for now.

Omnipresent• 12 years ago

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

mahmud• 12 years ago

Been there done that. 3.5 years of Play 1, but they decided to rewrite it in Scala and I left in anger.

Nearly one year now of servlet dev, trying nearly anything I can get my hands on. Most I have been satisfied with is Restlet for service development, otherwise nothing even comes close to Play 1.

Finally decided to harden up and learn Scala. I have set my prejudices aside and after a month, I can safely say I am a _write_only_ Scala developer. I still can't read much of the fancy code in the wild, but for my immediate needs, gluing java libraries together, it's a far superior language to Java.

My opinionated guide to developing modern Java is: get TypeSafe Activator and learn Scala.

nl3• 12 years ago

Dropwizard is very nice. Can't comment on Play.

tkubacki• 12 years ago

I'm using Dropwizard and it was easy enough for me - former .NET developer to get things done quickly. That said if I was starting today long term project I would go with Dartlang (yes they'are server side as well)

mschulze2• 12 years ago

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.

yawz• 12 years ago

The problem lies more in bloated frameworks...

How ironic... I was an early adopter of Spring, when it was all about simple "enterprise development without J2EE". So, given enough time, does bloat follow success and does it become inevitable?

userbinator• 12 years ago

I think that to a certain extent, the standard library also encourages this culture, since that's the most prominent and arguably widely used piece of software that's written in Java and it will be used as an example of "good" code.

The continuing notion that CS classes teach objects first (I've heard recommendations that it be before even conditionals and loops, shockingly enough) I think is also a contributing factor: "When all you have are classes, everything turns into an object."

But as things like Java4K suggest, the bloat may not be inherent in the language itself; it's certainly possible to write concise, efficient Java code.

monkmartinez• 12 years ago

I have come full circle in a way. I started learning Java in school and built a few, small things for Android and the desktop. Then I was "all like;" I am going to learn the hotness which was(is?) Node. Node is what it is and I didn't really care for it. Then I moved on to Python and I really like it. Python is awesome for many, many things but GUI applications are not one of them. I have since returned to some Android development and I am diving into a CRUD web app in Java. Simple stuff, but it needs to be fast.

Looking forward to part 2 and more!

ryanobjc6• 12 years ago

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!

a8da6b0c91d2• 12 years ago

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.

TillE• 12 years ago

You still have to read Effective C++ to avoid shooting yourself in the foot, but after that C++ isn't much more difficult than Java or C#. The compile times remain annoying, though.

UK-AL5• 12 years ago

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.

pjmlp28• 12 years ago

C++11/14 is in practice not that much more difficult to write well than Java. It's not 1998 anymore.

While I agree with you and C++ belongs to my favorite languages, the truth is that most corporations still use C++98/C++03 and they aren't going to improve their compilers any time soon.

On our Java projects we still get requests for Java 1.4.

The enterprise is a very slow moving snail.

zenbowman4• 12 years ago

Exactly. I'd argue C++ has a lot going for it, and I think the claim that Java's performance is only slightly slower is simply not true for the vast majority of situations where good memory organization can provide significant speedups - which includes any computer graphics, vision or audio application.

I personally find C++11 more high-level than Java and significantly more optimizable for performance.

You can wax poetic about "developer time is more important than processor time" all you like, but when your application runs like a turtle on anything short of server-class hardware, it doesn't mean much.

Performance will always be of primary importance for a large class of applications. For the rest, Java is a good alternative.

ryanobjc6• 12 years ago

Having spent 5 years doing production C++, I don't believe you basically.

All that shit that sucked in 2005 about C++ is still in there. It's just up to your discipline to not use it.

Do you trust your coworkers enough?

cwufbt08• 12 years ago

In what way is Java a "dynamic language" ?

escaped_hn• 12 years ago

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

shellac• 12 years ago

I think "dynamic platform" would be more accurate. Java has typically been a fairly conservative language sat on a much more interesting VM, a VM which has rather more features in common with dynamic languages like Smalltalk than you'd expect.

ryanobjc6• 12 years ago

Java has a lot of runtime knowledge about itself, it can do a lot with that.

As a result, you see things in Java that are more typical of dynamic languages, rather than C++ for example.

zmmmmm4• 12 years ago

Contrary to popular belief Java is highly dynamic. You can introspect the fields, methods, interfaces of any object at runtime, inject new / redefine classes, methods, fields, etc. The problem is that it's very awkward and unwieldy to do so. Hence the tendency to build new JVM languages rather than attempt to use Java's dynamic features directly.

zak_mc_kracken3• 12 years ago

"Dynamic language" != "Dynamically typed language".

kodablah• 12 years ago

One of my opinions these days on javadoc is that you should be minimalist. Have nothing to say about the return type? Don't add @return. Same for @param. Just a sentence about the method/field/class? Just a single line /* * ... */ is fine. Have nothing of value to say on a method/field/class (e.g. a getter), don't add javadoc at all. I'm growing weary of large files with tons of redundant javadoc lines to make some checkstyle/pmd rule happy.

nollidge2• 12 years ago

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.

AnimalMuppet2• 12 years ago

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.

benjaminpv2• 12 years ago

Seconded.

I always bristle when I see javadocs that include things like 'returns an object of [x] type that...' You're dealing with strong types, the signature provides all this information already. That, combined with good variable names, should do a lot of the documentation for you.

If you wanna document a method, document what problem it solves. Document any gotchas (or better yet, redesign them out o_~). Don't just repeat what reading the method's signature already tells me.

bananas6• 12 years ago

That pisses me off but the following is much worse. The commit comment that goes:

"checked in abstract_class.cpp"

Duh!

tieTYT6• 12 years ago

Yet, I'm always surprised in how good the official javadoc is at avoiding this problem. They always have a @return and it's usually saying something useful. I think there's two situations:

1) You're writing javadoc for something that isn't really a public facing api. In that case, I agree, remove the @return. Perhaps even remove that / * * and convert it to / *. It shouldn't be officially documented.

2) It is public facing api. It may seem that the @return is redundant, but there's really a better way to document it.

lomnakkus5• 12 years ago

Thirded. At my last place of employment I actually made this into an informal[0] coding style rule and succeeded in getting a few people to remove the completely useless default javadoc template which Eclipse (and the like) have for new methods.

One thing I did find very important was to document if your method had any side effects that were not obvious from just its name. (E.g. if a method is called printXXX() or logXXX() you can pretty much guess what it's going to do, but saveXXX() is a little bit more ambiguous. Where is it going to save things? The database? The file system? Is it atomic? Etc.)

[0] I don't believe in formal coding styles (at least not for small teams/orgs) since what constitutes "best" practice is always context-dependent. We handled all knowledge transfer (including coding style) by intra-team code review and a few very high-level documents about the overall system architecture.

levosmetalo2• 12 years ago

I've been guilty of that kind of comments you despise when I had to work in environments where software "quality" metrics were applied to all checked in code as a part of build process and your code was marked as "low quality" because you missed @return document entry in your Javadoc. You can bet that, with few IDE templates to autogenerate all missing JavaDoc on save my metric was quite good. In addition to that, I completely stopped trying to write good docs. What you measure is what you get in the end.

DennisP• 12 years ago

The position of things like Netty and Undertow at the top of the techempower benchmarks has me a little intrigued. How much hassle is it to write websites with servlets like that?

pron10• 12 years ago

A bit of a hassle, but Comsat will make it dead-easy (right now Comsat runs on top of any servlet container, but it will also run directly on top of Netty/Undertow). Take a look at our Comsat web actors: http://blog.paralleluniverse.co/2014/01/28/web-actors-1/

bhauer• 12 years ago

Undertow provides a Servlet container, so if you are already using a Servlet-based framework, the level of effort is fairly minimal. Though, Resin remains a very high-performance Servlet container as well in our benchmarks and if you need a broad set of Servlet features, Resin may be a better fit.

Another option is WildFly, which is the new JBoss application server that uses Undertow below the hood.

We are presently adapting our in-house framework to use Undertow natively (without the Servlet layer) and the effort to do so has been low, all things considered. If you're comfortably working with the internals of your framework, you may be able to do the same without a great deal of pain.

lmm16• 12 years ago

I've had a great experience building web APIs (i.e. returning JSON rather than HTML) in Scala with Spray; it requires you to think a bit more about when things happen (because everything is async), but it's lovely and smooth to use (there's this routing configuration DSL that looks almost like a config file, but then you realize it's all Scala so you can use things like for/yield with it).

In terms of actual websites I understand Play is migrating to run on top of Spray, but I'm not aware of any mature frameworks for doing it right now.

java-lang2• 12 years ago

It is easy to write performant web applications without servlets using Vert.x which is also based on Netty. It also scored highly in the benchmarks.

agibsonccc4• 12 years ago

It's ironic, I'm slowly trying to move my development over to scala. I'll likely integrate gradle in to my stack (still use maven =/ mainly because I know all of its weird quirks)

What have people's experiences with gradle been? I'm not a huge fan of groovy hence why I stayed away from it.

bpodgursky• 12 years ago

IMO Gradle has made huge improvements the past couple years (when I first started using it a few years ago it was incredibly unstable) but if you are a semi-power user of Maven I think you're going to find yourself frustrated using gradle still for a couple reasons (I've looked into this for my work recently, moving away from Ivy). Note I haven't extensively used Gradle, this is just from research:

- Intellij has incredible Maven support, and by this point almost all the bugs have been worked out. Gradle support is improving, but our company has dozens of modules, a mix of Java / Clojure source code, and depends heavily on Intellij automatic source linking working correctly, dependency propagation working 100% successfully, etc, and it's really easy for small bugs to become blockers. Last I checked there were still a number of pretty frustrating bugs related to this

- The Jenkins maven plugin is great, and the Gradle one is mediocre. For example, it does not even handle automatic triggering of downstream builds (this is absolutely critical for us https://issues.jenkins-ci.org/browse/JENKINS-19941)

- Gradle pretty decent plugin support by now, but is not yet as exhaustive as what you'll find with Maven (there's a maven plugin for basically everything now)

- This may have been resolved, but I had issues configuring getting Gradle to update snapshot dependencies, which was really important to us.

In the end I decided to migrate to Maven to avoid these headaches. I think I will try to use Gradle for personal projects, but I don't feel comfortable migrating our company stack there yet.

agibsonccc4• 12 years ago

Really appreciate the insight, this is what I have found as well. Especially using intellij, it's still hard to beat. I'm always on the look out to use new stuff, but I'd rather wait a bit..

If I go hybrid JVM, I will likely just use SBT instead.. I think I'll keep an eye on gradle and see if it matures though.

One of the reasons I still use maven is like what you mentioned: the tooling, I don't find myself using xml most of the time (despite knowing it like the back of my hand anyways)

twic4• 12 years ago

I like Gradle a lot. The build scripts are easy to read, and it's really easy to write nice plugins.

That said, my Scala-using colleagues are unanimously agreed that SBT is the way to build Scala projects. I suspect that some of that is purely about being fashionable, but there are certainly a few things you need to do with Scala (like handling the Scala version as part of artifact coordinates) that SBT does naturally that Gradle doesn't.

zwieback• 12 years ago

I'm using Java for the first time because of Android. I had played with Java when it first came out but have stayed with C/C++/C# for almost everything.

I have to say that my Java experience isn't as unpleasant as I thought it would be. I always thought C# is what Java should have been but after learning a little idiomatic Java the reality is quite okay, really.

nmjohn• 12 years ago

The way you phrased that sounds to me like you've been programming for a significant amount of time. If that is the case, the Java of today offers so much that a younger Java did not, and I suspect you would have had a more unpleasant with the java of 10 years ago.

kasey_junk• 12 years ago

In a lot of ways C# is still a much superior language than Java, but the JVM (I'm thinking HotSpot) is tremendously better than the CLR.

pjmlp28• 12 years ago

I follow Grail and now Truffle development since the days of the Maxime VM.

Looking forward to the day the reference JVM becomes a meta-circular one.

peterashford• 12 years ago

Anyone looking at where "enterprise" Java went - the whole J2EE monstrosity - would have run screaming. But the basic language is actually quite good and has been for a long time.

cpprototypes2• 12 years ago

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 (streams) and others. Dalvik was based on Apache Harmony which is a dead project and will never get the Java 8 API changes implemented. Does anyone know if Google is going to do something about Java 8 and Android?

eloisant• 12 years ago

There's always been some fragmentation between Dalvik and "real" Java. A lot of libraries don't work out of the box on Android.

spullara7• 12 years ago

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.

_pmf_• 12 years ago

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

pjmlp28• 12 years ago

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.

icebraining• 12 years ago

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.

jayd163• 12 years ago

Forked != out of date. Android code is still Java code. you just compile to Dalvik bytecode instead of jvm bytecode.

If you think that's wrong, fine but that lawsuit had nothing to do with bytecode.

mhaymo• 12 years ago

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.

cpprototypes2• 12 years ago

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.

pjmlp28• 12 years ago

If you target only KitKat and don't mind missing some of the Java 7 new APIs.

higherpurpose• 12 years ago

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.

pjmlp28• 12 years ago

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.

jayd163• 12 years ago

Especially since Google hasn't updated its Java language much lately

Yes it has. They recently added Java 7 language support.

mncolinlee2• 12 years ago

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

pjmlp28• 12 years ago

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.

clumsysmurf• 12 years ago

> Official, default support is coming soon.

Default support of ART or Java 8?

If Java 8, how do you know this? Citation needed ;)

izacus5• 12 years ago

Hmm, what you write makes no sense.... even if Google would use Oracle Java, we'd still be stuck with devices running Java 1.6 JVMs.

Having a different implementation doesn't change the limitations imposed by out of date VM running on a device.

spullara7• 12 years ago

Why would they run 1.6 JVMs? Why wouldn't they run the latest?

donniezazen2• 12 years ago

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.

izacus5• 12 years ago

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

pnathan2• 12 years ago

I appreciate the modern Java style espoused here, it's much further away from the horrible overdesigned & pointless configuration style I often see with Java.

However, the author doesn't really understand why C++ and dismisses it quickly. The short answer is C++ gives control and abstraction on demand, an unusual combination. Java trades control in exchange for GC.

pjmlp28• 12 years ago

The short answer is C++ gives control and abstraction on demand, an unusual combination.

Ada, Modula-3, the Oberon language family as well.

But they lacked a proper OS vendor support and faded away.

Ada seems to be raising up, thanks to GNAT and continuous security issues with C and C++. At least from its increasing presence at FOSDEM.

pnathan2• 12 years ago

Well, yes. And more than a few other languages that got left in the dustbin of our history. But as for today...

I actually am personally very keen on seeing where Rust goes here, but it isn't 1.0 yet (which will be the signal for me to start writing in it seriously ).

benjaminpv2• 12 years ago

Ironically the Java ecosystem could stand to use some garbage collection of its own: there's a ton of old, outdated info out there that both colors people's impressions of the language and teaches new players a whole manner of bad habits. I appreciate what this article's going for and hope there'll be follow-ups.

I use Java daily and though there's undoubtedly room for improvement (I'm looking forward to when tooling better supports stuff added in Java 8), I think a lot of the negativity that surrounds it is undeserved. There's definitely bloated XML-infested frameworks out there but the core's a real workhorse.

Terr_5• 12 years ago

old, outdated info out there

I'd love it if the JDK had a "learner mode" that disabled interned string literals. Then newbies experimenting with `assert(str1 == str2)` wouldn't leap to false conclusions.

lmm16• 12 years ago

== should never have been used for that method, which is very rarely what you want. The right thing is probably to deprecate == on nonprimitive types, replacing it with a longer name that's clearer about what it means.

pjmlp28• 12 years ago

Some pruning is planned for Java 9, at least is was announced so at Java One last year.

twic4• 12 years ago

It's not just the JDK that needs pruning, though. It's the ecosystem of third party libraries, and the millions of pages on blogs and StackOverflow (and shudder JavaRanch) that contain bad, outdated advice, following which will make people hate Java.

lmm16• 12 years ago

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 declarative and all the tools understand it. Learning a new language just to configure your build tool seems excessive.

exabrial2• 12 years ago

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.

karlmdavis• 12 years ago

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

sztanko• 12 years ago

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

lmm16• 12 years ago

Until you have to debug it. At which point you realise you're now writing what's effectively a different language with its own tooling and compilation (and its own bugs), and if you were going to do that then you might as well go all the way to Scala where you get much more in return.

arel• 12 years ago

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

emsy6• 12 years ago

For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.

lmm16• 12 years ago

For starters, you can see Groovy as "Java without semicolons"

Not if you have to read other people's code, or understand examples you find on the internet.

I went from Maven to Gradle and never looked back. It's superior in most ways.

What's it better at? I want my build tool to be simple; maven compiles my source and does my releases, and the main thing I have to configure is just a list of dependencies (in an admittedly verbose format). I'm actually a scala programmer, but I use maven rather than SBT because it seems to me that having lots of logic in the build system could only lead to bad things. So what are the things you see it helping with?

vorg5• 12 years ago

you can see Groovy as "Java without semicolons"

Only a very small subset of Groovy is used by the typical Gradle build script, the very subset of Groovy that's least like Java. What part of this build script from the linked article bears any resemblance to Java?...

  apply plugin: 'java'
  apply plugin: 'application'

  sourceCompatibility = '1.8'
  mainClassName = 'jmodern.Main'

  repositories {
    mavenCentral()
  }

  dependencies {
    compile 'com.google.guava:guava:17.0'
    testCompile 'junit:junit:4.11' // A dependency for a test framework.
  }

  run {
    systemProperty 'jmodern.name', 'Jack'
  }

  javadoc.options {
    docletpath = configurations.markdownDoclet.files.asType(List) // gradle should relly make this simpler
    doclet = "ch.raffael.doclets.pegdown.PegdownDoclet"
    addStringOption("parse-timeout", "10")
  }

  run {
    jvmArgs "-javaagent:${configurations.quasar.iterator().next()}" // gradle should make this simpler, too
  }

zak_mc_kracken3• 12 years ago

you can see Groovy as "Java without semicolons

I see it as "Java without types", myself.

I'm aware that Groovy now supports optional typing but if I'm going this path, I prefer to switch to Kotlin, which I describe as "Java with everything that's bad removed".

levosmetalo2• 12 years ago

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.

mschulze2• 12 years ago

I used Lombok in a Java 8 project without problems.

umut5• 12 years ago

Couldn't agree more.. But this comes with the most cliche discussion with a smartass looking at your code. Dude, I know what getters and setters are, I just don't agree

laureny2• 12 years ago

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.

venomsnake• 12 years ago

Dependency injection and any othee type of code indirection is evil imo. Anything that breaks the ability to find your way in a codebase with something other than grep brings more pain in the long run than it saves.

Terr_5• 12 years ago

the ability to find your way in a codebase

It's a tradeoff between two different kinds of clarity. Yes, it's harder to see the "whole wiring" without better tools...

But it makes small, encapsulated classes much easier to reason about and develop! You can focus on assuring: "My `Foo` can interact with a supplied `Bar`" rather than dealing with all sorts of crap about what implementation of `Bar` it gets or how that `Bar` instance is configured.

rat872• 12 years ago

grep is a that good even for for c++ or dynamic mojo. Java is statically typed and has many ides and tools that understand code structure.

maaaats• 12 years ago

Just grep for "extends InterfaceBeingUsed" and you'll find the implementation just fine.

revscat2• 12 years ago

Dependency injection has seen its day. The gains promised by DI/IoC containers tend to be outweighed by the complexity they introduce.

I'm looking at you, Spring.

laureny2• 12 years ago

Spring's DI is terrible but Guice (and on mobile, Dagger) is really easy to work with, statically typed and has increased the maintainability and testability of our code base tremendously.

UK-AL5• 12 years ago

Adding @Inject is hard now?

Most DI frameworks automatically configure, and register objects. So literally all you need to add is the annotation.

Then you can override the automatic registration with you own, with different implementation when required.

altcognito2• 12 years ago

DI is fine, it's just the way people overuse it that's an abomination. I general inject the most significant pieces, or the pieces that are changed. I won't even introduce DI unless I know I'm going to setup a different config of it. My coworkers (sigh), insist that nearly everything must be injected to "eliminate dependencies". (and because it makes it "easier to test"). YMMV

pron10• 12 years ago

Coming up in part 3, where we discuss http services.

quotemstr• 12 years ago

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.

EdwardDiego8• 12 years ago

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)

tieTYT6• 12 years ago

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.

pjmlp28• 12 years ago

Gradle is mainly being pushed by Grails and Android development.

I don't know of any other project using it. We are always doing Maven or Ant.

If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.

pron10• 12 years ago

https://github.com/search?q=gradle&type=Code&ref=searchresul...

I also know that Netflix use Gradle for pretty much all their Java stuff.

revscat2• 12 years ago

Southwest Airlines uses it.

sadris• 12 years ago

And Minecraft Forge.

eeperson7• 12 years ago

Is Grails really pushing Gradle adoption? My experience has always been that the integration between the two is pretty bad. Are things better now that they finally... released a real Gradle plugin to support Grails 2?

elchief2• 12 years ago

Spring is pushing it hard in all their new tutorials, even non-Grails. Which annoys the heck outta this Maven guy.

vanilla• 12 years ago

libGDX (cross plattform game lib.) also made a push to gradle

vorg5• 12 years ago

I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling

That could be the slow, dynamically-typed Groovy in Gradle that's dragging your machine. Gradle needs to bundle another build language. Since the goal of statically-typed (and hence speedier) Kotlin is to make it easier to write IntelliJ IDEA [1], on which Android Studio is built, instead of using Java, the logical choice is Kotlin.

Gradle's developer says they'll happily support any community effort to create additional build script engines other than Groovy, but it isn't a priority for them right now [2]. Perhaps the Kotlin team need to kick off a Kotlin build engine for Gradle (though because one of the Kotlin developers was a victim of the Groovy++ fiasco, I'd understand if the Kotlin people are hesitant about having anything more to do with Groovy ecosystem software like Gradle).

[1] http://blog.lunatech.com/2011/08/24/scala-ceylon-kotlin-goal...

[2] http://www.gradle.org/overview

pron10• 12 years ago

Specifying the dependency in Maven XML has become sort of a standard that even Gradle people use. Obviously, Maven has been around much, much longer, and a lot more people are still using it, but more and more are switching to Gradle. At the very least Gradle has come to a point that you don't have to worry about it not being maintained, or that there won't be people to ask if you've got a question.

bananas6• 12 years ago

This. I can't see myself using Gradle any time soon. Literally everything I've touched is maven only and I don't want to learn another DSL on top of yet another language.

smrtinsert4• 12 years ago

There are no winners in the build war despite the overwhelming online support for Gradle. Personally I'm not a fan of it. I find it on the slow side even compared to maven. I'd rather have declarative builds like Ant but therefore support better tooling than super freeform tools like Gradle that force you to drop into a language with about as much type safety as Javascript. Multi-project builds are also annoying, as Gradle has to parse and validate all the connected projects before proceeding with one single task on the build you're invoking due to its design. Very annoying stuff.

tieTYT6• 12 years ago

I'd rather have declarative builds like Ant

Is that a typo? I'd say Ant is the opposite of declarative.

oldmanjay• 12 years ago

I've definitely found gradle to be faster than maven, particularly using the daemon, and even more so considering the extensive support for understanding when a task is up-to-date. I haven't run a clean task in gradle in several months, but in maven it seemed to be a crapshoot if the clean was required or not. That saves a lot of time.

eeperson7• 12 years ago

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

[0] http://www.scala-sbt.org/ [1] - https://github.com/sbt/sbt/wiki/Client-server-split

jayd163• 12 years ago

You should be skeptical. Many Android projects don't use Gradle. Gradle itself might be stable but Gradle issues are at the top of every single Android Studio release notes.

When that stops happening I'll start thinking about Gradle.

EdwardDiego8• 12 years ago

Yep, Maven is the defacto AFAICT. But so is Java 6 currently.

java-lang2• 12 years ago

I'm a little skeptical of this.

The title did warn that it is an opinionated guide.

I think most projects that used Maven before Gradle don't have enough incentive to migrate. A lot of the new projects, however, start out with gradle: Vert.x, Crate.io, RxJava.

pswenson8• 12 years ago

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 going on. Using a debugger would be nice, but it simply doesn't work. Gradle is terribly slow on a big project, the update checks are the main culprit. They should be done automatically in the background to alleviate this pain.

Since gradle is compiled rather than interpreted, calling code in the project being built is difficult and convoluted. For example, if I want to call a DBUtil.cleanDB() method in my java code I can't reference DBUtil in my gradle script as it hasn't been built yet and the Gradle script won't compile. If gradle was interpreted this problem wouldn't exist....

I find the DSL unintuitive and the inability to specify the order of tasks execution is always a sore point.

On the positive, at least it's a language, not XML. I have never understood the java world's obsession with XML and forcing it in directions never intended. This XML obsession has led to java being a major laggard in automation tech. Java devs do many things manually that a Ruby/Python dev would be horrified at....

tieTYT6• 12 years ago

Maven also suffers from XML hell, but at least it has dependency management.

I don't find it that bad. The nice thing about it is how my IDE will auto complete almost everything and it should be possible to validate it without even using an IDE, as it has a schema. I agree with your complaints about Ant.

The thing I was hoping gradle would give me is the ability to write tests for my build. EG: I want to have more confidence that my maven filtering is working the way I want it to. But it sounds like gradle isn't built with that in mind.

Considering that groovy is dynamically typed, if my IDE doesn't auto complete (maybe it does) I think it's possible to make the argument that Maven is the least awful of the 3. At least the maven XML has a schema. I don't need yet another way to make a mistake in my build script (ie: typing issues).

Java devs do many things manually that a Ruby/Python dev would be horrified at....

Such as?

izacus5• 12 years ago

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 IDE's was orders of magnitude faster with Mvn than with Gradle... all in all setting up all the components with gradle took about 2-3x as much time. Mostly it seems like someone decided that because now you have code instead of XML for build configuration, they'll just skip most of the plugin design and force you to roll half of the build process on your own.

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.

ryanobjc6• 12 years ago

Ah see I know you aren't an intellij user because your "XML hell" comment makes no sense.

IntelliJ makes this a breeze. I'm sorry you aren't using it, that must make life really hard :-(

nvarsj2• 12 years ago

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

smrtinsert4• 12 years ago

Declarative builds = intelligent tooling. Would json make it better? I hate editing json too. Personally I would go with toml but wait... that would look similar to something else...

Ant's real problem is that it never found a path towards next generation. Why isn't ivy included by default? I want something bigger and easier to use that isnt gradle or maven but is more along the lines of an Ant+ivy default. It should have a bootstrap script, it should understand default project directories... It should continue to be declarative, but it should have an xsd or similar descriptive format that can be used for tooling.

There is a future in the ant+ivy perspective that I don't see in other build tools.

leorocky2• 12 years ago

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 horrible thing about these threads in Java is how hard it is to not share memory across them, because if you do terrible things happen. In other platforms you don't have to involve threads unless you want to, and you definitely aren't boxed into a situation where it becomes easy to accidentally share memory across theads.

I like Go's way of handling this. node.js is single threaded but the event loop makes it possible to do non-blocking IO without crazy Jave thread issues. Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.

That gets me to my other pet peeve with Java. Just how much boiler plate there is to do basic things like opening up encrypted TLS TCP connections. Tons of cruft.

Anyway, having said that, I love Java and use it, but these things need addressing. I like Scala's Akka, I hope Java comes around and improves the horrible thread situation. I will have to check out Quasar. I know I just need to become more familiar with threading in Java in general. I'm actually pretty new to Java.

stcredzero• 12 years ago

Using synchronized, atomic properties and locks is not the right way to do these things as your code gets really complicated when trying to do basic things.

One point being made in the op is that you don't have to. Of course, you may be constrained by how the libraries you want to use are structured, but I don't think this is necessarily the case. What if you used the op author's actor framework?

dk8996• 12 years ago

There is nothing wrong with Java Threads, it gives you low-level access which can be complicated and cumbersome but, when mastered, can be powerful. I believe that Akka uses Java Threads underneath the covers.

Terr_5• 12 years ago

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.

twic4• 12 years ago

There's plenty of stuff like this, though, in the JDK and in third-party libraries. Think about how much effort it takes to read the contents of a file into a string!

I don't think this is a fatal flaw, just a reflection of the attitudes and priorities the founders of Java. Concision for small tasks just wasn't seen as important. I don't think it was until the generation of scripting languages like Python and Ruby (and that other one, the moustache guy's one) came along that benefits of having a comfortable raft of easy ways to do small things became clear.

Java is far and away my favourite language, but even i'm embarrassed that it took until Java 7 to get a standard way to compare two possibly null variables for equality.

agibsonccc4• 12 years ago

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.

ww520• 12 years ago

Sounds like it's the implementation of the audio library using thread in the wrong way. Has nothing to do with threading in Java. Nodes could have the problem of starving the audio playback if other parts of your code hogging too long of processing time. It's just shifting the problem around.

leorocky2• 12 years ago

I'm not using an audio library. I'm just using Clip and AudioInputStream

pron10• 12 years ago

Go makes it even harder not to share mutable memory, as it has no 'final'. But if you read the whole article you'll see that Java now has lightweight threads with cheap blocking - just like Go or Erlang.

tieTYT6• 12 years ago

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.

steveklabnik• 12 years ago

It's certainly a bit strange, but it's how Scala works as well. I wonder if it's for backwards compatibility reasons, given that everything is nullable already. Have to give it more thought though.

the_af9• 12 years ago

Indeed, Option in Scala has the same problem. I understand null is needed for backwards compatibility, but it makes Option the poor man's Maybe...

peeters• 12 years ago

There are a number of implementations of JSR 305 (https://jcp.org/en/jsr/detail?id=305). Findbugs is one that provides the annotations. You can include the annotations JAR file on your compile path and then use findbugs in your build to enforce them. IntelliJ will still recognize them and flag the warnings/errors.

kazagistar2• 12 years ago

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 other way, like how "final" is enforced in the constructor, but it should be possible.

Unless you make it default, though, it won't be as "elegant" as the haskell Maybe, and doing so would net you a very very different language.

pjmlp28• 12 years ago

Outside the JVM world, Eiffel does it.

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

strictfp• 12 years ago

You can at least add runtime assertions automatically with jwtbrains annotation processor (maven plugin). I don't know about compiler errors,

kyberias2• 12 years ago

Why do people seem to think "opinionated" is a virtue these days?

zenbowman4• 12 years ago

An excellent question.

Opinionated: conceitedly assertive and dogmatic in one's opinions.

It generally refers to people who assert their opinion without making a sound argument for it. I consider it a huge negative.

Another vice that many consider a virtue is when they consider themselves to be "real" - this is generally code for lacking any self-discipline and being unable to control emotion.

lmm16• 12 years ago

Because, particularly in Java-land, if you're not opinionated you end up providing a FactoryFactoryFactory. A beginner is in no position to weigh up the pros and cons of the different build tools available, so it's better for a guide to simply make a recommendation and explain that one than to give the beginner a confusing choice.

Daishiman• 12 years ago

Two reasons that come to mind:

- Java is such a massive ecosystem that you need someone to guide you through the complexity and to show you the diamonds among the piles of dung.

- You're being honest. Really, my impression of Java has been so bad because of people that want "industry standard" and "enterprise" things that I welcome fresh perspectives from people in the field. Ultimately, if someone points out that a certain statement is they own opinion it's easier for you to judge it in a broader context, so even if you still disagree you don't feel like you're being misled.

kazagistar2• 12 years ago

Its better to have one opinion then ten conflicting ones. Its also easier to learn how to do something from an opinionated source then one that tells you to do "whatever you want", without providing you with good ways of evaluating the choices and intelligent defaults.

jebblue4• 12 years ago

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 Subversion, git for Git, etc. Use the workspace as just a shell to manage Eclipse preferences and such.

bradleyjg3• 12 years ago

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.

jebblue4• 12 years ago

Sorry no link, co-workers and as "smrtinsert" said, Git or for me having both Git and Subversion projects makes life easier keeping source separate from the workspace.

smrtinsert4• 12 years ago

I do this, or have started to since I've been using git more. I also do it with large projects. Only my truly disposable projects are in the workspace.

agibsonccc4• 12 years ago

I finally switched off of eclipse for intellij. It's light years ahead of eclipse in terms of speed and response times.

One of the things I liked was how easy it made things by allowing eclipse keybindings to be used. Ever since I enabled those, things have worked exactly the way I would expect.

I also like the work flow with git. A common example I like is the prompt for adding files to your repo automatically upon creation, this way I don't have to think too much about it.

Just my 2c as an eclipse user converted.

Terr_5• 12 years ago

Something that really resonates with me from the linked PDF ("Blue-collar language") published in 1997:

What I found most interesting in watching people use Java was that they used it in a way similar to rapid prototyping languages. They just whacked something together. I was initially surprised by that, because Java is a very strongly typed system, and dynamic typing is often considered one of the real requirements of a rapid prototyping environment. [...] you find out fast when something goes wrong.

Despite working in JS and Python, sometimes I feel more comfortable hacking something up in Java, because every missing method or undefined variable is an unavoidable short-term TODO.

eranation2• 12 years ago

But enough writing Go in Java. Let’s try Erlang.

Nice

cs02rm0• 12 years ago

Quasar is an open-source library made by us

Quite enjoyed the article until that got jammed in there.

anthonye2• 12 years ago

Modern Guide to Java... using our tools.

wil4213• 12 years ago

But the modern Java developer uses Gradle...there are quite a few things that are quite, though not very, common, but still require dropping down to imperative Groovy.

This is the first time I have heard of Gradle, but why would I use a build tool that requires me to learn Groovy. If I already know Java I wont be learning something new just to build a Java project.

I find a lot of development tools/frameworks make me learn B just to get started with A, its really frustrating for someone with limited experience IMHO.

nsxwolf• 12 years ago

I wouldn't say you need to actually learn Groovy to get going with Gradle. The example build.gradle files are fairly self-documenting, and you'll be modifying them more than writing them from scratch.

Easier to read than a pom.xml, for sure.

wil4213• 12 years ago

Easier to read than a pom.xml, for sure.

In that case I will have to check in out on a side project. My current projects at work are using Ant or Maven and I dont really like sorting through the pom.xml especially if someone else set it up.

darylteo2• 12 years ago

What if I told you that Java code is perfectly compilable in Groovy and learning the required amount of Groovy isn't that much anyway?

There's even a JavaDoc that you can reference at any time.

And even now in Java 8, you have Lambdas... well guess what? Groovy uses Closures everywhere, and the syntax is similar too. So it really shouldn't be black magic.

wil4213• 12 years ago

What if I told you I am not a very experienced java programmer and learning something new wouldn't really help me become a better java programmer.

That and my employer uses Java and randomly chooses PHP sometimes for no apparent reason.

spopejoy2• 12 years ago

In this example, Java is rather annoying, especially when it comes to testing the type of a message with instanceof and casting objects from one type to another.

Using instanceof is an antipattern 99% of the time, easily avoided with proper API design. In this case a simple enum type would help with appropriate getType() method on the event; or a polymorphic event API with dedicated method types for each event (LifecycleEvent marker interface with ExitEvent subtype containing onExitEvent(ExitMessage m), etc), or ... or ...

Writing an intro to Java + touting your company's API + blaming Java for yourco's API problems: seems like bad form.

Which reminds me: can someone explain how actors is any different than using messages and queues for concurrent programming? Unless it also implies "magic translation of messages to method calls" which makes me uncomfortable (bad memories of CORBA/Web services)

EdwardDiego8• 12 years ago

or a polymorphic event API with dedicated method types for each event

Exactly!

sivanmz• 12 years ago

Agree that instanceof is wrong and discredits the article.

I'm not sure if this is what you meant, but here is how polymorphism along with the double dispatch pattern would work: NaiveActor#handleLifecycleMessage will need to delegate to the event subclass, which will in turn select the appropriate method on NaiveActor.

Example of subclass of LifecycleMessage:

        class ExitMessage implements LifecycleMessage {
            @Override
            void handle(BasicActor actor) {
               actor.handleExitMessage(this);  
            }
        }

In NaiveActor:

        @Override
        protected void handleLifecycleMessage(LifecycleMessage m) {
            m.handle(this);
        }

        @Override
        protected void handleExitMessage(ExitMessage m) {
            if (Objects.equals(m.getActor(), myBadActor) {
                System.out.println("My bad actor has just died of '" + m.getCause() + "'. Restarting.");
                spawnBadActor();
            }
            return super.handleExitMessage(m);
        }

It's been my experience that many developers resort to instanceof or enum type flags because they don't believe polymorphism actually works in real world situations such as this.

mbrock• 12 years ago

I think a lot of programmers aren't totally clear about how dispatch works in Java. I've talked to many who couldn't explain exactly why it doesn't work to overload based on subtype information only known at runtime. Type flags are extremely obvious!

spopejoy2• 12 years ago

There's something wrong with this approach, though: it couples ExitMessage and BasicActor, in that BasicActor would have to have a method for each event type, resulting in lots of empty methods, etc.

What I'm describing is a marker interface for eventing, with specific subtype APIs:

  interface LifecycleListener { }

  interface StartListener extends LifecycleListener { 
      void onStart(Foo f); 
  }

  interface ExitListener extends LifecycleListener {
      void onEnd(Foo f); 
  }

along with a single registration method (perhaps a LifecycleObservable API, or in a class also offering event-firing methods):

  Disposable addLifecycleListener(LifecycleListener l)

The benefits to the client code are numerous: clarity (dedicated methods for events), declarative code ('implements' section documents interactions), performance (no dispatching in client code).

[Note, Disposable here represents a dispose() function to deregister the listener, avoiding the classic pair of void register/deregister methods. Often I find void methods represent a missed opportunity ... wishing Java was more like Smalltalk here]

The service side has to jump through some hoops to efficiently dispatch, using class equality or instanceof at registration time to pre-select listeners. This code could certainly use pattern-matching but personally I think it would look identical. If anything, I'm glad that pattern-matching isn't available in this case, to at least alert framework devs to the problem and not push it off to tons of switching on the client.

heavenlyhash3• 12 years ago

I believe the segment that cast shade on instanceof checks was doing so in the process of mentioning "pattern matching" features from other languages. It would be difficult to suggest the utility of pattern matching without explaining the issue that it addresses.

I agree that you can do this with a boilerplate of `MyEnum getType()` methods, and I admit I often do this so I can use a switch statement in situations like these, but I don't at all resent the suggestion that maybe there's a better way -- this does come up often enough that I would rather appreciate a language feature that helped me deal with it.

elchief2• 12 years ago

What did the Eclipse team do so wrong to fall so fast?

Also, what are Maven's fatal flaws? I don't consider XML a flaw.

lightblade• 12 years ago

...simplicity of Maven...

Did I read that right?

eranation2• 12 years ago

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.

pjmlp28• 12 years ago

The initial JVMs already had Go like threads, aka green threads, with red threads being OS ones.

The language specification does not require a specific implementation and with time all JVMs moved to red threads.

There are a few JVMs around that still support green threads as threading model.

pswenson8• 12 years ago

I'd like to hear thoughts on CheckedExceptions in part 2. IMO, they are a disaster - most projects degrade into all methods having a "throws Exception" clause. But I'm not sure if there is any consensus on how the CheckedException haters like myself work around them. I use Runtime exceptions everywhere, but it's a pain/boilerplate to convert them.

mike_hearn• 12 years ago

Not all checked exceptions are bad. The main problem is that the core Java libraries tend to use them too aggressively and now of course cannot be changed. You really have to be sure that the caller MUST handle a particular occurrence and anything else is a bug to make an exception checked. But, I do find it helps me feel more confident in my code. Everyone hates writing error handling code, but at least with checked exceptions you can see whether it's been done properly or not.

But in Java 8 for the times when I want to disable it, I just use the following code:

    public interface UncheckedRun<T> {
        public T run() throws Throwable;
    }

    public interface UncheckedRunnable {
        public void run() throws Throwable;
    }

    public static <T> T unchecked(UncheckedRun<T> run) {
        try {
            return run.run();
        } catch (Throwable throwable) {
            throw new RuntimeException(throwable);
        }
    }

    public static void uncheck(UncheckedRunnable run) {
        try {
            run.run();
        } catch (Throwable throwable) {
            throw new RuntimeException(throwable);
        }
    }

    public static void ignoreAndLog(UncheckedRunnable runnable) {
        try {
            runnable.run();
        } catch (Throwable t) {
            log.error("Ignoring error", t);
        }
    }

Then you can write

Foo result = unchecked(() -> getAndMaybeThrow(a, b));

pron10• 12 years ago

Well, there's not much to discuss about checked exceptions. The general consensus in the Java community that it was a very good idea in theory, that hasn't worked out well in practice. New API designs usually don't introduce new checked exceptions. Those that are there - are there, and new ones aren't being added, so there is really not much to argue over.

heavenlyhash3• 12 years ago

I quite like checked exceptions. They're actually one of the few things that keeps me writing java for more projects instead of switching more of my time to golang -- golang takes the far opposite approach, and with either returning error codes, or using golang's borderline untyped panic (yes, yes, you can panic typed errors... but it's an incredible PITA to try to construct an error type hierarchy and impossible do terse typed catch blocks with it) doesn't scale well for projects more than about 4ksloc in my experience.

Exceptions signatures, like anything else, need aggressive refactoring to remain a useful part of an API. Always remove throw declarations that aren't needed. Always refactor the exception type hierarchy as your project evolves to keep it sensible.

The worst of typed exceptions I've felt recently is the JGit API (don't get me wrong, JGit is an amazing piece of work; but its sharpest parts are the error handling). There's inchoate masses of IOExceptions from some pieces, JGitAPIExceptions in others, and none of them compose nicely so that when I do large amounts of work I can summarize the error handling up to a few types of conceptually similar problem. And several JGit commands throw checked exceptions for what are essentially fuck-ups in builder patterns, which have been compile-time issues every time I run into them, thus a source of huge irritation (these are prime examples of where you should use unchecked exceptions).

On the other hand, the project I was using that same JGit API in has been one of the best examples of why typed exceptions can be a good idea. This project grew out of a python->java rewrite, and so in the original translation used completely unchecked exceptions as a holdover from the python form. (Why rewrite? It needed to go cross-platform and I needed a stable git api; libgit2 still couldn't clone at the time, so it was jgit or gtfo.) And as I kept working on the project and writing test cases... time and time again, converting things to typed exceptions and refactoring the exception hierarchy paid huge dividends in code quality, huge improvements in API consistency, and raised the quality of tests and final product alike because similar error cases ended up with similar exception types, and tended towards similar handling as I refactored similar exceptions types into one... #wining.

tl;dr being irritated by methods that claim to throw too many exception types is good and healthy. The fix isn't to toss checked exceptions out the window: the fix is to take the pain, and use it to fuel a good API with a tightly controlled and easily understandable set of failure modes.

zmmmmm4• 12 years ago

I think some of the additions in Java7/8 will make them a little easier to work with. The worst thing used to be the necessity to nest multiple try/catch blocks, or repeat identical code between separate catch blocks because different components throw different errors. This is now dramatically helped by the multi-catch and other additions.

Like you, I use a lot of RuntimeExceptions, but I think in it's important not to overlook the benefit of checked exceptions: if you're trying to write reliable software looking up and understanding every possible failure mode of every API you are calling is an almost unbearably tedious and impossibly boring task. In principle, having the compiler check and tell you "Hey, there's this error that could occur and you haven't defined how your code is dealing with that" is a tremendously useful thing. Our human tendency to focus only on the successful path through our code and then ignore all the possible failures is terrible bias if you're trying to make code that behaves the right way under ANY circumstance. So I support checked exceptions, and I hope the new improvements in Java make them more workable and accepted. There probably need to be more improvements, something long the lines of STM type features before we'll get there though, I think.

pswenson8• 12 years ago

1) try introducing a Checked Exception in a commonly used method. Soon you'll be updating 100s or 1000s or methods.

2) checked exceptions don't play well with interfaces (APIs) for similar reasons. any interface user must change their code simply because some new checked exception bubbles up now

3) checked exceptions lead to terrible error handling and hiding bugs/system problems. instead of letting exceptions bubble up - java coders almost always write code that either swallows or simply logs the exception and continues along as if nothing happened. If my bank deposit fails, I don't want the failure to just end up in a log file - I want to know it! Exceptions were designed to usually bubble up and be exposed/handled in a standard way at the top level thread. They are usually not recoverable.

4) they lead to bugs. I very rarely see anyone handle the statement/resultset handling of JDBC code correctly.

5) if they are such a good idea, why does no other language ever created has them?

hugofirth• 12 years ago

Another great Java resource (though admittedly the current edition is focused on Java 7) is "The Well-Grounded Java Developer" by Evans & Verburg [1].

[1] http://www.manning.com/evans/

ninjazee124• 12 years ago

I went from Java to Scala and am back to Java 8, and couldn't be happier with my choice. We are also using the latest Spring 4 framework which plays well with Java 8.

A lot of the Spring + Java haters haven't really looked at all the improvements have happened to both Spring and Java recently, either that or they just like to bounce off what they read online without any actual experience.

It's a solid stack for a backend, and I have built the whole platform on in without a hitch.

loup-vaillant• 12 years ago

depending on the exact usage, a large Java program can be slightly slower, as fast, or a little faster than a comparable C++ codebase

This is probably true but…

Does anyone here have any data to back that up?

pit2• 12 years ago

Does anyone here do Java development sans IDE -- like, say, with Emacs?

darylteo2• 12 years ago

When I taught programming I made my students do all their programming in notepad++/sublime text.

nvarsj2• 12 years ago

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

ivan_gammel• 12 years ago

Oddly, this resource is blocked in Russia, so I was not able to read the article from my ipad. WTF with this country. Anyone knows if I can penetrate Great Russian Firewall on ios?

AmrMostafa• 12 years ago

If you have come to this post expecting to read something related to modern Java for the web, and have come back unsatisfied, then here is something to make up for that: yeoman's jhipster generator: http://jhipster.github.io/

Presentation: http://jhipster.github.io/presentation/

0800899g• 12 years ago

modern java

hyp0• 12 years ago

+1 for markdown inline docs.

A simple, obvious, useful idea I hadn't seen before.

jg03• 12 years ago

You always know to expect a dreary, look-my-language-is-modern-too article when "opinionated" features in the title. This one didn't disappoint.

An Opinionated Guide to Modern Java Development, Part 1

Related Stories