PS:业余继续整理Loonframework-web部分源码中，在业余的业余中抽空写点杂说……
——————————————————————————————————————
   PS:本文JRE皆指Sun JRE。

   大家都知道，通常Java程序需要JVM与OS互动才能运行于本地环境之上，所谓鱼与熊掌不可兼得，这样做虽然极大降低了程序的移植难度，却同时增加了程 序的环境要求，因为无论你用什么方法，总需弄个虚拟机才能让你的Java程序跑起来（JET之类转Win32编译的方式愚以为不如直接写C++程序，那样 更安全更高效） 。

   当面对企业级用户时，虚拟机安装这根本就算不上问题，布署之类事宜本就有专人负责，我们踏踏实实写代码就好，精简JRE之类的琐事与我何干？或者说，根本就不存在精简它的必要，又何必想要去精简呢？

   然而，当你的软件最终不是面向企业，而是面向个人用户时，那么JRE的安装就绝对成了问题。

   我们想象一下，现在有两套同期发布的个人软件，一套是Java开发，一套是Delphi开发，它们功能近似，售价近似，且都处在普及阶段，同样没有多余的 经费进行广告宣传，隐藏数据是：Java软件实用性较强。而此刻人们无从得知其具体性能，只能通过下载免费试用版作比较。

   这对于Delphi开发的软件似乎没什么说的，只要老老实实打包发布就好；可对Java软件来讲，麻烦却找上门来了，那就是，我要怎么布署安装才合适呢？   
    

   方式一：老老实实把JRE打包进软件中，一起发布。理由：1、减少用户操作复杂度，直接安装即可使用，有利于用户体验。2、避免在已安装JRE系统上产生版本冲突。

   Java方软件大小：使用最适合Java程序发布的Install4J打包，比如JRE1.6大约能够压缩到10MB以内，假设我们以jar形式发布软 件，发布的jar及配置文件等累计占用空间10M以内，那么到了Install4J中至多也就是2-3MB，理想状态下，我们的安装程序可能只有10MB 多一点左右甚至不到，当然，这已经接近极限了。

   Delphi方软件大小：使用InstallShield打包，exe及dll与其他配置文件累计占用空间5MB左右，打包后安装文件维持在2MB左右（实际上可能更小|||）。

   可能的结果：2MB VS 10MB的同类软件，简单化的说，就是下载你一个Java程序的时间，够下载这Delphi程序5个|||。 
   我们都知道，如果你在网络上下载电影，只要有1部以上，那么通常讲都会或自觉或不自觉地下载速度较快那部，难道在下载软件时，人就会例外吗？
    结 果是，用户可不懂什么叫Delphi那个是Java，他们只关心那个快捷，那个方便，而看到这2MB和10MB的对比，他们则更多的会怀疑体积庞大一方的 技术，为什么东样的东西你做这么大人家就占那么点空间？怀疑你内置的东西，该不会这小子整合套远程监控系统进来吧？……如果两个软件同时发布，只要 Java方没有比Delphi方更高明的宣传手段，那么结果肯定是大家都一窝蜂的去下载Delphi软件，过一段时间，大家软件用熟了，习惯成自然，自然 还是继续使用Delphi方的，即便有几个用Java方软件感觉不错，那也只会成为类似Mac OS对比Windows的感叹罢了。
    

  方式二：利用网络安装手段，比如使用Sun提供的jinstall那套网络安装小工具，文件大小都只有几百KB，或者直接令Install4J安装程序进 行网络下载，而不直接打包JRE。理由：1、最大限度缩小安装程序体积，增加用户信赖度。 2、减少程序下载时间，有利于用户体验。

  Java方软件大小：由于没有直接携带JRE，Install4J打包程序后我们的安装文件至多也不过2、3MB，看上去很可能比Delphi安装程序更小。

  Delphi方软件大小：见方式一。

  可能的结果：2MB左右 VS 2MB的同类软件，此刻潜在用户们实际上是很难抉择的，大体上讲不成倍数的软件体积差距普通用户基本是无视的，所以他们这时很可能会想要比较一下性能，也就是Delphi程序和Java程序各下载一个看看，反正看上去空间占用都很小。
  然而，对Java来说，问题再次出现在某个场景之内......
  哇！某位使用Java版软件的女用户尖叫着呼唤她的XX：“快来看看，我这电脑怎么了？自动下载起来了~”，“什么事啊？我看看……我靠，你这下载什么 呢？还十几兆这么大？！”，女：“不知道呀，我一安装XXXX软件，它就提示正在准备安装，然后就联网开始让我下载什么Java，我一点击下载，都1分钟 了还没完呢~”，男：“快中断进程，肯定是个流氓软件！”，女：“我X，什么破东西啊，以后再也不用它了。”……
   结 果是,与这位女性有相同或类似经历的用户开始痛骂Java开发的XXXX软件,进而发展到论坛甚至媒体,XXXX软件尽管多方解释,但无奈于我国的特殊国 情,最终被用户归类于服务差性能差的垃圾软件一类,同时受舆论及自身安装体验影响,用户大量涌向市场占有率本就非常接近的Delphi软件一方……

 我们来看一下Sun提供的JRE1.6 Windows版安装说明：

 系统要求

    * Vista

    * Windows 2000 (SP3+)

    * Windows XP Home

    * Windows XP Professional (SP1+)

    * Windows Server 2003 Editions

  支持Intel和100%兼容处理器。推荐使用物理内存至少为 64MB 的 Pentium 166MHz 或更快处理器。此外，还应至少拥有 98MB 的可用磁盘空间。    

  无论我们怎样替普通用户布署JRE,一个完整的JRE始终都太大了,这对于大部分只想完成单一功能,又没有多少软件知识的普通用户来说,无疑是种负担.  
  
  而事实上讲，我们所使用的类库往往只是JRE提供给我们类库中的极小一部分，大多数时候，不过是十之二、三甚至于十之一、二，更多的则仅仅是无意义的存在那里，浪费着用户的磁盘空间罢了。

  试想当年Applet何等风光，如果不是因为它太重太不方便，不是因为与微软决裂及Flash等轻量级应用的双重打击，那么今天那些写Flash的家伙干的事情，本就该归我们Java程序员负责才对。
  
  于是我们渴望更小的，更实用的，轻量级的，消费型的JRE出现，以从根本上避免上述这些无谓的浪费与遗憾。
  
  庆幸的是，Sun已经开始意识到这些，开始尝试JavaFX项目及Java Browser Edition计划等一系列行动，但目前来说，依旧是远水解不了近火，所以目前阶段要想精简JRE，还是要靠我们自己动手、丰衣足食了。

  下文开始，我将结合具体实例尝试JRE的精简与压缩。

  ————————————————————————————————————————————————————

  睡觉，明天晚上回来继续……

本文转自 cping 51CTO博客，原文链接:http://blog.51cto.com/cping1982/129634