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

Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

zeroturnaround.com

Post reply on HN
Print view View original

81–90 of 149 posts

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#81

Post by RivieraKid »

fauigerzigerk wrote: post #54
petercooper wrote: post #17

Earlier quoted context omitted.

One problem of many is that Java is quite verbose, and while IDEs like Eclipse help with this, there's a significant contingent of open source developers who both refuse to use typical IDEs and who also like to manually manipulate their code rather than let an IDE tweak it about. Languages like Ruby and Python make that easily manageable in a way Java doesn't.

Java is certainly unnecessarily verbose, but if you compare it to other statically typed languages (like C++, C# or Go) and subtract the verbosity that is purely cultural (overdesign) it's not quite as verbose as it sometimes seems. Comparing to dynamically typed languages (and even to statically typed languages using a lot of type inference) is a little tricky, because in some cases "verbose" means you have informat…

> verbosity that is purely cultural (overdesign) it's not quite as verbose

This is absolutely true, especially with Java 8.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#82

Post by abvdasker »

sgt wrote: post #14

Java is rapidly becoming more viable as an alternative to all of these "trendy" languages these days, e.g. Ruby, Python, Go. What I mean by that is simply that a lot of developers are prejudicious against Java due to historically it being slow and having tedious development feedback cycles. We use Java extensively (and Java EE 6) in an agile IT business and it is truly an asset. I encourage others to look in the dire…

This. Java's syntax and core API is pretty much stable compared to the hot languages championed by so many HN readers. Updating applications written with the "hipster languages" is like pulling teeth. It has a serious impact on an application's maintainability when the language's core API is constantly changing.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#83

Post by marcioaguiar »

kamaal wrote: post #64

One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that i…

It's impossible to deal with ANY LARGE PROJECT without an IDE.

If you don't use an IDE, your project is not large yet.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#84

Post by agibsonccc »

gresrun wrote: post #67
microtonal wrote: post #30

Earlier quoted context omitted.

The Maven assembly plugin can also do this with the 'jar-with-dependencies' descriptor.

I personally use the maven-shade-plugin for this because it has built-in support for handling special resource files like licenses, service definitions, and manifest entries.

The maven shade plugin can be dangerous if you hit the zip file limit of 65535 entries. Watch your filters.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#85

Post by pron »

PuercoPop wrote: post #66
alayne wrote: post #35

Earlier quoted context omitted.

The 20-50x performance tradeoff is a hard pill to swallow though. I'd love to see a better performing dynamic language that isn't as minimal as Lua.

It is called Common Lisp

Or Clojure.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#87

Post by pron »

James_Duval wrote: post #40
sgt wrote: post #14

Java is rapidly becoming more viable as an alternative to all of these "trendy" languages these days, e.g. Ruby, Python, Go. What I mean by that is simply that a lot of developers are prejudicious against Java due to historically it being slow and having tedious development feedback cycles. We use Java extensively (and Java EE 6) in an agile IT business and it is truly an asset. I encourage others to look in the dire…

What I like most about Java is that you can switch more easily to certain fashionable languages (Scala and Clojure) which have good interopability with Java because they use the JVM. Sources for this claim: http://www.slideshare.net/tackers/how-we-mostly-moved-from-j... http://java.dzone.com/articles/moving-java-scala-one-year Counterpoints: Couldn't find any data on how well Clojure works with Java apps. Scala's dec…

Clojure's Java interoperability is better than Scala's. For example, Java collections are automatically treated as Clojure collections with no wrapping required, any Iterable is a seq etc.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#88

Post by kamaal »

RivieraKid wrote: post #79
kamaal wrote: post #64

One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that i…

> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…

I like working with Java too. I'm only pointing out the problems, which I see are pretty clear.

The only problem is from the perspective of using and developing a new skill, I would rather use a newer language which is better built for problems of our time than something 20 years back.

Java has had its day in the sun. Its primary purpose was to become an easy C++ for people who didn't get memory management and people who didn't want to get into tiny pedantic issues while trying to run their code on two different Unix'es. But these are by and large solved problems now. Over years a lot of legacy code has gathered around Java.

But if you want better employability especially if you want to work on new projects, new paradigms and new domains of problems you should likely chose newer set of languages. Not Java.

One hard lesson that I've learned over the years is to never have any hard religious feelings towards old aging tools. We must learn to move on, find new shores build new stuff there. The only projects you get with these older tools are legacy ones, and people are generally waiting just to phase them out.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#89

Post by RivieraKid »

pekk wrote: post #46

Why Big Band Music Rocks More Than Ever: Part 1 - You Can Dance To It There are still fans of Big Band music! Java fans (or maybe I should say, employers) who want to keep exhuming this dead horse might be well served to emphasize "you can get a job" and "it's enterprise" and "JIT makes Java faster than Assembly" as they have been doing for decades, rather than tarting it up (a Java logo with an electric guitar, seri…

As a Java fan I claim that Java is the best choice for lots of projects. What other language has:

- amazing tooling

- static typing

- great performance

- huge amount of libraries available

- multiplatformity

?

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#90

Post by agibsonccc »

rsynnott wrote: post #11

> All this is only worsened by the ‘black box’ nature of the optimization level switches. JVM switches like -XX:CMSInitiatingOccupancyFraction=70 -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewSize=2048m -XX:MaxNewSize=2048m (taken from real recommended settings for an open-source project) are, of course, not opaque-to-the-average-user at all :)

One of my favorite tricks not often used: -XX:MaxTenuringThreshold=0

Higher throughput when you have lots of short lived objects.

Post reply on HN