GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-10-22) - page 1 of 10
 
___________________________________________________________________
Using Java 9 Modularization to Ship Zero-Dependency Native Apps
107 points by StevePerkins
https://steveperkins.com/using-java-9-modularization-to-ship-zer...
___________________________________________________________________
 
tootie - 2 hours ago
While everyone is excited about how this helps desktop app
development, this is also going to simplify server deploys. If
you've got a full java stack, you won't need to do anything to
provision a server.
 
capelio - 3 hours ago
Even so, Java is now at a place where you can ship self-contained,
zero-dependency applications that are comparable in size to other
compiled languages (and superior to web-hybrid options like
Electron).For cross-platform desktop GUI apps, I would argue that
JavaFX combined with Java 9 modularization is hands-down the best
choice available today.Electron is succeeding in the desktop GUI
space because it tears down the barriers to desktop app
development. While the author's article is excellent, when it comes
to Electron, he (like most engineers) is still missing the point:
the choice between Electron and its alternatives doesn't pivot on
file size.
 
  Avshalom - 1 hours ago
  >tears down the barriers to desktop app developmentYes, then it
  replaces them with the barriers to web app development.
 
  aaomidi - 2 hours ago
  Yes, but it's electron.I've honestly seen only one properly
  written Electron app and it's VSCode. Everything else electron
  sucks. VSCode is not great either but it's much better than say,
  Atom or Slack.
 
    bpicolo - 1 hours ago
    Discord is great
 
      supergreg - 1 hours ago
      So is gitkraken.But I assume these apps have spent a
      considerable amount of time in optimizing electron, which not
      everyone can do.
 
        erikbye - 46 minutes ago
        While some may find GitKraken visually pleasing, it can't
        be used for big repos; didn't even manage to open a few of
        the ones I tried.
 
    richardwhiuk - 32 minutes ago
    Slack?
 
  ssijak - 2 hours ago
  Well, will see how Electron will pan out in the end. While I
  dislike default Java Swing GUI (it can be made easily to look
  native but many devs previously did not do it), JavaFX can be
  made to look like anything with almost weblike feel to
  development and animations. Now, more than the looks I dislike
  the slowness and utterly unacceptable memory Electron apps
  consume. I ditched Electron and VSCode (it is a little better
  than Atom) because I don`t want to have my text editor eat 500mb
  ram to open 1 medium file and crash on large ones. Same for Slack
  and other Electron apps. And it is not even funny to see dev
  console when some Atom plugin or whatever crash. I`m interested
  how many devs also ditched this two editors ONLY because of
  Electron bloat.
 
    pjmlp - 2 hours ago
    Electron pop culture made me buy Sublime Text.
 
      ssijak - 38 minutes ago
      For me it finally pushed me enough to switch to Vim for web
      dev work. But I do have Sublime for just in case.
 
  _sh - 35 minutes ago
  Electron sits in the same hybrid space as Cordova/Phonegap, and
  will suffer the same fate once React Native, or something
  similar, starts eating its lunch.
 
zengid - 1 hours ago
I'm unfamiliar with the state of the art, but could this make it
possible to target iOS with a bundled JVM?
 
  ssijak - 36 minutes ago
  No.
 
  pjmlp - 24 minutes ago
  It is possible using an AOT compiler for Java, like Codename One
  or Robot VM.So far Oracle has shown little interest into
  integrating such features into OpenJDK, but the ongoing efforts
  to add AOT compilation to it, might become a possible solution.
 
  filereaper - 1 hours ago
  iOS tends to favour direct native code, hence the use of
  Objective C and Swift for iOS development.Given the already large
  ecosystem built on these lanuages, its unlikely they'll pivot to
  a JVM based system.
 
    pjmlp - 24 minutes ago
    There are AOT native Java compilers for iOS, the majority just
    tends to ignore them.
 
tpolzer - 2 hours ago
Does it have cross platform Hi-DPI support? No.
 
  ZenoArrow - 2 hours ago
  Are you joking? I can't tell.Just in case you aren't, what do you
  think is required for a platform to support Hi-DPI displays?
 
  pjmlp - 21 minutes ago
  Yes it does, when using Java 9.
 
phreack - 3 hours ago
While Electron's popularity was a boon to the desktop app scene, I
keep on dreaming that JavaFX applications made with Kotlin, jlink,
Gluon's scene builder (or maybe even something better) will gain
enough popularity to attract a healthy open source community for
cross platform desktop apps.It feels like the tools are almost
where they need to be and finally coming together!
 
generichuman - 3 hours ago
I want to use JavaFX to develop cross-platform apps but I feel JVM
uses too much memory even for little things.It's been a while since
I've used Java to program, has the memory situation changed? or are
there any other solutions for lowering the JVM memory usage?
 
  jm547ster - 2 hours ago
  Default heap size is over-generous in most JVM implementations,
  experimenting with smaller settings is the solution.
 
  pjmlp - 2 hours ago
  Apparently lack of memory isn't something that affects Electron
  popularity.Java applications use much less memory, unless their
  coders weren't paying attention during algorithms and
  datastructures lectures.
 
  slackingoff2017 - 2 hours ago
  Java will use as much memory as you give it. Higher heap size is
  better for performance up to around 32GB. For most Java apps you
  can limit heap to 256M or less with little consequence.AFAIK Java
  uses less ram than Python and JavaScript, only common languages
  that beat it are Golang and C/C++
 
    nextos - 2 hours ago
    And memory used will be hopefully quite lower with value types,
    coming sometime in the
    future:http://www.jesperdj.com/2015/10/04/project-valhalla-
    value-ty...
 
  vbezhenar - 2 hours ago
  I used Swing Java applications on a computer with 512 MB RAM.
  Sure, Java eats more than C++, but it should be pretty in line
  with JavaScript which is a very popular choice nowadays.
 
camus2 - 3 hours ago
> A ?Hello World? CLI written in Go compiles to around 2 MB.Nitpick
but hello-world in Go :    package main         func main(){
print("Hello World")     }   is < 1MB on most computers (900KB on
windows). No need to import the "fmt" package.
 
  virmundi - 29 minutes ago
  Hey! You win the worthless example competition! See the front
  desk for your prize. How about comparing a full stack, monolith
  app in Java vs Golang? While you?re at it, don?t just compare
  binaries. Compare how well it handles concurrency. Compare how
  well it handles templates. Or how smoothly it handles DB
  interaction. Then look at all this and compare the population of
  Golang vs Java devs. Compare how well you can leverage existing
  language knowledge while working on a major mobile platform too
  like Android.Binary size for a hello world app means little to
  nothing. I can beat that with Bash: echo ?hello, world!? Compare
  to real applications.
 
  morecoffee - 2 hours ago
  print() is a nonstandard function and will be removed eventually.
 
  pjmlp - 2 hours ago
  Except that isn't actually portable Go code, because you are
  using an unsupported function that can be removed at any
  time."The print built-in function formats its arguments in an
  implementation-specific way and writes the result to standard
  error. Print is useful for bootstrapping and debugging; it is not
  guaranteed to stay in the
  language."https://golang.org/pkg/builtin/
 
    [deleted]
 
  slackingoff2017 - 2 hours ago
  You can get under 200KB in Java easily by using proguard or
  similar to strip unused code from your dependencies.
 
    camus2 - 2 hours ago
    Sure, but I didn't apply any specific code optimization or
    third party tool here.
 
      slackingoff2017 - 2 hours ago
      Progaurd is default on Android and some other environments,
      it's not anything exotic.
 
    pebers - 2 hours ago
    But that 200KB isn't a standalone executable. The Go example
    would be a lot smaller if it just distributed some unlinked
    object code with no runtime.
 
      slackingoff2017 - 57 minutes ago
      True. The JVM is big. I've been meaning to try Golang one of
      these days, I see it as Java's spiritual successor
 
        eropple - 34 minutes ago
        I tend to view it more as a regressor. Golang is a
        conservative retrenchment towards Java pre-1.5 in a lot of
        ways. (And that may be fine for some use cases; I get the
        appeal even if I think it's misguided.)
 
        pjmlp - 22 minutes ago
        Not really, unless you enjoy to program in Java 1.0 again.
 
i386 - 1 hours ago
Oracle have broken and delayed releases of Java so some people can
get slimmer binaries? Hardly seems like a good trade off when
storage is the cheapest it?s ever been.
 
  blinkingled - 50 minutes ago
  It's not about storage. Most desktops don't have a JRE installed
  and downloading the full non-modular JRE and installing it before
  being able to run the program is a hassle compared to providing a
  stripped down, self sufficient, linked version of the app that's
  one third in size.