Actually there are ways to define a platform portable library (which will ultimately need to address the GUI too) and then statically link in just the code that is used by a particular application (which is the approach Go is taking). The resulting app is self contained.
This can be done in such a way that a different binary is produced based on selecting a platform build target. So in the end the binary might be for running on Windows, Linux, Mac OS, Android, etc. Deploying such a native application would not require the prerequisite of a runtime to be installed first. When building for a target such as Linux, then the kernel version and 32-bit vs 64-bit could be selected. The problem of creating an rpm or debian or bin file should be a post-build phase, that's taken on by a packaging step. So all of this platform specific business could be dealt with at build and packaging time. A runtime installer requirement just puts a consistent environment in place ahead of the app. The approach I'm describing here would create that consistency at build time instead. Yeah, then there would be different variations of the resulting installable application that are highly platform specific. However, we all know that with Java, such applications are very often embedded into platform-specific installers and then a user comes along and chooses the right one for their platform. So Java with its runtime has not achieved the goal of a truly universal app binary (except with .war and .ear files for middle-tier servers). No one would give a client-side end user a collection of .jar files and expect them to have a good time trying to figure out how to install and run the app. So for the client side, the Java JRE approach has been a failure. Sun should have addressed this up front with Java but they lost interest in the client-side for a number of years. On Nov 15, 6:51 am, Stuart McCulloch <[email protected]> wrote: > 2009/11/15 Casper Bang <[email protected]> > > > > > > > I hear you, and might I add, WebStart is no rosy story either in a > > customer scenario. Personally I have always felt that the client Java > > approach is a case of "doing all platforms, but none of them > > particular well". I suppose there's direct evidence to that, in how > > NetBeans for Windows is delivered through a wrapper exe file written > > in C. > > > Btw. the Mono guys are quite far down this path of a mini-runtime > > statically compiled into one executable. This is what allows them to > > run on the iPhone and create Moonlight. See the Bundles section here: > >http://www.mono-project.com/Guide:Running_Mono_Applications > > > Size of the executable is such a non-issue today anyway and you can't > > really trust 100% backwards compatibility of an existing JRE either, > > it's a nice idea in theory but it doesn't pan out in practice. > > FWIW you've been able to compile a Java app into a native binary for a > while: > > http://gcc.gnu.org/java/ > > they even did a native compilation of Eclipse back in late 2002 / early > 2003: > > http://www.linuxjournal.com/article/4860 > > but when it comes down to it, even with a native app running on an OS you'll > have deal with different installations - just look at the different Linux > layouts > or the changes between Windows releases, you're still using a runtime and > depending on a library (especially GUI components) - just at a different > level > > I worked on native apps before (and after) moving to Java and wouldn't like > to > go back - too many memories of insanely #ifdef'd files! With Java I get a > lot > of portability for free. It may not be 100%, but it's enough for my purposes > > PS. the new modular JVM should make it easier to bundle a minimal runtime > > -- > Cheers, Stuart > > /Casper > > > > > On Nov 15, 7:56 am, RogerV <[email protected]> wrote: > > > I'm at this weird point in life where I have runtime installer > > > fatigue. > > > > For several years now I've been doing Java, some .NET for Windows > > > clients (talking to Java middle-tier), and these days Adobe Flex for > > > Flash Player and AIR on the client. > > > > The flagship languages for these runtimes are Java, C#, and > > > ActionScript3/MXML respectively. > > > > I do enterprise software solutions. I'm responsible for multiple > > > products and oversee teams per each. A lot of the concern that > > > consumes my life is deployment, configuration, and application > > > stability/consistency (with respect to distributed applications where > > > various components have to be well versioned to be compatible to one > > > another). > > > > As such, I don't like to leave things to chance when it comes to JRE > > > or .NET or Flash Player or AIR runtime versions that our apps have > > > been well tested and verified against. Consequently we have installers > > > that put specific JRE and AIR runtime into place to be used privately > > > by our apps and turn off automatic updating. We control and manage all > > > that rigorously to make sure the customer client machine doesn't > > > destabilize our software. > > > > I guess this is a round about way of saying that what appeals to me > > > about Go is the notion of once again building an executable binary > > > that is standalone. (Just to make sure things stay stable, I'm > > > resorting to making the runtimes private to the apps anyway.) > > > > When it comes to middle-ware server software, dealing with JRE is not > > > biggie. And it is nice to build middle-ware software deployments > > > as .war or .ear files that can easily be plopped onto AIX, Linux, or > > > Windows and be able to just run the same under the respective JRE for > > > those platforms. > > > > The client-side stuff is a different matter, though. I'm rather fed up > > > with runtimes and would just as well install a conventional native app > > > that doesn't depend on a separate runtime facility being present to do > > > its thing. (Perl, python, et al, have the same problem of how to > > > create distributable apps - it's the crazy runtime problem.) > > > > Go will take me back to those good old days - but with some of the > > > niceties as found in the more modern languages. It has enough of the > > > spirit of C to make me feel quite at home (C is my first language to > > > use professionally and I wrote several shrink-wrapped software titles > > > with it). > > > > Was going to spend more time learning Scala, but now Go has stolen the > > > center of attention. Too bad there's no Windows support yet. > > > > My one other reservation about Go is lack of intrinsic exception > > > handling features. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
