11 ms·

The JVM is a treasure just sitting there waiting to be rediscovered. It really is a shame that there is so much noise and unnecessary complexity around using i

The JVM is a treasure just sitting there waiting to be rediscovered. It really is a shame that there is so much noise and unnecessary complexity around using it.

taeric 10y ago
This is true of most any environment. When speed is a requirement, people can make things fast. For most of us. Speed is not a requirement.
- gozur88 10y ago
  Or it is but the slow part is the database. I wonder what percentage of business applications are some kind of RDB CRUD system - get some rows, put them in a table, let the user update or delete, send them on to the next system... When you're doing that kind of application the overhead the language adds is lost in the DB noise floor.
mablap 10y ago
For me, as an outsider, the JVM looks a bit like .NET: this huge, extremely complex codebase which does everything and anything, very optimized and comes with great tools. But to me that is a problem. Even though the JVM could do X or Y better than another platform, just the time spent learning about it feels like a waste of time, as I could already be productive in another language which is less optimized and less complex, but much faster to develop with. It seems just learning to use a Java IDE is a job in itself. I do mathematical modeling, by the way. If I need speed, I use optimised libraries. So I might not be the target user of Java, although I've often heard good things about it for scientific computing.
- formula1 10y ago
  Java really isnt that bad. I think the biggest issue surrounding it is a package manager, better ui/templating language and a more obvious/documented import and linking api. Outside of that it isnt too bad Edit : also events were annoying in 7. I dont have a particular interest in creating a class just to act as a listener. I believe 8 introduced lambdas which is nice
  - aeroevan 10y ago
    Java 8 with lambdas and streams is actually fairly nice to program. It's still Java, but it is much better than it was before Java 8. Maven is complicated, but Java 9 with project jigsaw might help things out on the packaging side. I don't do ui or any templating in java (analytics and simulations) so don't really know what's going on in those areas.
    - agibsonccc 10y ago
      I'd consider maybe looking at gradle then. The awesome thing about maven is it is os agnostic and is at least stable. Most of the jvm libs are stored in maven central.
      - _asummers 10y ago
        Gradle is fantastic to work with. Groovy is nice when you need it, but the DSL is just much better to work with than Maven.
        vorg 10y ago
        Gradle 3, due out soon, will use Kotlin instead of Apache Groovy as its prefered language for writing build scripts and plugins.
        cel1ne 10y ago
        ...which will make it completely typesafe.
        deleted 10y ago
        [deleted]
        _asummers 10y ago
        Ooooh how exciting! I like that a lot. I can find this out myself, but what do they plan on doing with existing Groovy plugins for gradle pipelines?
- coldtea 10y ago
  >Even though the JVM could do X or Y better than another platform, just the time spent learning about it feels like a waste of time, as I could already be productive in another language which is less optimized and less complex, but much faster to develop with. It seems just learning to use a Java IDE is a job in itself. Any other comparable language (basically with static types) would want to use would require an IDE too. Of course you can write C or C++ or Rust, etc without one, but you'll be as unproductive as writing Java without one (nothing inherently IDE-demanding that Java has compared to these). Or at least configuring Emacs for the task, which can be a full job in itself too. Now, if you talk about something like Python or JS etc, maybe. But the JVM != Java, and those languages run there too. Plus, there's nothing really to "configure" to run the JVM, any more than you need to configure Python. There are GC and other options, but you can ignore that for the same (or even more) time than you could in Python.
  - agibsonccc 10y ago
    Java is great for a lot of things. That's why you see large distributed systems projects that power large companies being written in java. See presto at facebook or kafka at linkedin for example. It's not as good at for loops though. If you need it for hpc you should still be using c++ underneath somewhere for simd instructions and other neat tricks only available in lower level languages. I look at java as a better python or: "frontend to c++ code"
    - _asummers 10y ago
      Even with HPC (the Azul Systems folks would object to your claim), you just have to code in a foreign style of not allocating memory. Once you get that style in your tight loops, Java can run very very fast.
      - agibsonccc 10y ago
        I've debated with cliff click about this before actually. There was a consensus that the JVM can support certain kinds of operations for that stuff (eg: basic SIMD) with that coding style. It can't do everything though. It's a lot better to go JNI for 99% of this stuff though. I'd also love to know when java has first class support for gpus (you know where hpc actually runs?). I'll continue relying on c++ for that stuff. It's also what nvidia supports first class. If you have any first hand experience with this stuff I'd also love to hear your thoughts on this as well. Better yet: Here's a mailing list where these people (including me) sit. Go ahead and peruse it. I've learned a lot being on here. I'm STILL of the opinion the JVM can't do most of these things well after having run the numbers: https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy For cpu I'll be sticking with openmp for the long term. Don't even get me started with cpu specific optimizations (eg: different intel generations)
- agibsonccc 10y ago
  We do scientific computing on the jvm (mainly deep learning). We wrote: https://nd4j.org https://nd4j.org which immitates numpy and co on the jvm with builtin gpu support and linking against blas like other frameworks. We also hand implemented a lot of ufuncs for you in c++. It's mainly oriented towards dense atm though. Sparse will come at some point but it hasn't been a big feature for us. It uses: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp underneath. Happy to answer questions!
  - mablap 10y ago
    Yeah, I've actually heard about ND4J and was interested in learning about it. But as I said in my parent post, Java seems (from the outside) as this huge unwieldy language that is hard to get into. What could I do with Java/ND4J in scientific computing that I couldn't do with other packages, or that is much easier/better done on the JVM?
    - agibsonccc 10y ago
      Yeah and it might be. We're targeting the big data folks with this framework frankly. Anything that does static typing might be overkill for just running matrix math. I created nd4j with the intent of having the same primitives and programming model accessible to me for production environments and also affording me the same privileges of optimizing things in c with nice clean abstractions. scala MIGHT be easier which is why we created nd4s: https://github.com/deeplearning4j/nd4s https://github.com/deeplearning4j/nd4s The JVM and the developers who use it are mainly people with salaries soliving a very specific class of problems not people publishing papers. The one exception to this I've seen is the NLP community. I'd argue it's just a different audience who needs the things the jvm has, eg: static typing, integrations with libraries, etc. For large codebases you really can't beat jvm tooling..if you just need a click repl and throwaway code? It might be a bit much if you don't already know it.
- digler999 10y ago
  > which does everything and anything, same here. Until I wrote my first android app, used JPG images in a loop, figured "well, they run out of scope, and everthing is a reference, and java has 'garbage collection', so everything should be fine, right?". Wrong. Ran out of memory. The one time I thought I could rely on the JVM and all the delicious java-ness, it lets me down. I'll stick to C++ where WYSIWYG.
  - namelezz 10y ago
    > Wrong. Ran out of memory Android VM(DVM) is different from the JVM we are usually talking about. When developing Android apps, you need to understand the life cycle of components to prevent memory leaking. Your issue may come from your poor understanding of Android platform.
    - digler999 10y ago
      > Your issue may come from your poor understanding of Android platform. possibly. But what is my responsibility as a developer ? If I learn a standardized language do I now have to learn the JVM/DVM standards of how its implemented ? Whats wrong with a destructor being called when an object goes out of scope and have its resources freed ? If I have to now worry about how the VM implements that, learning the language was useless.
      - pjmlp 10y ago
        Sure you have to. It is no different than having to learn what gcc, clang, Visual C, aCC, SunPro, xlc, icc ... do to your C code outside of what ANSI C specifies how it should behave. And even for those parts that the ANSI C specifies how it should behave, those compilers do not generate the 100% same code. Also one needs to know how the underlying OS and CPU handle that generated code as well. Specially interesting regarding the understanding of the underlying OS on UNIX platforms, is to learn how much the platform deviates from the POSIX specification in regards implementation specific semantics, because POSIX just like ANSI C, leaves platforms quite some freedom of implementation. Understanding the target platform is always required.
- ams6110 10y ago
  You've got that backwards. .NET was Microsoft's attempt to "embrace and extend" java. Early versions of C# were basically copy/paste compatible with Java.
rb2k_ 10y ago
Alternatively: any medium sized high throughput Java app needs somebody with a PhD in garbage collection tuning, because otherwise the app will just grind to a halt regularly :(
- eropple 10y ago
  Two things: - I became the JVM whisperer for a fairly large company a whole year out of college. JVM tuning is not that complex, nor is the Java memory model. Shipilev's talk on the JMM[1] is almost everything you could ever need to know, and you can refer to it when you need it. - That you actually can meaningfully tune the JVM GC is something you can't say about a lot of the alternatives. Like, I love the CLR, but the "self-tuning" nature of the garbage collector has bitten me more than once in the past. [1] - https://shipilev.net/blog/2014/jmm-pragmatics/ https://shipilev.net/blog/2014/jmm-pragmatics/
  - stevehiehn 10y ago
    Thanks for that link! Very timely. I have been trying to gain a solid understanding of the java memory model.
- mindcrime 10y ago
  It's not really that bad. And on the plus side, VisualVM helps a ton because you can connect to a running JVM and actually see what's happening with the garbage collector (among other things).
  - rb2k_ 10y ago
    I've seen high throughput apps doing 45 second "stop the world" garbage collection cycles because of high disk I/O and enabled GC logging (the process just sat there waiting for some I/O time to flush the GC log file). So in theory tuning GC isn't thaaaaaat complicated. In practice however I've seen horrible things :(
    - mindcrime 10y ago
wtbob 10y ago
> The JVM is a treasure just sitting there waiting to be rediscovered. It's the result of man-centuries (man-millennia?) of work, yes, and as a result is really, really impressive. But imagine if that much work had been put into something fundamentally great, like Smalltalk or Lisp, rather than something fundamentally okay like Java. > It really is a shame that there is so much noise and unnecessary complexity around using it. Very true. Java itself is not a terrible language (hence why I wrote 'fundamentally okay' above); it's the arcane, rococo, lunatic levels of ritual which surround it. Every time I look at Java code I'm reminded of some insane fantastic court in which one has to plead with the Minister of Small Affairs, make a sacrifice to the God of Bureaucracy, pay for a Token of Token-Paying, appeal to the good graces of the Wise Undersecretary of Vice-Small Affairs and finally spend a weekend climbing an Escher Staircase before an audience with the King, all just to get a scrap of toilet paper.
- _asummers 10y ago
  Java and the JVM are entirely separate beasts and should not be taken together. While most JVM code began as Java code, there are enough non-Java languages hosted on the JVM at this point that it should be looked at through the Java lens only.
  - desdiv 10y ago
    >...that it should be looked at through the Java lens only. I think you missed a "not" there.
    - _asummers 10y ago
      I did indeed. Good catch!
- niftich 10y ago
  (Edited to clarify that I think Java was good in the very beginning, less so in the middle, and is good once again) Java started off as the Golang of the 90s: small, simple, opinionated, statically-typed, in many ways state-of-the-art, and engineered to protect the programmer from doing bad things (either due to ignorance or will). It came with a batteries-included standard library. Then, in a quirk of fate, it became very popular. Though its library provided clean abstractions, you had to chain several of them together to actually accomplish anything: this is why it was so verbose. Everyone was writing Java, but no one was sharing Java, yet. Before Apache (Jakarta) Commons, no one bothered to make wrappers for basic stuff... just like how we were writing bad JS before jQuery or underscore came out. We were caught between our own experimentation, Sun's desire to take over the desktop, and companies like IBM and Oracle that wanted to ensure they could sell commercial support for big monolithic Java appservers. When the 'Design Patterns' book came out, someone should've made a framework, but instead we sprinkled AbstractStrategyFactoryBuilders everywhere because that's what the enterprise libraries did... and it read like a bad parody of object-oriented programming, but by now, we've learned our mistake. Now that bad APIs have fallen out of favor, Java EE is nearly abandoned, Spring brought some sanity but also forced us to consider why we're even thinking about convention over configuration, Java is much, much nicer. In the Maven, Github, CI world, we can -- environment and company policies permitting -- easily pull in libraries and frameworks that allow us to actually get stuff done at the correct level of abstraction.
mr_overalls 10y ago
Now that the CLR is getting more attention because of Microsoft's cross-platform efforts, how comparable is the CLR to the JVM, engineering-wise? I ask because, as a C# developer, I like C# as a language, but am jealous of Java's extensive libraries and the legendary engineering of the JVM. How likely is it that the CLR can serve as the basis for future Big Data projects like Hadoop or Spark?
- PeCaN 10y ago
  Unless you're doing something like high-frequency trading, I doubt you'll notice a difference between the CLR and the best JVMs.
- pjmlp 10y ago
  The best would be to do as we do. My employer works with both eco-systems, so we happen to jump between JVM and CLR all the time. Actually on my case, I am jealous that on .NET side I get the AOT compilers for free (NGEN, .NET Native, MDIL) instead of having to buy them, official unsafe, painless FFI, while I will need to wait for Java 10+ to use them on JVM based projects.
  - kuschku 10y ago
    For the JVM, look at the JNA instead of the JNI — that makes the FFI a lot saner.
mr_overalls 10y ago
Now that the CLR is getting more attention because of Microsoft's cross-platform efforts, how comparable is the CLR to the JVM, engineering-wise? I ask because, as a C# developer, I like C# as a language, but am jealous of Java's extensive libraries and the legendary engineering of the JVM. How likely is it that the CLR can serve as the basis for future Big Data projects like Hadoop or Spark?
bogomipz 10y ago
It sure is, 20 years and who only knows how many engineering hours have gone into it. What noise are you referring to?
maxpert 10y ago
> The JVM is a treasure just sitting there waiting to be rediscovered. So true, long long back when people were going NodeJS ape-sh*t I did some benchmarks proving JVM can blow V8 out of water any given day (URL if someone is intrested http://blog.creapptives.com/post/9924551244/the-node-redumption http://blog.creapptives.com/post/9924551244/the-node-redumpt...) and got trolled by NodeJS fanboys alot.
- chadscira 10y ago
  Cool article, Would be interesting to see these benchmarks updated :)
- emilsedgh 10y ago
  But nodejs was never really about JVM vs. V8 in the first place. It was about async io, handling everything in a process and a handful of threads, instead of spawning a new thread for every request (and paying for OS context switch). Of course in your article you mention Netty. But Nodejs is (still) the only ecosystem where everything is async (event-loop style), vs. Java Netty or Python Twisted, in which you only have a subset of libraries. Or am I mistaken?
  - wsargent 10y ago
    Akka, Play and Lagom are part of the Lightbend Reactive Platform -- everything's async from the ground up, built on the JVM and Scala. The authors put together the Reactive Manifesto: https://www.lightbend.com/blog/reactive-manifesto-20 https://www.lightbend.com/blog/reactive-manifesto-20
    - im_down_w_otp 10y ago
      That manifesto site drives me completely nuts. It reads like somebody is trying really, really, really hard to describe Erlang without actually saying, "Erlang".
    - deleted 10y ago
      [deleted]
brightball 10y ago
Kotlin might pull that off
technion 10y ago
A lot of this thread is in regard to development in Java, but a lot of the noise and "unnecessary complexity" also involves end user applications. I spent a lot of time supporting Java based desktop applications. I've seen a situation where a single organisation sells two products. And the installation guide basically says "these applications need an absolutely correct JRE version, down to the point release, or they will fail to run. And they will only use the system default, and don't have any concept of bundled Java. And they don't support the same version of Java, so our recommendation is to give users two desktops". And I know that's not Java's fault, but when a certain monopoly releases every single application with that anti-pattern, you get pretty sick of see null pointer exception errors because a user applied a (two year old) Java security update.
- cel1ne 10y ago
  I agree. I think a lot of the bad reputation of java comes from the user-visible parts, from slow swing etc.
  - oblio 10y ago
    Most Java software is enterprise and that stuff is famous for horrible UI/UX, regardless of language.
- slantedview 10y ago
  Complexity for the sake of complexity has badly tarnished the Java ecosystem's reputation. I feel like the community has countered that phase by creating new, smaller tools, more modular tools, similar to what exist in other ecosystems, but the foothold of bloated, overly complicated crap is still strong in the enterprise world. A simple rule of thumb is just don't use anything with the word "Spring" in it, and you're well on your way.

The JVM is a treasure just sitting there waiting to be rediscovered. It really is a shame that there is so much noise and unnecessary complexity around using it.

taeric 10y ago

This is true of most any environment. When speed is a requirement, people can make things fast. For most of us. Speed is not a requirement.

gozur88 10y ago
Or it is but the slow part is the database. I wonder what percentage of business applications are some kind of RDB CRUD system - get some rows, put them in a table, let the user update or delete, send them on to the next system... When you're doing that kind of application the overhead the language adds is lost in the DB noise floor.

mablap 10y ago

For me, as an outsider, the JVM looks a bit like .NET: this huge, extremely complex codebase which does everything and anything, very optimized and comes with great tools. But to me that is a problem. Even though the JVM could do X or Y better than another platform, just the time spent learning about it feels like a waste of time, as I could already be productive in another language which is less optimized and less complex, but much faster to develop with. It seems just learning to use a Java IDE is a job in itself. I do mathematical modeling, by the way. If I need speed, I use optimised libraries. So I might not be the target user of Java, although I've often heard good things about it for scientific computing.

formula1 10y ago
Java really isnt that bad. I think the biggest issue surrounding it is a package manager, better ui/templating language and a more obvious/documented import and linking api. Outside of that it isnt too bad Edit : also events were annoying in 7. I dont have a particular interest in creating a class just to act as a listener. I believe 8 introduced lambdas which is nice
- aeroevan 10y ago
  Java 8 with lambdas and streams is actually fairly nice to program. It's still Java, but it is much better than it was before Java 8. Maven is complicated, but Java 9 with project jigsaw might help things out on the packaging side. I don't do ui or any templating in java (analytics and simulations) so don't really know what's going on in those areas.
  - agibsonccc 10y ago
    I'd consider maybe looking at gradle then. The awesome thing about maven is it is os agnostic and is at least stable. Most of the jvm libs are stored in maven central.
    - _asummers 10y ago
      Gradle is fantastic to work with. Groovy is nice when you need it, but the DSL is just much better to work with than Maven.
      - vorg 10y ago
        Gradle 3, due out soon, will use Kotlin instead of Apache Groovy as its prefered language for writing build scripts and plugins.
        cel1ne 10y ago
        ...which will make it completely typesafe.
        deleted 10y ago
        [deleted]
        _asummers 10y ago
        Ooooh how exciting! I like that a lot. I can find this out myself, but what do they plan on doing with existing Groovy plugins for gradle pipelines?
coldtea 10y ago
>Even though the JVM could do X or Y better than another platform, just the time spent learning about it feels like a waste of time, as I could already be productive in another language which is less optimized and less complex, but much faster to develop with. It seems just learning to use a Java IDE is a job in itself. Any other comparable language (basically with static types) would want to use would require an IDE too. Of course you can write C or C++ or Rust, etc without one, but you'll be as unproductive as writing Java without one (nothing inherently IDE-demanding that Java has compared to these). Or at least configuring Emacs for the task, which can be a full job in itself too. Now, if you talk about something like Python or JS etc, maybe. But the JVM != Java, and those languages run there too. Plus, there's nothing really to "configure" to run the JVM, any more than you need to configure Python. There are GC and other options, but you can ignore that for the same (or even more) time than you could in Python.
- agibsonccc 10y ago
  Java is great for a lot of things. That's why you see large distributed systems projects that power large companies being written in java. See presto at facebook or kafka at linkedin for example. It's not as good at for loops though. If you need it for hpc you should still be using c++ underneath somewhere for simd instructions and other neat tricks only available in lower level languages. I look at java as a better python or: "frontend to c++ code"
  - _asummers 10y ago
    Even with HPC (the Azul Systems folks would object to your claim), you just have to code in a foreign style of not allocating memory. Once you get that style in your tight loops, Java can run very very fast.
    - agibsonccc 10y ago
      I've debated with cliff click about this before actually. There was a consensus that the JVM can support certain kinds of operations for that stuff (eg: basic SIMD) with that coding style. It can't do everything though. It's a lot better to go JNI for 99% of this stuff though. I'd also love to know when java has first class support for gpus (you know where hpc actually runs?). I'll continue relying on c++ for that stuff. It's also what nvidia supports first class. If you have any first hand experience with this stuff I'd also love to hear your thoughts on this as well. Better yet: Here's a mailing list where these people (including me) sit. Go ahead and peruse it. I've learned a lot being on here. I'm STILL of the opinion the JVM can't do most of these things well after having run the numbers: https://groups.google.com/forum/#!forum/mechanical-sympathy https://groups.google.com/forum/#!forum/mechanical-sympathy For cpu I'll be sticking with openmp for the long term. Don't even get me started with cpu specific optimizations (eg: different intel generations)
agibsonccc 10y ago
We do scientific computing on the jvm (mainly deep learning). We wrote: https://nd4j.org https://nd4j.org which immitates numpy and co on the jvm with builtin gpu support and linking against blas like other frameworks. We also hand implemented a lot of ufuncs for you in c++. It's mainly oriented towards dense atm though. Sparse will come at some point but it hasn't been a big feature for us. It uses: https://github.com/bytedeco/javacpp https://github.com/bytedeco/javacpp underneath. Happy to answer questions!
- mablap 10y ago
  Yeah, I've actually heard about ND4J and was interested in learning about it. But as I said in my parent post, Java seems (from the outside) as this huge unwieldy language that is hard to get into. What could I do with Java/ND4J in scientific computing that I couldn't do with other packages, or that is much easier/better done on the JVM?
  - agibsonccc 10y ago
    Yeah and it might be. We're targeting the big data folks with this framework frankly. Anything that does static typing might be overkill for just running matrix math. I created nd4j with the intent of having the same primitives and programming model accessible to me for production environments and also affording me the same privileges of optimizing things in c with nice clean abstractions. scala MIGHT be easier which is why we created nd4s: https://github.com/deeplearning4j/nd4s https://github.com/deeplearning4j/nd4s The JVM and the developers who use it are mainly people with salaries soliving a very specific class of problems not people publishing papers. The one exception to this I've seen is the NLP community. I'd argue it's just a different audience who needs the things the jvm has, eg: static typing, integrations with libraries, etc. For large codebases you really can't beat jvm tooling..if you just need a click repl and throwaway code? It might be a bit much if you don't already know it.
digler999 10y ago
> which does everything and anything, same here. Until I wrote my first android app, used JPG images in a loop, figured "well, they run out of scope, and everthing is a reference, and java has 'garbage collection', so everything should be fine, right?". Wrong. Ran out of memory. The one time I thought I could rely on the JVM and all the delicious java-ness, it lets me down. I'll stick to C++ where WYSIWYG.
- namelezz 10y ago
  > Wrong. Ran out of memory Android VM(DVM) is different from the JVM we are usually talking about. When developing Android apps, you need to understand the life cycle of components to prevent memory leaking. Your issue may come from your poor understanding of Android platform.
  - digler999 10y ago
    > Your issue may come from your poor understanding of Android platform. possibly. But what is my responsibility as a developer ? If I learn a standardized language do I now have to learn the JVM/DVM standards of how its implemented ? Whats wrong with a destructor being called when an object goes out of scope and have its resources freed ? If I have to now worry about how the VM implements that, learning the language was useless.
    - pjmlp 10y ago
      Sure you have to. It is no different than having to learn what gcc, clang, Visual C, aCC, SunPro, xlc, icc ... do to your C code outside of what ANSI C specifies how it should behave. And even for those parts that the ANSI C specifies how it should behave, those compilers do not generate the 100% same code. Also one needs to know how the underlying OS and CPU handle that generated code as well. Specially interesting regarding the understanding of the underlying OS on UNIX platforms, is to learn how much the platform deviates from the POSIX specification in regards implementation specific semantics, because POSIX just like ANSI C, leaves platforms quite some freedom of implementation. Understanding the target platform is always required.
ams6110 10y ago
You've got that backwards. .NET was Microsoft's attempt to "embrace and extend" java. Early versions of C# were basically copy/paste compatible with Java.

rb2k_ 10y ago

Alternatively: any medium sized high throughput Java app needs somebody with a PhD in garbage collection tuning, because otherwise the app will just grind to a halt regularly :(

eropple 10y ago
Two things: - I became the JVM whisperer for a fairly large company a whole year out of college. JVM tuning is not that complex, nor is the Java memory model. Shipilev's talk on the JMM[1] is almost everything you could ever need to know, and you can refer to it when you need it. - That you actually can meaningfully tune the JVM GC is something you can't say about a lot of the alternatives. Like, I love the CLR, but the "self-tuning" nature of the garbage collector has bitten me more than once in the past. [1] - https://shipilev.net/blog/2014/jmm-pragmatics/ https://shipilev.net/blog/2014/jmm-pragmatics/
- stevehiehn 10y ago
  Thanks for that link! Very timely. I have been trying to gain a solid understanding of the java memory model.
mindcrime 10y ago
It's not really that bad. And on the plus side, VisualVM helps a ton because you can connect to a running JVM and actually see what's happening with the garbage collector (among other things).
- rb2k_ 10y ago
  I've seen high throughput apps doing 45 second "stop the world" garbage collection cycles because of high disk I/O and enabled GC logging (the process just sat there waiting for some I/O time to flush the GC log file). So in theory tuning GC isn't thaaaaaat complicated. In practice however I've seen horrible things :(
  - mindcrime 10y ago

wtbob 10y ago

> The JVM is a treasure just sitting there waiting to be rediscovered. It's the result of man-centuries (man-millennia?) of work, yes, and as a result is really, really impressive. But imagine if that much work had been put into something fundamentally great, like Smalltalk or Lisp, rather than something fundamentally okay like Java. > It really is a shame that there is so much noise and unnecessary complexity around using it. Very true. Java itself is not a terrible language (hence why I wrote 'fundamentally okay' above); it's the arcane, rococo, lunatic levels of ritual which surround it. Every time I look at Java code I'm reminded of some insane fantastic court in which one has to plead with the Minister of Small Affairs, make a sacrifice to the God of Bureaucracy, pay for a Token of Token-Paying, appeal to the good graces of the Wise Undersecretary of Vice-Small Affairs and finally spend a weekend climbing an Escher Staircase before an audience with the King, all just to get a scrap of toilet paper.

_asummers 10y ago
Java and the JVM are entirely separate beasts and should not be taken together. While most JVM code began as Java code, there are enough non-Java languages hosted on the JVM at this point that it should be looked at through the Java lens only.
- desdiv 10y ago
  >...that it should be looked at through the Java lens only. I think you missed a "not" there.
  - _asummers 10y ago
    I did indeed. Good catch!
niftich 10y ago
(Edited to clarify that I think Java was good in the very beginning, less so in the middle, and is good once again) Java started off as the Golang of the 90s: small, simple, opinionated, statically-typed, in many ways state-of-the-art, and engineered to protect the programmer from doing bad things (either due to ignorance or will). It came with a batteries-included standard library. Then, in a quirk of fate, it became very popular. Though its library provided clean abstractions, you had to chain several of them together to actually accomplish anything: this is why it was so verbose. Everyone was writing Java, but no one was sharing Java, yet. Before Apache (Jakarta) Commons, no one bothered to make wrappers for basic stuff... just like how we were writing bad JS before jQuery or underscore came out. We were caught between our own experimentation, Sun's desire to take over the desktop, and companies like IBM and Oracle that wanted to ensure they could sell commercial support for big monolithic Java appservers. When the 'Design Patterns' book came out, someone should've made a framework, but instead we sprinkled AbstractStrategyFactoryBuilders everywhere because that's what the enterprise libraries did... and it read like a bad parody of object-oriented programming, but by now, we've learned our mistake. Now that bad APIs have fallen out of favor, Java EE is nearly abandoned, Spring brought some sanity but also forced us to consider why we're even thinking about convention over configuration, Java is much, much nicer. In the Maven, Github, CI world, we can -- environment and company policies permitting -- easily pull in libraries and frameworks that allow us to actually get stuff done at the correct level of abstraction.

mr_overalls 10y ago

Now that the CLR is getting more attention because of Microsoft's cross-platform efforts, how comparable is the CLR to the JVM, engineering-wise? I ask because, as a C# developer, I like C# as a language, but am jealous of Java's extensive libraries and the legendary engineering of the JVM. How likely is it that the CLR can serve as the basis for future Big Data projects like Hadoop or Spark?

PeCaN 10y ago
Unless you're doing something like high-frequency trading, I doubt you'll notice a difference between the CLR and the best JVMs.
pjmlp 10y ago
The best would be to do as we do. My employer works with both eco-systems, so we happen to jump between JVM and CLR all the time. Actually on my case, I am jealous that on .NET side I get the AOT compilers for free (NGEN, .NET Native, MDIL) instead of having to buy them, official unsafe, painless FFI, while I will need to wait for Java 10+ to use them on JVM based projects.
- kuschku 10y ago
  For the JVM, look at the JNA instead of the JNI — that makes the FFI a lot saner.

mr_overalls 10y ago

bogomipz 10y ago

It sure is, 20 years and who only knows how many engineering hours have gone into it. What noise are you referring to?

maxpert 10y ago

> The JVM is a treasure just sitting there waiting to be rediscovered. So true, long long back when people were going NodeJS ape-sh*t I did some benchmarks proving JVM can blow V8 out of water any given day (URL if someone is intrested http://blog.creapptives.com/post/9924551244/the-node-redumption http://blog.creapptives.com/post/9924551244/the-node-redumpt...) and got trolled by NodeJS fanboys alot.

chadscira 10y ago
Cool article, Would be interesting to see these benchmarks updated :)
emilsedgh 10y ago
But nodejs was never really about JVM vs. V8 in the first place. It was about async io, handling everything in a process and a handful of threads, instead of spawning a new thread for every request (and paying for OS context switch). Of course in your article you mention Netty. But Nodejs is (still) the only ecosystem where everything is async (event-loop style), vs. Java Netty or Python Twisted, in which you only have a subset of libraries. Or am I mistaken?
- wsargent 10y ago
  Akka, Play and Lagom are part of the Lightbend Reactive Platform -- everything's async from the ground up, built on the JVM and Scala. The authors put together the Reactive Manifesto: https://www.lightbend.com/blog/reactive-manifesto-20 https://www.lightbend.com/blog/reactive-manifesto-20
  - im_down_w_otp 10y ago
    That manifesto site drives me completely nuts. It reads like somebody is trying really, really, really hard to describe Erlang without actually saying, "Erlang".
  - deleted 10y ago
    [deleted]

brightball 10y ago

Kotlin might pull that off

technion 10y ago

A lot of this thread is in regard to development in Java, but a lot of the noise and "unnecessary complexity" also involves end user applications. I spent a lot of time supporting Java based desktop applications. I've seen a situation where a single organisation sells two products. And the installation guide basically says "these applications need an absolutely correct JRE version, down to the point release, or they will fail to run. And they will only use the system default, and don't have any concept of bundled Java. And they don't support the same version of Java, so our recommendation is to give users two desktops". And I know that's not Java's fault, but when a certain monopoly releases every single application with that anti-pattern, you get pretty sick of see null pointer exception errors because a user applied a (two year old) Java security update.

cel1ne 10y ago
I agree. I think a lot of the bad reputation of java comes from the user-visible parts, from slow swing etc.
- oblio 10y ago
  Most Java software is enterprise and that stuff is famous for horrible UI/UX, regardless of language.
slantedview 10y ago
Complexity for the sake of complexity has badly tarnished the Java ecosystem's reputation. I feel like the community has countered that phase by creating new, smaller tools, more modular tools, similar to what exist in other ecosystems, but the foothold of bloated, overly complicated crap is still strong in the enterprise world. A simple rule of thumb is just don't use anything with the word "Spring" in it, and you're well on your way.