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

341–350 of 402 posts

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

#341

Post by wil421 »

darylteo wrote: post #284
wil421 wrote: post #124

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

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.

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.

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

#342

Post by pkolaczk »

zenbowman wrote: post #181
a8da6b0c91d wrote: post #24

Earlier quoted context omitted.

> super subtle rules (eg: C++) C++11/14 is in practice not that much more difficult to write well than Java. It's not 1998 anymore. The language is larger and more complex than Java, but it's also a lot more expressive and powerful, not to mention faster.

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

Java is fast enough now to compete with C++ in some categories of software traditionally viewed as "high performance" e.g. web-servers or database systems. Applications running like "turtle on anything short of server-class hardware" is a result of bad-coding, not Java itself.

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

#344

Post by vorg »

pjmlp wrote: post #307
vorg wrote: post #240

Earlier quoted context omitted.

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

From the usual JUG discussion themes I also get the impression, if it wasn't for Gradle, the Groovy interest would be much lower nowadays. There was a Grails wave here in Germany, but now I seldom see anything related to it.

Yesterday's Who is hiring? (https://news.ycombinator.com/item?id=7679431) only had 1 mention of Groovy or Grails (and none of Gradle) out of over 400 comments. And many (most?) of the projects tagged Groovy on Github are triggered by a single Gradle build script for a project that uses some other language. These Gradle build scripts are often 30 lines long.

So I'm not sure how Groovy will fare in the future. Nothing seems to be taking its place, though, for testing and general manipulation of Java classes. Java and Scala are statically-compiled languages for building things, whereas dynamic Clojure seems to also be used for systems programming rather than scripting. I'm guessing Oracle will heavily promote Nashorn for scripting and JavaFX, but Javascript syntax doesn't seem quite as full-featured as Groovy for now.

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

#346

Post by wtetzner »

snikeris wrote: post #49
wtetzner wrote: post #47

Earlier quoted context omitted.

So why not just pass its dependency as a constructor argument?

Passing a dependency as a constructor argument is dependency injection: http://en.wikipedia.org/wiki/Dependency_injection#Constructo...

Right, my point was more "why do you need a framework to call constructors for you?".

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

#347

Post by smrtinsert »

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…

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.

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

#348

Post by [deleted] »

pjmlp wrote: post #84
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.

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.

[deleted]

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

#349

Post by spullara »

llemiengre wrote: post #318
spullara wrote: post #292

Earlier quoted context omitted.

I don't think that person understands how it works at all.

He knows what he is talking about & his description matches the explanation by Brian Goetz. So unless I'm missing something, please be specific.

Well, for one, Lambdas are desugared into methods, not anonymous classes. Early on they used anonymous classes because it was convenient but that wasn't the final translation strategy.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...

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

#350

Post by _ea1k »

spullara wrote: post #290
_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.

Oracle was offering licensing for "real Java" at around $1 per device. This was too high for Google that wanted to make it entirely free. Kind of silly, since Android hardware manufacturers pay much more than that to Microsoft in patent licenses.

It's unlikely that the patent licensing situation would have been different with Java ME. It is entirely likely that it would not have been completely open source due to Sun (and ultimately Oracle) restrictions on Java ME.
Post reply on HN