There seems to be a real advantage to using the JVM. It has practical-to-use, interoperable implementations of a wide variety of programming languages: from statically typed OO and OO/FP languages (Java, Kotlin, Ceylon, Scala, OCaml-Java) to Lisps (Clojure, ABCL, Kawa) to GIL-less ports of popular scripting languages (JRuby, Jython). You can call Java from a slower language like JRuby for the performance-critical bits instead of having to either write an interpreter extension in C or bite the microservice bullet. Deployment is simple. There is a lot of high-quality open source libraries. The price for this, slower application startup, greater memory usage and, in JRuby's case, a degree of incompatibility with the reference implementation, seems worth paying.Still, I don't see a great number of startups or side projects that get featured on HN using the JVM from the get-go. What are the technical and the nontechnical reasons behind this?
[+] [-] pfitzsimmons|10 years ago|reply
2. Using non-Java JVM languages seems to always create as many problems as it solves, in my experience. First, you do not get access to any libraries with C-bindings. So as your project gets going, the probability increases that some library you want to include won't work. Also, there are all sorts of micro-frictions. Debugging support not quite working. Types not matching between Java numbers and python numbers when doing comparisons. Etc. It all adds up. If you use Kotlin, then a lot of code samples you find on stackoverflow will have to be manually converted.
3. If you go pure Java, the type system can be a pain in the neck when you are doing rapid development. Something as simple as getting a row out of the database with date field, publishing it as JSON, then getting posted back an updated version from JSON, requires a bunch of conversions and annotations to make the types all get matched correctly. Writing any sort of time-saving meta code requires a really strong knowledge of how generics, annotations, and reflection works, or else you will be beating your head against the wall.
4. Restart times are longer, and there is no REPL, so rapid iteration is a little slower.
5. I still don't think there is a web framework that is as easy to use as Rails/Django. I don't think this is the fault of the language though, and I have something in the works myself on this front...
[+] [-] MoOmer|10 years ago|reply
2. You have access to troves of Java libraries from most JVM languages.
3. Again, not all JVM languages suffer from this.
4. Some JVM languages have a REPL. JRuby and Scala for example.
5. You can use Ruby on Rails out of the box with JRuby and Torquebox. A couple of gemfile changes and you're good to go.
[+] [-] ashneo76|10 years ago|reply
[+] [-] pcx|10 years ago|reply
I think Play Framework is trying to achieve such usability, but I don't think it's there yet.
[+] [-] neverminder|10 years ago|reply
[+] [-] splix|10 years ago|reply
3. IMO there're no much reason to use pure Java in webdev. Only if you have well defined project, maybe already written in JVM language, that you want to optimize
4. Depends on language. Clojure have one. Groovy/Grails too.
5. check Grails
[+] [-] rglullis|10 years ago|reply
So most of us are subject to fashions and trends. And Java (the platform) is out of fashion* . Which is a pity. I've always disliked Java-the-Language, but kind of hoped some other languages would get first-class status there. By the time that those languages started showing up, I was already deep into Python, which has a flawed VM but a rich ecosystem and multiplatform.
* One of the biggest tells about JVM being seen as a "outdated" platform is that Javascript already had for a long time a JS implementation (Rhino) and it never got traction. It took node.js to come up and suddenly it became popular.
[+] [-] rileymat2|10 years ago|reply
[+] [-] _ea1k|10 years ago|reply
[+] [-] sergiotapia|10 years ago|reply
Having that tumor attached to Java and the JVM taints it for everybody I know.
[+] [-] harel|10 years ago|reply
[+] [-] iheartmemcache|10 years ago|reply
The license for the JDK anyways is good ol' GPL v2 so they really can't take the OpenJDK out of the community[1]. I'm not sure about "Java the language", and I'm really not sure about things like Hotspot and JRocket. But Oracle can do about as much to take away the OpenJDK from the community as Linus can remove Linux.
[1] No license flame wars please.
[+] [-] splix|10 years ago|reply
[+] [-] goldbrick|10 years ago|reply
[+] [-] Juliate|10 years ago|reply
Not sure what to say. This is highly subjective and irrational anyway. And sad, hence.
Having spent some years in college programming in Java around 2000~2004, I was amazed by the then patterns-obsessed ludicrous verbosity of Java projects. Programming for the sake of writing so much text to accomplish so little.
Switched to Perl & PHP, which were, for Web-based projects we had, much more approachable and efficient (although somewhat ugly). Hopefully, Python & Ruby were growing too. And alternatives to XML happened too, thank God.
In the Web development sphere I worked in, Java projects always have felt to me like too... enterprise, under-specified, freezed, too much developer-focused, not enough thought out, although advertised as "the" technology of choice - so it was deceiving.
Whereas teams working with PHP (!) or Ruby felt like much more concerned about usability and efficiency, globally and were delivering better and faster. Perhaps because those teams were composed of people grasping the whole product stack (hosting, db, code, ui) at the same time, because the tools they had enabled them better to do so? Not sure.
Scala & Clojure look nice. Have to find a use case for these in my daily projects.
[+] [-] ericfrederich|10 years ago|reply
Tell me you've seen this:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[+] [-] Heliosmaster|10 years ago|reply
[+] [-] mcroft|10 years ago|reply
Even a couple of years ago when this wasn't the case, it was still usually as simple as dropping your WAR in the autodeploy folder of your favourite app server (e.g. JBoss, WebLogic, GlassFish) - the main issue was that it was different for each app server even though it was (in theory) the same framework.
[+] [-] bcg1|10 years ago|reply
I can see why people wouldn't choose it though... for better or for worse.
There are not a lot of technical reasons, except perhaps than in "the cloud" using more RAM in a VM has a not insignificant cost, and Java-ish applications tend to have significant memory overhead.
Most of the downsides seem non-technical - perhaps mostly than it is just not "the new hotness". Also, in the 2000's Java went through the wringer of being used everywhere in "enterprise", and admittedly there were some ugly growing pains where you ended up writing XML configuration files that could be longer than your actual source code (Spring Framework and Hibernate were serious offenders, and "everyone" used those). During that time RoR started to become popular and provided a more pleasant alternative... then some of the Ruby community started writing hit pieces about the JVM platform which did a lot of damage to Java's "coolness" from which I don't think it ever really recovered.
Fast forward to today, and Java/JVM is battle tested and actually much easier and pleasant to use, but compared to "the new hotness" it is quite mature... and like grandparents, even though there is a lot of wisdom baked in there, it is not something that the "cool kids" want to hang out with.
[+] [-] codeduck|10 years ago|reply
To many people this is somewhat akin to black magic. CMS, G1, PermGen, Xmx, NewRatio... it takes time to get to grips with even the rudiments of the JVM, and many places simply do not have the expertise.
Also, it takes time to set up a JVM stack. You can have a rudimentary rails app running in a few minutes; it took me several hours to get a lightweight spark / mysql PoC up and running.
Java is performant, but it falls down in terms of RAD when contrasted against languages like Go and Ruby and against frameworks like Elixir or Rails.
[+] [-] anuraaga|10 years ago|reply
A modern rails setup with system/user level isolation usually requires homebrew and rvm or similar which is quite involving. Compare that with install java, hit new play app in IDE (or download template) and just run, and I'd say Java has a pretty good recipe for productivity. Deployment? Just copy a fat jar created automatucally by the build system and java -jar it, no virtualenvs in sight.
So would I pick Java for a business? I don't know - I personally enjoy programming in Python way more than Java and would probably go with it, eventually regretting it...
[+] [-] dandrick|10 years ago|reply
It's just a different set of skills to pick up, no different from any others.
[+] [-] matwood|10 years ago|reply
My current go to for quickly starting projects is spring-boot, jooq, and postgres.
And the basic jvm settings will get someone a long ways - much farther than an out of the box Rails setup.
[+] [-] blablabla123|10 years ago|reply
Of course Go and Ruby work out of the box. On the other hand, their runtimes are kind of lightweight and less general purpose as the JVM.
[+] [-] vardump|10 years ago|reply
My perspective to web development isn't public websites, but web servers running on embedded devices and/or workstations.
My issue is that JVM forces me to marry it. I can never make a C-ABI library with it. However I need to run same code also in places where JVM is not available or an option, that limits JVM's usefulness to me.
Other issues I have is it's much harder (and often impossible) to extract maximum performance out of JVM. It's true JVM is as fast as naive C/C++ code and much safer too. There are things you can do to slightly improve performance, but it often means the code is far from idiomatic Java (or whatever language it is that compiles to bytecode).
I like how JVM land can dynamically optimize on the fly according to runtime information. How it can inline at runtime across different .jar "libraries".
But in C-ABI land I can ensure memory locality of reference, directly map objects to memory mapped file, and use SIMD and other processor features for maximal effect. I can deal with multi-socket NUMA issues and allocate CPU local memory. There are cases where SIMD gives 10-40x boost (like sorting code) and a ton of cases where you get 2-10x gain.
I can even compile C/C++ code into pretty fast Javascript that runs in a web browser! Sure there's GWT, but it doesn't come near when it comes to end result performance. In fact, with some care, the same C/C++ code can run on practically any platform. Windows, OS X, Linux, Android, that 8-bit microcontroller, web, DSP, GPU -- you name it.
I do hate the days when some piece of code poops all over stack and heap and all you have is a corrupted core dump to work with.
Of course I can use JNI, but then I have two problems.
JVM banana is tasty, but the gorilla and jungle comes with it.
Rust apple looks promising and so far it seems like I get only the apple I need. On top of that it looks like in addition to memory safety, I'm also getting compile time concurrency guarantees. That's something JVM/Java never gave me.
If one day Rust could provide me dynamic runtime optimization features, that might be all I'll need.
[+] [-] notacoward|10 years ago|reply
2. "Better the devil you know". A lot of people don't trust JIT and especially GC to do their jobs well. Seeing the plethora of alternatives and options that have come along over the years doesn't help. Those things might be awesome by now, they might solve way more problems than they create, but too late. A lot of people have already taken a look and decided to stick with what they know.
3. Oracle.
4. Deployment headaches. Forget developers for a moment. Consider users. The JVM is no trivial thing resource-wise, even compared to other VMs. A lot of users don't want to add that much bloat, plus a whole parallel set of libraries installed "through the back door" instead of via the system package manager, then solve all of the tuning/sizing and dependency problems, to run one app. Developers who care about their users listen to this feedback.
5. Oracle. I know it seems like I'm making a joke here, but that pernicious influence a serious negative for a lot of developers and users.
[+] [-] azth|10 years ago|reply
Practically all major languages other than C or C++ rely on GC. That point makes no sense. The JVM is used in so many critical infrastructure projects (let alone web apps like OP was referring to), and so the JIT point is also incorrect.
[+] [-] mosburger|10 years ago|reply
I think it's a subtle manifestation of ageism in startup culture. From my experience, most Java developers started with the language, community, and ecosystem when it was young, vibrant, and new. Those programmers (like me) are now in their 40s. A lot of them now work in beige cubicles for larger, more family-friendly firms (many by choice, so perhaps "ageism" is unfair). Early in your career, you see opportunity in new ecosystems. You see other people like you taking risks and experimenting with shiny new stuff and all the hype around it (hey look, now I'm the one being ageist!). The more mature you get, the more fads come and go, and some of us are a lot more cynical about whatever johnny-come-lately is being blogged about.
Rails, Django, even PHP, and newer technologies like Elixir and Golang - they're all new and fun. Younger people have the time, risk tolerance, and predilection to hype for the latest fads. There are opportunities to "make your mark" as an expert by contributing to FOSS projects and writing the next Rails in the next new language.
And startups like young people. Google Silicon Valley Ageism. Read pg's tweets (https://mobile.twitter.com/paulg/status/655490006216146944). And young people like startups - they still see glory in working 60 hour weeks and sleeping at their desks.
I recognize that there are obviously lots of exceptions to all of this, and I'm probably being a bit dangerous speaking in generalities with my personal experience.
So tying back to the original question: Java and .Net were hip in the 90s and early 00s. In those eras, the people who worked with those exciting new architectures were the people in their twenties in those eras. They're older now, and startups tend to attract younger employees (call it ageism or call it "startups aren't attractive to older people." It happens). You don't see a lot of twentysomethings looking at the JVM and thinking there's a lot of opportunity there to make their mark as an expert. It's not the latest fad to be posted on Hacker News every other day. You don't see posts titled "A ___, but written in Kotlin"on what is (ostensibly) a site about startups. You see a lot of "A ___, but written in Go."
Having said that, I'm a forty-something Rails dev who's learning Elixir as we speak. So perhaps I have no idea what I'm talking about. ^_^
[+] [-] notacoward|10 years ago|reply
This is a too-common syndrome, and not just with respect to the JVM. Some people are genuinely in love with anything new. Some people just get bored easily. Those might not be the best motivations, but they're not the worst. The worst is the people who jump all over a new language or technology because they know peers are unfamiliar with it. They're insecure. They're not confident in their ability to master the standards and best practices that are already established for an older technology, so they try to get in first on a new technology where those things haven't evolved yet. No rules to violate. Then their arrogance as kings of the new hill, combined with their obvious cluelessness about the broader context, puts everyone off what might have been a true advance in the state of the art. That's the worst.
This is way more common than you'd think. There's a guy on my project, who works around the edges in Go because he can't handle the C that most of the code is written in. I've felt tempted to do similar things myself, writing some bit of code in Lua or something just so others won't be able to review what I've done and say it's wrong. I resisted. Too many don't.
[+] [-] dandrick|10 years ago|reply
Our industry is a big lover of the next big thing. We collectively waste so much time and productivity by constantly changing the rules of the game.
[+] [-] notzorbo3|10 years ago|reply
Other than java, none of those languages are widely used. It seems business have an adversity to languages that are not "popular". So however much I'd like to write in Scala, our customers are not going to approve that.
> JRuby, Jython
Again, fringe languages. Python and ruby are great because of the large amount of packages available. Are those gonna run on Jython or jruby? It's hard to find out, so writing a project in Jruby or jython is a huge risk for me as a developer. ("Sorry, sqlalchemy contains C code").
> Deployment is simple
Hardly. Java is almost an OS in itself. It basically reinvents everything. Scheduling, memory management, logging, monitoring, init systems, etc. I've found that java apps require constant fiddling with settings. Other languages... just run.
> There is a lot of high-quality open source libraries.
True, but that's just as true for many other languages.
> greater memory usage
The JVM doesn't actually use up all that much more memory than, say, a Python program. Basic "hello world" in Python running on Cherrypy already takes up 800mb. The bigger problem is the JVM's rather static memory allocation.
> What are the technical and the nontechnical reasons behind this?
A little background: my experience with Java / the JVM is purely from a systems adminstration point of view. I don't develop in Java or for the JVM.
The reason for me is the obfuscated nature of java projects. It's all very... enterprisey. Hundreds of XML configuration files, toggles switches and knobs to tweak everywhere. I strongly believe in KISS, and Java/JVM is about as far away from KISS as you can get. I'm pretty sure it's great if you're following old-school waterfall "design upfront, then implement" projects like many big companies do (which I don't think is wrong at all). But when it comes to bootstrapping a project: no thanks.
[+] [-] nickjj|10 years ago|reply
For example a Flask project that I worked on had about 30 top level packages, and the entire web server used 55MB of RAM running with 1 gunicorn worker.
[+] [-] codeduck|10 years ago|reply
> Hundreds of XML configuration files
is a byproduct of the frameworks, not the JVM itself. Enterprise Java swallowed the XML kool-aid in a big and horrible way.
[+] [-] davelnewton|10 years ago|reply
[+] [-] rb808|10 years ago|reply
Java + Tomcat is simple, lightweight, powerful and fast.
When Java + Maven + Spring + Hibernate + JUnit + Jenkins became the default, it really became much harder to learn, slower to do anything and generally frustrating.
[+] [-] kisamoto|10 years ago|reply
Java is an excellent battle ready language that stable components in a business can be ported into with excellent test coverage and the power of all the mature libraries and tools.
However in a startup where maybe the end goal isn't completely defined yet; there is prototyping code to see if it will eventually get used and plenty of LoC being thrown away, wrestling with added libraries and even the compile & deploy time of Spring + Tomcat can really slow development and increase complexity breeding frustration.
[+] [-] thescribe|10 years ago|reply
[+] [-] chajath|10 years ago|reply
Technical - I like Node's single-threaded, non-blocking model. It is enforced at the platform level, so that libraries from third-party companies are forced to adhere to it (single threaded AWS JS client library vs thread-pooling AWS libraries in JVM)
Non-technical - Java and C# is still lingua franca in most big companies in the industry. If you were to do side projects on your own, might as well pick something that's not part of your routine life, just to get some fresh new perspective.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] yazriel|10 years ago|reply
Are you asking about the language or the platform ??
The usual argument for node vs java (for example) is that node has many small libraries (really code sniplets) which are instantly usable. So a lower activation energy!
As far as platform, the technical merits of a JVM are so much down the road so as to be completely meaning less at the critical early stages.
[+] [-] xeviknal|10 years ago|reply
[+] [-] 5ersi|10 years ago|reply
1. Java is not "a stack". It's a platform with multiple JVM, even more languages and numerous frameworks/languages. There are a lot of agile Java stacks out there.
2. Java is very strong in open-source, including companies that contribute to it: Redhat (JBoss), Spring Source, Apache (https://projects.apache.org/), IBM (http://www.ibm.com/developerworks/java/find/projects/). Java is #2 OSS language on GitHub (http://githut.info/).
About Java community not being as huge as Ruby, Python, JS: http://www.tiobe.com/index.php/content/paperinfo/tpci/
3. Just browse links above to see thousands of Java projects that are constantly being developed by thousands of contributors.
[+] [-] mbrock|10 years ago|reply
[+] [-] neel8986|10 years ago|reply
[+] [-] osullivj|10 years ago|reply
[+] [-] zubairq|10 years ago|reply
https://github.com/zubairq/AppShare
[+] [-] PaulHoule|10 years ago|reply
One definite problem I see is that (i) the Oracle JVM works better than Open JDK if you are doing anything demanding, and (ii) the Oracle JVM installer wants manual confirmation that you accept the license when you install it. (There is an answer for (ii) but that is all I will say about it.)
I think Java might be a harder platform to pick up than some other platforms. I have been programming in Java since Java was in beta, but today you need to know about Maven, probably Spring and also you need to have an IDE that provides more solutions than problems.
[+] [-] adamzegelin|10 years ago|reply
The OracleJDK is built on top of OpenJDK. The only differences, according to a quick google, are some additional tooling, higher quality Java2D rendering and a different licence.
There is no difference in GC algorithms, hotspot optimisations, etc.
Tl;dr use OpenJDK
[+] [-] malfist|10 years ago|reply
[+] [-] stonemetal|10 years ago|reply
When I work on side projects that frustration is something I don't want to repeat. Java doesn't make the list of tools I consider. Maybe the other JVM languages have a better story in that regard. I just figured they reused Java's infrastructure and were equally handicapped.