8 ms·

Ask HN: Why don't more web projects start with a JVM stack?

• mbrock 11y ago
  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.
• PaulHoule 11y ago
  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.
  • malfist 11y ago
    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.
    • cyphar 11y ago
      The issue with accepting Oracle's license is that you're accepting a license from the largest psychopath that produces software.
  • adamzegelin 11y ago
    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
• jryan49 11y ago
  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.
• jakozaur 11y ago
  To be fair there are quite a lot of Scala based projects and startups.
• sergiotapia 11y ago
  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.
  • harel 11y ago
    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.
  • iheartmemcache 11y ago
    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.
    • cyphar 11y ago
      But Oracle did win a patent suit against Google for Android's implementation of the JVM ABI.
  • goldbrick 11y ago
    Well that's why God invented OpenJDK.
  • splix 11y ago
    If Oracle, then why MySQL is so popular in web development?
• osullivj 11y ago
  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.
• codeduck 11y ago
  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.
  • matwood 11y ago
    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.
    • codeduck 11y ago
      > 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.
      • 67726e 11y ago
        > 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?
        • hamburglar 11y ago
          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.
• neel8986 11y ago
  There are lots of good startups with scala/play framework as their stack
• tacos 11y ago
  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.html 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.
  • excitom 11y ago
    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).
    • paulmd 11y ago
      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.
      • Chris2048 11y ago
        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?
• rglullis 11y ago
  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.
  • rileymat2 11y ago
    I am not a Java programmer, but I thought the platform was quite trendy in the form of Scala or Clojure.
    • MrBuddyCasino 11y ago
      This. Java (the platform) is absolutely not out of fashion, only Java (the language) is - though since Java8, this is not as pronounced anymore.
    • vorg 11y ago
      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.
  • jsight 11y ago
    I think that the APIs behind Rhino were a real hindrance, as was performance.
    • ashneo76 11y ago
      That and the SWT layer around it.
• mosburger 11y ago
  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 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. ^_^
  • dandrick 11y ago
    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.
• yazriel 11y ago
  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.
• vardump 11y ago
  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.
• rb808 11y ago
  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.
  • kisamoto 11y ago
    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.
    • Chris2048 11y ago
      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...
  • thescribe 11y ago
    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.
• pfitzsimmons 11y ago
  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...
  • MoOmer 11y ago
    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.
    • ericfrederich 11y ago
      I believe Django also works under Jython
      • 11y ago
• notzorbo3 11y ago
  > 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.
  • codeduck 11y ago
    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.
    • davelnewton 11y ago
      (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.)
• Juliate 11y ago
  "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.
  • Heliosmaster 11y ago
    Anecdote: Deploying a single jar generated with lein uberjar for clojure project is really simple.
  • mcroft 11y ago
    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.
    • ricardobeat 11y ago
      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?
• xxdiamondxx 11y ago
  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.
• xeviknal 11y ago
  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.
  • davelnewton 11y ago
    (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.
  • 5ersi 11y ago
    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/ https://projects.apache.org/), IBM (http://www.ibm.com/developerworks/java/find/projects/ http://www.ibm.com/developerworks/java/find/projects/). Java is #2 OSS language on GitHub (http://githut.info/ http://githut.info/). About Java community not being as huge as Ruby, Python, JS: http://www.tiobe.com/index.php/content/paperinfo/tpci/ 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.
• chajath 11y ago
  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.
  • deleted 11y ago
    [deleted]
• bcg1 11y ago
  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.
• Edmond 11y ago
  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.
• zubairq 11y 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 https://github.com/zubairq/AppShare
• stonemetal 11y ago
  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.
• notacoward 11y ago
  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.
  • azth 11y ago
    > 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.
    • notacoward 11y ago
      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.
      • azth 11y ago
        Fair enough.