Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why don't more web projects start with a JVM stack?
50 points by networked on Feb 4, 2016 | hide | past | favorite | 87 comments
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?




1. There was a history of heavy-weight, overly verbose frameworks. The early frameworks were over-engineered and hard to use. Lightweight frameworks in dynamic languages (Rails, django) thus took off when you they showed how you could write a blog app in fifteen minutes using only a few dozen lines of code.

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...


Some counterpoints:

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.


2 & 3 aren't really counterpoints - 3) explicitly states "If you go pure Java", and 2) regards compatibility issues, not lack of libraries.


I believe Django also works under Jython


Last I used it it had a memory-leak issue that persisted for quite a while. By the time the bug was fixed, I'd gone off it.


5. SpringBoot = http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/refe...


For me (5) is the major reason. Web development with Rails/Django is so much easier and smooth compared to that of any Java/JVM based frameworks, it doesn't make sense to use the Java/JVM ones. Even a Ruby/Python novice can pick up and run with Rails/Django. You will end up building a robust, secure solution following well documented best practices and leveraging abundant 3rd party library ecosystem.

I think Play Framework is trying to achieve such usability, but I don't think it's there yet.


Regarding 5: yes there is, it's called Play Framework.


Play probably is the JVM world's best answer to Rails/Django, but it's neither as complete nor as frictionless. Source: I use both Rails and Play at my day job.


But Play is sorta of a response to Django/Rails/Sinatra-like that came before, right?

Maybe there's a legacy effect here.


Sure, but that doesn't mean it doesn't exist.

There are several pretty light-weight ways to make both action- and API-oriented back ends on the JVM now, even in Java. (Although I prefer different JVM languages.)


2. JNI debug is a bit of pain probably. But Java/Groovy/etc much easier to debug, compared to, say, Python

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


> 2. JNI debug is a bit of pain probably. But Java/Groovy/etc much easier to debug, compared to, say, Python

Woah! How is Java/Groovy/etc easier to debug than Python?? In Python you just add the following line wherever you want to debug:

  import ipdb; ipdb.set_trace()


I was never managed to debug python code :( Maybe i'm doing something wrong. Never mind, I didn't want to offend python, it's only language I like besides jvm languages.

On other hand on JVM you don't even need such line, all works out of box, w/o code modification, never had any problem. At least with java and groovy


2. Groovy's stack traces are the joke of the JVM community. It's not easy to debug at all.

5. Grails adoption is tumbling. Not many places are starting new projects in Grails, or even upgrading from 2.x to 3.


2. stacktraces != debug. I don't actually see any difference with java stacktrace (only that it contains groovy classes, but it's still exactly same format). I mean tools for debug, like debug in IDE (look at Intellij IDEA, very powerful in debug), or JMX, take a look at VisualVM and profiling tools. There're many different tools. It's not just stacktrace.

5. Agree, not so popular that plain Spring maybe. But still, we're talking about features, right? not amount of projects on prod. Grails is pretty comparable to Rails/Django, in terms of features. Also, version 3 is too new, it requires to rewrite a lot of stuff to migrate. It takes time.


As much as most nerds would like to believe otherwise, people working with technology are not that different from other industries.

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.


I am not a Java programmer, but I thought the platform was quite trendy in the form of Scala or Clojure.


Yep. Scala and Clojure brought life back to the JVM, being JVM-friendly dialects of Haskell and Lisp respectively. If it weren't for them, the JVM would already be sinking under the oppressive weight of Java and Groovy.


This. Java (the platform) is absolutely not out of fashion, only Java (the language) is - though since Java8, this is not as pronounced anymore.


I think that the APIs behind Rhino were a real hindrance, as was performance.


That and the SWT layer around it.


Among my peers, everybody steers clear of Java and the JVM because of Oracle. We're not lawyers, we're engineers. We don't really quite understand what would happen if we make it big with Oracle.

Having that tumor attached to Java and the JVM taints it for everybody I know.


That. Pretty much why I would steer clear of anything Oracle related. I won't even begin to go into technical pros and cons - Java and mySql are pretty much off the drawing board.


IBM gave up their VM (J9) and now uses OpenJDK as their primary VM, on which they build many, many enterprise products. I think they're about as "big" as you can hope to become. If Oracle does anything nefarious preventing someone from using the JVM in a commercial fashion, I'd imagine IBM's army of litigators would be the first to submit their grievances to whichever civil court held jurisdiction. Historically IBM been a huge OSS contributor over the last 15 years- starting with Eclipse in 2001.

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.


But Oracle did win a patent suit against Google for Android's implementation of the JVM ABI.


If Oracle, then why MySQL is so popular in web development?


The obvious answer is that Oracle didn't always own MySQL. The fact that they own them now is a good enough reason to stay away on a new project but maybe not a good enough reason to port.


That is interesting, but again, we steer away from MySQL as well.


Well that's why God invented OpenJDK.


"Deployment is simple."

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.


"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."

Tell me you've seen this:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...


Thanks for the link. That made my day. =)

Here's a more realistic comparison between classic Java OOP design vs the more data-oriented approach to design encouraged in functional languages like Clojure for a simple board game:

https://www.youtube.com/watch?v=Tb823aqgX_0

TL;DW:

The classic OOP design of the board game ended up with 22 classes, 11 interfaces, 1 enum in total, with 271 lines of pure skeleton code with no implementation of any game logic whatsoever. The class diagram can be seen here for a better sense of the complexity involved: https://youtu.be/Tb823aqgX_0?t=688

The data-oriented design had 31 functions, longest of which is 7 lines, with a grand total of 144 lines of code that implements the entirety of the game logic.


Anecdote: Deploying a single jar generated with lein uberjar for clojure project is really simple.


Deployment with modern Java platforms/frameworks is simple. With Java EE you can create a runnable fat JAR just by running `mvn package` with WildFly Swarm. Spring Boot also has that capability and Payara Micro lets you deploy any existing WAR just by adding it as a command-line parameter.

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.


How do you deploy that to a server, let's say Digital Ocean? What kind of http server, proxies? Who/what starts and supervises the processes?


There are docker containers available for most of these. Spring Boot is made by Pivotal too, so has native CloudFoundry support if you want a PaaS. Docker is likely the most portable, but if you're happy writing an init.d start script or something you'd just need to call: java -jar /path/to/myapp.jar


Java (the language and the platform) is my #1 choice for almost everything I do.

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.


There is a non-obvious barrier to entry when it comes to the JVM, and that is learning the tools to performance tune a JVM in a production environment.

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.


Java8 has removed permgen, which was the only parameter that was essential as it put a hard cap on the size of the app you can build. With that gone, the JVM running with defaults will run laps around any scripting language, and any additional tuning is just more cake.

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...


I've been playing a bit with G1 and I'm still not 100% convinced that it's better than CMS. That said, it is nice to finally be rid of PermGen etc.


You're not wrong, but deployment is rarely simple. And there are gotchas in every environment I've ever worked with.

It's just a different set of skills to pick up, no different from any others.


Take a look at spring-boot.

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.


> And the basic jvm settings will get someone a long ways

But when it all goes tits-up it is a lot harder to work out why.

Also, I'd forgotten just how much i hated annotations. And now I need eye bleach :/

I like spark because it maps very closely to Sinatra in ruby, and doesn't require much additional support.


> But when it all goes tits-up it is a lot harder to work out why.

How so? Maybe you're just more comfortable with a different environment?


Yes, which is pretty much the answer to the original "why.". Different skill sets. You can't necessarily compare two wholly different stacks and say one is just as good as the other so why don't you use mine when there is accumulated knowledge associated with both. I have seen people arguing that rails is hard to set up in this thread, too, which seems really strange to anybody who doesn't consider setting up homebrew and rvm a burden. People have different things they have done and are familiar with and are productive at doing again. I think that is the complete answer to the thread.


Well also the documentation for that is really sparse. Years ago I messed around a lot with JRuby and I found this Xmx flag. So every time I had out of memory problems after, tuning Xmx worked just fine. ;) I always wondered why it's such a "hidden" parameter...

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.


I think people should just use what they're comfortable with and what is the best fit for the problem.

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.


1. Oracle.

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.


> A lot of people don't trust JIT and especially GC to do their jobs well.

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.


Point's waaaaaay over there, dude. This isn't about what is or should be. It's about what people perceive and how that affects their decisions. People who've been programming twice as long as the JVM has existed might still have a few funny ideas about it.


Fair enough.


I'm going to say something that'll probably be controversial, but screw it.

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. ^_^


> You don't see a lot of twentysomethings ... thinking there's a lot of opportunity there to make their mark

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.


There's something to what you're saying.

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.


> Java, Kotlin, Ceylon, Scala, OCaml-Java

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.


Not really sure about the JVM's tuned memory usage but for web applications, you likely won't come near 800MB with Python.

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.


It's Cherrypy that sucks up memory like there's no tomorrow. Not sure why. Thing is, you can run the JVM on a lot less than the default settings. JVM isn't nearly as memory hungry as people think. It's just all the enterprise crap you get with frameworks such as jboss makes it bloated. But the same thing is true for Python. Try running OpenERP on anything less than 10gb.


A small nitpick, but:

> 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.


(And if there are hundreds that you actually need to pay attention to, you probably did something wrong. Even in its heyday, XML proliferation like that is unusual and suspect.)


Java's memory/object allocation/instantiation is quite good.


One of the reasons I think the standard Java project became too complex.

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.


This.

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.


Just my recollections of java dev from about 2yrs ago...

Maven was complex, with too many 'concepts' for a build system. It was a revelation when I discovered dependency download and jar creation through apache ivy. Did Gradle take off?

Tomcat in turn had problems too, I recall JBoss was a little more robust, but also complex.

I also found hibernate/spring to be confounded by differences between versions - the XML config (of which there was a lot) tended to change in format quite a bit, and there was an added complexity in figuring out how to get code, and xml, or even code-from-xml to behave intuitively. It felt like a massive ORM, written in XML and annotated java...


This is a huge part of it. I was a Java programmer for almost ten years, and it is wholly opinion but most of those tools are inelegant and cumbersome. I realized most of the code I was writing was boilerplate or even worse, XML configuration of code.


Why would someone prefer Node.JS to JVM stack for side projects?

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.


Setting aside the effects of hype, hipness and herd -iness..

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.


1. I don't consider Java stack as the most agile stack. 2. I think companies which use java are not that friendly with the open-source paradigm. Then, java community is not as huge as ruby, python, js communities. 3. There isn't a powerful framework in constant evolution and supported by thousands of people.


All of your points are off:

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.


(1) without any reasons doesn't seem particularly meaningful. There are plenty of "agile" options on the JVM.

(2) I find the exact opposite; companies that use Java are very often huge contributors to the Java OSS ecosystem. And the Java community is giant because it's all over the place.

(3) Maybe you're not familiar with Spring, the canonical example of a huge ecosystem with tens of thousands of users, a very active development community, etc.

On point (3) I'd agree that the most agile environments have a smaller number of active contributors precisely because goliaths like Spring have so much mindshare. At the same time, I don't consider that a huge drawback, either: the people involved in the better, leaner frameworks are, in general, hugely smart.


As far as I can tell, Clojure is pretty seriously popular. Before Clojure, and before Java 8, I wasn't attracted to the JVM very much at all, because I didn't enjoy writing Java code, I am seriously allergic to startup times, and I like my tools to fit in nicely in a GNU/Linux environment. I'm not a huge Clojure fan either, but I don't mind working with it. On a subconscious level I feel like Java is controlled by corporate leviathans that kind of terrify me, but I don't know how true this is.


There are lots of good startups with scala/play framework as their stack


It was very popular in the late 90s and early 2000s. A lot of stuff was built on Tomcat/JSP/JBoss foundations, and this drove the expansion of Apache Java projects. But time to market is everything, hence the rise of Ruby on Rails & Django 10 years ago.


I am also a fan of the JVM. That's why I made my full stack framework JVM based:

https://github.com/zubairq/AppShare


I am a fan of the JVM.

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.


As of JDK 7 OpenJDK and Oracle JDK can be considered equal.

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


If I recall correctly, there is a environment variable you can set that implies you agree to it and the installer will not ask for manual confirmation.


The issue with accepting Oracle's license is that you're accepting a license from the largest psychopath that produces software.


I do front end web development for a place that uses java on the back end. The time between when I hit deploy to the time I can refresh and see new code in my browser is too long. Usually by the time it is ready I have gotten distracted and ended up on HN.

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.


To be fair there are quite a lot of Scala based projects and startups.


just tried to get my ruby project running on jruby. It's not a drop in replacement unfortunately, especially with database connectors. I think it makes sense if you're familiar with the Java ecosystem, but a lot of people aren't.


1. Cause it's not trendy or cool.

2. People are more familiar with other languages and their ecosystems (Javascript) ?

3. For reasons (real or imaginary), they don't like Java or whichever JVM language you've listed.


You can throw in Hivemind (www.crudzilla.com) as well...an open source polyglot web development platform for the JVM...It makes it very easy to use various JVM languages to build web apps.


Hanging out at HN you could be excused for thinking that Java/C# don't exist. It's part of the charm.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

For every advantage you cite above there's a more interesting blog post to be written using a newer tech or non-JVM language. Or a far simpler blog post that doesn't require "step 1: install Eclipse and Kotlin."

But there are plenty of articles about JVM and .NET stuff.


Similarly you would think that PHP doesn't exist. Whatever one may think of it, PHP runs the majority of websites (I've seen various estimates in the 80% range).


There's a whole lotta CMS, Wiki, and storefront systems out there. And many of the big names there - WordPress, Drupal, MediaWiki, etc - all run on PHP.

We tend to live in a world of custom-coded dynamic websites, while many needs can be filled adequately by a static page or off-the-shelf package like the above. They're not sexy, but they work.


Many programming language can build those same sites using template DSLs ala haml. PHP is like a template DSL without the host language. While PHP is in many ways mature, why start from there now?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: