Announcement

Collapse
No announcement yet.

GraalVM Updated For Java/JDK 21, Great Performance Results

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael_S
    replied
    Originally posted by caligula View Post
    Web frameworks are used for all sorts of stuff these days, but it doesn't mean they're efficient or productive to use. It's actually quite horrible how long it takes to "compile" even simple React apps.
    Some of the frameworks attempt to reject the maximalist options like React or Angular. I haven't looked recently, but I think Svelte.js is lightweight? I'm sure there are others.

    Leave a comment:


  • bug77
    replied
    Originally posted by stormcrow View Post

    "User requests are what computers are for," said Dumont. "Doing our business is what computers are for!" retorted Edward Dillinger.

    Ed ended up in jail for fraud.

    The truth is that computers are a tool for solving problems. It doesn't matter if it's business logic, scientific pursuits, or just helping my partner keep up with their various appointments. A calendar app is just as legitimate an application for Java as a highly complex port of a 50 year old business logic/accounting/inventory system originally written in COBOL on an IBM S/360. Java is a general purpose programming language, and it lends itself to generalized tasks. The details how it does those tasks are less important.

    It's disingenuous, objectively wrong, and disrespectful to all those that have nurtured computer science and technology to claim the only reason for the advancement of computers, computer and electronics technology, and computing in general is to support businesses and their endless pursuit of greed. That's not what history teaches. Amateur and professional technicians, scientists both professional and casual, electronics and radio buffs, mathematicians and the merely curious all had a hand in making the computing industry what it is today both on the hardware side and the software side.
    Are you sure you understand what "business logic" means? https://en.wikipedia.org/wiki/Business_logic

    Leave a comment:


  • stormcrow
    replied
    Originally posted by bug77 View Post

    It's called business logic. You know, the whole reason applications exist in the first place...
    "User requests are what computers are for," said Dumont. "Doing our business is what computers are for!" retorted Edward Dillinger.

    Ed ended up in jail for fraud.

    The truth is that computers are a tool for solving problems. It doesn't matter if it's business logic, scientific pursuits, or just helping my partner keep up with their various appointments. A calendar app is just as legitimate an application for Java as a highly complex port of a 50 year old business logic/accounting/inventory system originally written in COBOL on an IBM S/360. Java is a general purpose programming language, and it lends itself to generalized tasks. The details how it does those tasks are less important.

    It's disingenuous, objectively wrong, and disrespectful to all those that have nurtured computer science and technology to claim the only reason for the advancement of computers, computer and electronics technology, and computing in general is to support businesses and their endless pursuit of greed. That's not what history teaches. Amateur and professional technicians, scientists both professional and casual, electronics and radio buffs, mathematicians and the merely curious all had a hand in making the computing industry what it is today both on the hardware side and the software side.

    Leave a comment:


  • nadirx
    replied
    Originally posted by bug77 View Post
    And once again they pride themselves about AoT compile, despite:


    https://www.graalvm.org/22.0/referen.../native-image/
    Why are you looking at 22.0 ? 23.0 includes the native image tool https://medium.com/graalvm/a-new-gra...e-4aab483692f5

    Leave a comment:


  • caligula
    replied
    Originally posted by bug77 View Post

    Yeah, somehow desktop was never a priority for Java. After applets and Swing killed it on the desktop, we got JavaFX which was actually nice and introduced the separation between presentation and business logic which Swing didn't enforce. But of course, by then it was already too late.
    I guess Swing was designed to compete with Unix and Win32 GUI toolkits. Sure it had a more modern style of programming. For example, usually no need to manage resources explicitly. The first generation of JavaFX appeared when so called rich web/internet applications became popular. Adobe Flash & Flex etc. JavaFX isn't all that bad, but it has plenty of design flaws (e.g. they're still opening some aspects of the APIs because the built-in components aren't that customizable). JavaFX is also quite heavy, but at the same time doesn't support any advanced 3d scenes with modern rendering options. I would have wanted to see an expressive truly cross-platform GUI library built in a pure high level language. It's kind of silly that all these Java GUI libraries offload stuff to GTK. Java is powerful enough for enabling things like a full GUI engine that would target Vulkan or some other efficient low-level API. That could have even helped with the laggy feel of the current GUI libraries. There are way too many abstraction layers involved.

    Web frameworks are used for all sorts of stuff these days, but it doesn't mean they're efficient or productive to use. It's actually quite horrible how long it takes to "compile" even simple React apps. React builds its own abstraction on top of the DOM. It might launch a bit faster than Java/Swing, but uses tons of memory. Sites like cellmapper or miro also use quite a bit of CPU & GPU power. I really miss the technical superiority of the efficient native GUI toolkits from 1980s and early 1990s.

    Leave a comment:


  • cynic
    replied
    Originally posted by Linuxhippy View Post
    I guess this AOT support as well as a better looking swing default theme (does anyone still remember pre java-1.5 metal) would have saved java on the desktop back then.
    Imagine you would have to wait 30s for an application to start, and when it finally pops up it looks like this:
    grafik.png

    The sad thing is technically everything was always there (Excelsior JET for AOT, pluggable swing themes that looked really cool), but without the push from Sun those things didn't gain tracktion.
    for the time Metal L&F was not bad at all.

    TBH I still like it today, but I realize that I have a bit of outdated tastes regarding GUI.

    Leave a comment:


  • cynic
    replied
    Originally posted by Linuxhippy View Post
    I still remember running JBuilder back then
    oh, I still have the CD, the manual and the original box somewhere!

    Leave a comment:


  • caligula
    replied
    Originally posted by Linuxhippy View Post

    I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
    Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.
    Well yea. OTOH I think you could have run interpreter instead. It was a lot slower, but anyway. The Sun implementation of Java wasn't really suitable for those kind of low-end systems. I think they had some kind of internal development project for speeding up the startup (I don't mean the ones they later published), but that project was never released. GCJ was a bit faster to launch. Then again, even native applications like those made with Delphi were a lot slower than slimmer apps written in Visual C++.

    Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then
    Swing also relies on an extra verbose style of OOP where e.g. layout manager objects are different from the containers and many functionalities require adapters and all sorts of wrappers. This puts a lot of burden on the GC and other parts of the runtime. If Java didn't allow dynamic loading of new classes, it would have been possible to optimize things a lot more, especially those intermediate objects that don't need an explicit class name.

    Leave a comment:


  • bug77
    replied
    Originally posted by Linuxhippy View Post

    I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
    Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.
    Startup was slow because the JVM had to parse and verify protable bytecode at each application start (pre-verification and class-data-sharing weren't available back then), and when the class was finally loaded the JIT hadn't even kicked in yet. Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then

    I guess back then not a lot was missing to make Java a viable development plattform for client applications. However those things were not done or avoided (e.g. AOT was probably avoided to make users install the JRE), and desktop java basically died: The only popular swing based app I know still of relevance today is IntelliJ.
    Yeah, somehow desktop was never a priority for Java. After applets and Swing killed it on the desktop, we got JavaFX which was actually nice and introduced the separation between presentation and business logic which Swing didn't enforce. But of course, by then it was already too late.
    Azureus was popular too, but it also died a few years back.

    Leave a comment:


  • Linuxhippy
    replied
    Originally posted by caligula View Post
    It's just bad application design. On a modern system the Java runtime (JIT, not AOT) takes around 200-500 ms to launch. It can be faster if you use jlink. Often Java applications have really complex startup and initialization sequences. They could also lazily load more stuff. A GUI app doesn't need to initialize all the windows before showing them.
    I was talking about the days when desktop applications were still relevant (e.g. 1998/99) and more than a niche.
    Believe me, with Java-1.4 on a P2-350 with 64MB Ram and a spinning disk, you had to wait MANY seconds before a window would appear, even for the most basic application.
    Startup was slow because the JVM had to parse and verify protable bytecode at each application start (pre-verification and class-data-sharing weren't available back then), and when the class was finally loaded the JIT hadn't even kicked in yet. Swing was be slow simply because it had a large code-base which was mostly lukewarm code (a case where JITs do not excel), despite hardware accelerated rendering added with Java 1.4. I still remember running JBuilder back then

    I guess back then not a lot was missing to make Java a viable development plattform for client applications. However those things were not done or avoided (e.g. AOT was probably avoided to make users install the JRE), and desktop java basically died: The only popular swing based app I know still of relevance today is IntelliJ.
    Last edited by Linuxhippy; 20 September 2023, 11:54 AM.

    Leave a comment:

Working...
X