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

51–60 of 149 posts

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

#51

Post by ReverendBayes »

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…

Have you ever programmed anything substantial using java outside the enterprise/agile IT environment? Any type of project on your own time? Have you every built anything in Ruby, Python, or Go? I'm asking to try to discern what you mean by "more viable".

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

#52

Post by yareally »

jerven wrote: post #41
yareally wrote: post #34

Earlier quoted context omitted.

Plus they tend to avoid all the excessive XML tooling and configuration that goes along with J2EE. Compared to nearly any other templating system, JSP is one of the most tedious I've encountered and try to avoid. I had the displeasure of using it a while ago with Struts for a project at my University and hope it will be the last time I ever have to use it. I assume it stems from Coldfusion and it being popular around…

J2EE was last released 10 years ago. Since then its been JEE and with the latest you should not have to use XML for configuration only when you want some really odd config instead of going by convention. JSF2/Facelets replaced JSP in the most recent JEE standards and is much nicer to work with. I mean JEE 1.6 was released 4 years ago (around the time of Rails 2.0). For a standard that is not bad. We actually use a lo…

Interesting. Thanks for the info and I'm glad to see things have changed for the better. I'll have to search around when I have some free time for more details.

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

#53

Post by pkinsky »

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…

More like Why Stadium-Scale Sound Systems Rock (even if you play shit music on them).

JVM != Java

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

#54

Post by fauigerzigerk »

petercooper wrote: post #17
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…

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 information available locally that you would otherwise have to look up elsewhere.

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

#55

Post by venomsnake »

alayne wrote: post #35
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.

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.

Is that really the case in real world loads? I have always thought that the moment you avoid blocking io and code almost any language is fast enough. And usually the problems come from bad design.

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

#56

Post by alkonaut »

I don't know if the whole oracle/sun debacle is to blame for the complete stagnation of the jvm and the java language, but the development pace is laughable these days. We're still waiting for proper lambda expressions after all these years. We still have a runtime without generics. And so on.

The irony of the article is that ZeroTurnaround not only make money from the java community, but does so by selling tools that work around shortcomings of the jvm. So not only is it in their interest to have a large dev community on the jvm, if you are a bit mean you could say its in their interest to have a crap jvm :)

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

#57

Post by Roboprog »

th0br0 wrote: post #4
jonstewart wrote: post #2

Beefs with this article: 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. 2. clang and gcc have compatible command-line option syntax. 3. The options example he lists for gcc is a pure strawman. Maybe they are necessary to compile that particular source file, but it is not necessary to use all these…

Most importantly, his gcc example is taken from OSX... ugh.

As the guy says he is writing music software, Mac OSX would be a pretty important platform to cover.

That said, I'm a recent convert from Linux to OSX, and I like to tinker with Garbage Band from time to time :-)

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

#58

Post by yareally »

specialist wrote: post #50
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.

Honest question: Are their refactoring IDEs for Ruby, Python, or other dynamically typed languages? Agree 100% about Java's verboseness. I really want type inference, lightweight objects, properties (vs JavaBean accessor convention), switch for 'instanceof', etc. However. Java's verbosity is nothing compared to the verbosity of the common APIs and frameworks. All that DI, IoC, configuration via markup, etc. are terri…

> Honest question: Are their refactoring IDEs for Ruby, Python, or other dynamically typed languages?

Yep, Intellij IDEA does it pretty well, or one can get their language of choice individually as WebStorm (JavaScript/NodeJS), PHPStorm (Webstorm + PHP), PyCharm (Python + Webstorm) or RubyMine (Ruby + Webstorm).

The refactoring and type inferring abilities for dynamic languages in each are pretty amazing. Types can also be inferred by docblocks and return types as well in each IDE for code analysis to avoid silly mistakes. That, along with refactoring has saved me tons of time and a reason to use a full IDE over a more lightweight editor. They also have an open source version of the Python IDE if you want to try it out.

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

#59

Post by this_user »

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…

Ruby is 18, Python is 22, what's your point? I'd very much like to hear your valid criticism towards Java. From my point of view that language and ecosystem is alive and well and newer iterations of Java EE have been giant leaps forward in terms of productivity.

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

#60

Post by deong »

pron wrote: post #42
Styck wrote: post #23

Earlier quoted context omitted.

This is one of the reasons I use Go in favour of pretty much anything running on the JVM stack. I don't have to change my workflow at all between working in Python, C, Go and JS. I can use vim for all of the above and none of them force me to have years of experience with an IDE in order to be productive.

Sure. Go is pretty much a JVM-less Java. To me, it seems the exact wrong things to take from Java. Go takes the language (Go is a simplified Java, with some modern improvements) - which is only OK, but drops the JVM, which is awesome. It does have one advantage over the JVM, which is a much shorter startup time. But Java has better performance and far better monitoring tools (as well as dynamic linking and hot code s…

I think calling Go a simplified Java is pretty far off the mark. Aside from both aiming at the niche of being sort of "medium-level" languages, for lack of a better term, Go's approach seems very different from Java's.

Objects vs structs and functions, exceptions vs multiple return values, required static vs required dynamic linking, implicit vs explicit subtyping/interfaces, etc.

Go is C with added convenience.

Post reply on HN