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

Post by trailfox » Mon, Oct 07, 2013, 1:57 PM UTC

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…

Post by Styck » Mon, Oct 07, 2013, 1:59 PM UTC

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.

Post by kumarm » Mon, Oct 07, 2013, 2:00 PM UTC

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

Post by jebblue » Mon, Oct 07, 2013, 2:02 PM UTC

gresrun wrote: post #5

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…

> 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. It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build art…

Post by rsynnott » Mon, Oct 07, 2013, 2:07 PM UTC

kumarm wrote: post #25

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

http://www.oracle.com/technetwork/java/javase/tech/vmoptions... The page existed for over ten years (Under different domains) and countless tutorial and presentations about hotspot covered them.