6 ms·

Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.

by hanief 11y ago

threeseed 11y ago
That comes from the fact that Java takes quite a while to startup. It is going to be hopefully fixed in Java 9 where the platform becomes more modular. But that issue is what caused Java to have such a terrible reputation when apps were run on the desktop.
- hugi 11y ago
  Probably part of it, but for me, the somewhat uncanny valley-ish non-standard look and behaviour of Swing UIs (and AWT before that) is the biggest turn off. Using java apps on the desktop feels a little like using a keyboard with mittens.
  - saiya-jin 11y ago
    This is an issue of unskilled devs using ancient UI design approach, usually not even bothering with skinning it. Things like bitTorrent were done in Java (correct me if I'm wrong), and you have no clue which language they are done in when looking at UI. But this a bit of extra effort, and for intranet apps, nobody usually bothers. Another reason for oh-not-so-windows-look of UI is something microsoft finally begun discovering - that there are other platforms than Windows. Java UI works anywhere where you have working JRE, and if you've ever seen Linux's KDE/GNOME/XFCE etc. then you might realize it ain't easy to come up with a cross-section between them. You need to hack things with Wine or similar to have it +-++ work the other way around (ie MFC app -> anywhere but MS world, and even there it might be tricky with all dll hell).
    - lmm 11y ago
      Standard bittorrent was in Python. Azureus was in Java and it felt significantly slower (than Python!) - it took so long to start it needed a splash screen, and you'd click a menu and wait for it to appear. Kind of an unfair comparison - the Python one just calls native Qt or Tk whereas the Java UI is actually written in Java - but it does colour the perception.
- mike_hearn 11y ago
  Startup time isn't that bad. It takes about 500 msec to get a window on the screen with the latest versions of Java and the JavaFX toolkit. Most of that is UI init. If you're doing command line apps it's much faster.
ghshephard 11y ago
Once you heat up the JVM, Java can run like a bat out of hell. And, if you don't run into GC problems, it's as fast as anything out there.
- sacado2 11y ago
  You can't fine-tune memory usage and can run into cache issues (or worse) if you deal with quite a lot of data, though.
  - lmm 11y ago
    > You can't fine-tune memory usage What do you mean by that? There are some very fine-grained tuning options if you really need them.
    - sacado2 11y ago
      Maybe I'm wrong, but I don't know how you can say you want, say, a list of objects of class Foo be in contiguous slots of memory, rather than having a list of references to objects. Because the latter is very cache-unfriendly. In go, you can say whether you want a []Foo or a []*Foo
      - lmm 11y ago
        You can do that "by hand" with buffers (and the HFT guys do) but yeah it's not easy or fun. C#-style struct types are supposedly coming in the next version.
  - threeseed 11y ago
    Wait. What ? I have never seen any piece of technology with more tuning options than the JVM. Especially given how dramatically different your apps perform with different combinations. It's akin to old wifes tales about which settings to use when. http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html http://www.oracle.com/technetwork/articles/java/vmoptions-js... And don't forget that much of big data is on the JVM e.g. Hadoop, Cassandra, HBase.
CookWithMe 11y ago
Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it. Two examples from my experience: JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0]. Hibernate is probably the worst offender. Well, the interface is somewhat nice: you don't have to care about loading objects from the database, Hibernate will load them for you. One object, one request at a time. Looking at the hundreds of generated SQL requests it's quite easy to figure out how you would write better SQL... but you don't write the SQL, Hibernate does :) The lesson IMO is: If you're writing everything from scratch, language performance is important. If you're using frameworks, the performance of the whole stack is way more important and one should probably compare benchmarks - or even real-world applications that are similar to ones use case - of the whole stack. [0] http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html
- vetler 11y ago
  Well, to be fair, Hibernate is just a tool - and as many tools, it can be used the wrong way and the right way. Most people seem to not spend any time to learn how to use it, and then complain when it doesn't magically read their mind. It's leaky, like all abstractions. You have to understand how it works, and how databases works. There's always the option to write HQL or JPQL as well, or even fall back to SQL if all else fails. It's not Hibernate's fault that you eager load everything, always load entire entities when you just need a single boolean field, or loop over entity collections to aggregate values - Hibernate is just a tool, and it's the developers who are telling it what to do.
  - saiya-jin 11y ago
    true, but... if so many developers end up having issues on not-trivial-hello-world-employee-customer example, then maybe, but just maybe it's not the best tool for most. I mean, it's around for ages, the principle didn't change a bit, and same issues again and again. One thing that I don't like about Hibernate - most projects evolve, for a very long time even after delivery. Messing with OR mappings (which most changes do) can include a lot of regression on performance side, much more than SQL (unless you do something horrible on DB level). Also, the more complex data model is (and often you don't choose how it's done), the less benefits you get from solutions like these.
glogla 11y ago
There's a series of articles about how Java don't have to be slow XML-laden crap: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/ While I don't necessarily agree with everything in it (like Gradle builds), it's interesting to look at.
- vorg 11y ago
  If you don't like XML but don't want to switch to Gradle, you could use another language atop Maven: https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven
lmm 11y ago
Any Java program takes a while to start up, and interactive Java desktop apps tend to be slow because of the UI toolkits they use. But in terms of throughput for a backend service, Java performance is fantastic.

Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.

by hanief 11y ago

Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.

threeseed 11y ago

That comes from the fact that Java takes quite a while to startup. It is going to be hopefully fixed in Java 9 where the platform becomes more modular. But that issue is what caused Java to have such a terrible reputation when apps were run on the desktop.

hugi 11y ago
Probably part of it, but for me, the somewhat uncanny valley-ish non-standard look and behaviour of Swing UIs (and AWT before that) is the biggest turn off. Using java apps on the desktop feels a little like using a keyboard with mittens.
- saiya-jin 11y ago
  This is an issue of unskilled devs using ancient UI design approach, usually not even bothering with skinning it. Things like bitTorrent were done in Java (correct me if I'm wrong), and you have no clue which language they are done in when looking at UI. But this a bit of extra effort, and for intranet apps, nobody usually bothers. Another reason for oh-not-so-windows-look of UI is something microsoft finally begun discovering - that there are other platforms than Windows. Java UI works anywhere where you have working JRE, and if you've ever seen Linux's KDE/GNOME/XFCE etc. then you might realize it ain't easy to come up with a cross-section between them. You need to hack things with Wine or similar to have it +-++ work the other way around (ie MFC app -> anywhere but MS world, and even there it might be tricky with all dll hell).
  - lmm 11y ago
    Standard bittorrent was in Python. Azureus was in Java and it felt significantly slower (than Python!) - it took so long to start it needed a splash screen, and you'd click a menu and wait for it to appear. Kind of an unfair comparison - the Python one just calls native Qt or Tk whereas the Java UI is actually written in Java - but it does colour the perception.
mike_hearn 11y ago
Startup time isn't that bad. It takes about 500 msec to get a window on the screen with the latest versions of Java and the JavaFX toolkit. Most of that is UI init. If you're doing command line apps it's much faster.

ghshephard 11y ago

Once you heat up the JVM, Java can run like a bat out of hell. And, if you don't run into GC problems, it's as fast as anything out there.

sacado2 11y ago
You can't fine-tune memory usage and can run into cache issues (or worse) if you deal with quite a lot of data, though.
- lmm 11y ago
  > You can't fine-tune memory usage What do you mean by that? There are some very fine-grained tuning options if you really need them.
  - sacado2 11y ago
    Maybe I'm wrong, but I don't know how you can say you want, say, a list of objects of class Foo be in contiguous slots of memory, rather than having a list of references to objects. Because the latter is very cache-unfriendly. In go, you can say whether you want a []Foo or a []*Foo
    - lmm 11y ago
      You can do that "by hand" with buffers (and the HFT guys do) but yeah it's not easy or fun. C#-style struct types are supposedly coming in the next version.
- threeseed 11y ago
  Wait. What ? I have never seen any piece of technology with more tuning options than the JVM. Especially given how dramatically different your apps perform with different combinations. It's akin to old wifes tales about which settings to use when. http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html http://www.oracle.com/technetwork/articles/java/vmoptions-js... And don't forget that much of big data is on the JVM e.g. Hadoop, Cassandra, HBase.

CookWithMe 11y ago

Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it. Two examples from my experience: JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0]. Hibernate is probably the worst offender. Well, the interface is somewhat nice: you don't have to care about loading objects from the database, Hibernate will load them for you. One object, one request at a time. Looking at the hundreds of generated SQL requests it's quite easy to figure out how you would write better SQL... but you don't write the SQL, Hibernate does :) The lesson IMO is: If you're writing everything from scratch, language performance is important. If you're using frameworks, the performance of the whole stack is way more important and one should probably compare benchmarks - or even real-world applications that are similar to ones use case - of the whole stack. [0] http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html

vetler 11y ago
Well, to be fair, Hibernate is just a tool - and as many tools, it can be used the wrong way and the right way. Most people seem to not spend any time to learn how to use it, and then complain when it doesn't magically read their mind. It's leaky, like all abstractions. You have to understand how it works, and how databases works. There's always the option to write HQL or JPQL as well, or even fall back to SQL if all else fails. It's not Hibernate's fault that you eager load everything, always load entire entities when you just need a single boolean field, or loop over entity collections to aggregate values - Hibernate is just a tool, and it's the developers who are telling it what to do.
- saiya-jin 11y ago
  true, but... if so many developers end up having issues on not-trivial-hello-world-employee-customer example, then maybe, but just maybe it's not the best tool for most. I mean, it's around for ages, the principle didn't change a bit, and same issues again and again. One thing that I don't like about Hibernate - most projects evolve, for a very long time even after delivery. Messing with OR mappings (which most changes do) can include a lot of regression on performance side, much more than SQL (unless you do something horrible on DB level). Also, the more complex data model is (and often you don't choose how it's done), the less benefits you get from solutions like these.

glogla 11y ago

There's a series of articles about how Java don't have to be slow XML-laden crap: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/ While I don't necessarily agree with everything in it (like Gradle builds), it's interesting to look at.

vorg 11y ago
If you don't like XML but don't want to switch to Gradle, you could use another language atop Maven: https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven

lmm 11y ago

Any Java program takes a while to start up, and interactive Java desktop apps tend to be slow because of the UI toolkits they use. But in terms of throughput for a backend service, Java performance is fantastic.