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. /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 -~----------~----~----~----~------~----~------~--~---
