Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Opinionated Guide to Modern Java Development, Part 1

blog.paralleluniverse.co

Post reply on HN
Print view View original

181–190 of 402 posts

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

#181

Post by zenbowman »

a8da6b0c91d wrote: post #24
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!

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

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.

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

#182

Post by lomnakkus »

benjaminpv wrote: post #22
kodablah wrote: post #12

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

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

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.

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

#183

Post by pjmlp »

Groxx wrote: post #178
pjmlp wrote: post #97

Earlier quoted context omitted.

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

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

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

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

#184

Post by jebblue »

bradleyjg wrote: post #160
jebblue wrote: post #137

Earlier quoted context omitted.

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.

Do you use the link source tab of the "Java Build Path" to point to the project directory in the source control directory?

Nope, never used that. For Git it's straightforward, I have one Git repo per project I manage with Git. just use Import Project. The code remains where it is at.

For SVN, I use Checkout and uncheck "Use default workspace location" and specify the location of the code.

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

#185

Post by pjmlp »

eranation wrote: post #177

The biggest take I have from this post is that apparently they have created go-like lightweight threads for the JVM with Quasar ( http://docs.paralleluniverse.co/quasar/ ) which is really interesting. If I understand correctly, Quasar uses bytecode instrumentation to enable user-mode threads for the JVM, and they claim they did benchmarks that show X6 to X12 better performance than native JVM threads: http://blog.par…

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.

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

#186

Post by hatred »

beat wrote: post #100
_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.

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

Isn't their stack based on Erlang or am I missing something ?

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

#187

Post by lomnakkus »

eeperson wrote: post #156
smrtinsert wrote: post #105

Earlier quoted context omitted.

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…

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…

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 with the immutable bits of project definitions so much more pleasant and we could avoid the weird semi-Scala syntax of .sbt files. And 2) A bottom-up approach similar to Pants. My team frequently end up getting a lot more project interdependencies than we bargain for simply because it's too easy to induce transitive dependencies.

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

#188

Post by georgewfraser »

pjmlp wrote: post #97
mncolinlee wrote: post #82

Earlier quoted context omitted.

Dalvik is being slowly replaced by ART (Android RunTime). Also, you can pretty easily hack Java 7 or even Java 8 into Android to use lambdas. Official, default support is coming soon. http://tools.android.com/tech-docs/new-build-system/user-gui... http://zserge.com/blog/android-lambda.html

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

Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.

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

#189

Post by java-lang »

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

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

#190

Post by sivanmz »

spopejoy wrote: post #149

> 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 (Lif…

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.
Post reply on HN