An Opinionated Guide to Modern Java Development, Part 1 • Hacker News Board

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

#221

Post by pswenson » Thu, May 01, 2014, 10:27 PM UTC

izacus wrote: post #218

pswenson wrote: post #195

Earlier quoted context omitted.

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…

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 would have much preferred that Rake became the default build system for java. Sadly that approach never took off....

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

#222

Post by ryanobjc » Thu, May 01, 2014, 10:27 PM UTC

cwufbt08 wrote: post #76

ryanobjc wrote: post #10

A lot of people love to hate on Java, but it's a surprisingly dynamic language and there is a ton of great testing, networking, and many other libraries available. One of the things I appreciate about Java is the ability to take large teams and just have their stuff work together, without having unhuman discipline around super subtle rules (eg: C++) Also, IntelliJ is a must have!

In what way is Java a "dynamic language" ?

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.

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

#223

Post by EdwardDiego » Thu, May 01, 2014, 10:28 PM UTC

eeperson wrote: post #173

EdwardDiego wrote: post #164

Earlier quoted context omitted.

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

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

Yeah, I just went and had a look at the project in question and I'm being unfair to SBT, it was a plugin I use to package WARs that changed underneath me. The plugin was quite closely coupled to the version of SBT, but the latest variant of it (once I found out about the migration to a different artefact) seems good.

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

#224

Post by ryanobjc » Thu, May 01, 2014, 10:29 PM UTC

pswenson wrote: post #195

tieTYT wrote: post #50

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

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…

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 :-(

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

#225

Post by lomnakkus » Thu, May 01, 2014, 10:31 PM UTC

eeperson wrote: post #215

lomnakkus wrote: post #187

Earlier quoted context omitted.

Right now, SBT + IDEA is a bit of a pain because they share the same target folder and IDEA sometimes overwrites/deletes .class files that your application (started via sbt run) hasn't loaded yet. Usually that leads to a few ClassDefNotFound errors and such. Hopefully that'll go away once we have a single SBT instance. My two wishes for SBT would be: 1) A monadic style for .scala build files. It would make dealing wi…

Would you mind elaborating on what you mean by a monadic style for .scala build files? PS - You may already know this, but you can change IntelliJ's compile output directory [0]. [0] - http://www.jetbrains.com/idea/webhelp/configuring-module-com...

Thank you, I haven't actually tried that. I really live the "I just want my IDE to work" philosophy (out of laziness), so I try to avoid configuration if I can. :)

About monadic style: I realize that it's a hard sell, but it's basically about leveraging for comprehensions (aka. do-notation) to specify your build. Shake is an example of this, although probably not particularly suited to building Scala code.

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

#226

Post by mike_hearn » Thu, May 01, 2014, 10:32 PM UTC

pswenson wrote: post #191

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.

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 {
        public T run() throws Throwable;
    }

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

    public static  T unchecked(UncheckedRun 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));

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

#227

Post by pron » Thu, May 01, 2014, 10:33 PM UTC

pswenson wrote: post #191

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.

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.

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

#228

Post by thwarted » Thu, May 01, 2014, 10:34 PM UTC

pjmlp wrote: post #73

_pmf_ wrote: post #68

Earlier quoted context omitted.

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

> Mobile non-Android Java is deader than dead. Lots of embedded devices make use of J2ME, e.g. cars, manufacturing, electricity monitoring...

How many of those will get Java 8 updates?

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

#229

Post by lomnakkus » Thu, May 01, 2014, 10:38 PM UTC

lmm wrote: post #134

bananas wrote: post #34

Earlier quoted context omitted.

That pisses me off but the following is much worse. The commit comment that goes: "checked in abstract_class.cpp" Duh!

I do that a lot, or rather my commit messages are usually "mumble" or "fixed this" or "awookga". I feel this is more justified than the javadoc case because you can always just leave out javadoc, whereas the VCS forces me to put a commit message.

Just a humble suggestion, but perhaps you should enter a message which states the intent or the functionality of the change more explicitly. (If you're just doing a topic branch, then sure, just say "wip" or "blah", but please clean it up with "git rebase -i" before merging.)

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

#230

Post by Groxx » Thu, May 01, 2014, 10:39 PM UTC

pjmlp wrote: post #183

Groxx wrote: post #178

Earlier quoted context omitted.

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

True, but it won't help users with KitKat and lower devices. We all know that they won't see any vendor updates.

Well sure. But people don't update their Java installs either, neither do all businesses. They're likely not going to be able to take advantage of v8 stuff. And can dumbphones on a Java platform (Symbian? Nokia? Others?) run the new Java flashiness? Every platform has problems like this.