4 ms·

(Slight nit-pic: To run a jar file, you need the JRE installed, whereas a Go binary contains the runtime.) But you're right about static resources, they need t

• Alupis 12y ago
  you can bundle the jre into your executable to remove all foreign deps
  • adrusi 12y ago
    Which is a security risk in that the jre can't be updated without an update to your product. Granted the same applies to go since it statically links to its runtime.
    • deleted 12y ago
      [deleted]
    • hueving 12y ago
      Not really a security risk if you think of it like an embedded library in your software. A JRE vulnerability is then just like a vulnerability in the app itself and the vendor needs to update it.
      • _delirium 12y ago
        The majority of JRE vulnerabilities are also not really relevant to a local app in the first place. They're sandbox vulnerabilities that let carefully crafted applets break out of the sandbox and execute arbitrary code. But regularly installed desktop/server software doesn't run in the applet sandbox, and is already assumed to be able to execute arbitrary code.
  • deleted 12y ago
    [deleted]
• heavenlyhash 12y ago
  In addition to the bundle-the-jre option (which is extremely workable), you can also feed java bytecode into robovm [1], which spins it through LLVM and produces native binaries for any platform you can go with LLVM. (Most of the documentation emphasizes IOS, but speaking from experience, yes, you absolutely can make mac desktop and linux native binaries as well.) What robovm can do is a great example of the joys of toolchains with a well-defined stable intermediate representation. (Or one of the joys, I should say -- the flowering of languages on top of the jvm is another.) Go's first-class AST work is excellent stuff, but I'd love it even more if they fleshed out a well-defined, stable, portable intermediate format like LLVM's IR and java's bytecode. Making a release of software and knowing it can run on architectures you haven't even thought of yet is liberating. Sure, architectures don't come along "very often" (but they're starting to happen more often!), and sure, you can use a full vm at the bottom layer (but it's slow! It can't do a fraction of the optimizations possible with an IR/bytecode), and sure, you can just pretend the source is an IR (but if some library you use chooses a different build tool chain than you, you're going to have a bad time -- don't laugh, golang is too young to have bifurcated much yet, but give it time, and look at what happened around the go-get mess already; or, consider what happens when someone just adds more tooling like source generation, which has also already happened)... Taking the long view, I think an intermediate representation has proven incredibly useful for the jvm as a platform, and I hope golang also grows to offer such a route sometime in the future. [1] http://robovm.com/ http://robovm.com/
  • pcwalton 12y ago
    LLVM IR is neither portable nor stable.
    • mcpherrinm 12y ago
      But that isn't really relevant here: robovm is just a step in a build pipeline: Java -> java bytecode -> llvm IR -> native binary you distribute
  • tempodox 12y ago
    There was a time when you just compiled the sources when you wanted to port a system to a new platform.