都是同学发的，如下：

早上醒来，先用二甘醇超标的田七牙膏刷，再用发臭的 水洗脸，给儿子冲一瓶添加三聚氰胺的三鹿奶粉，自己杯黑作坊的豆浆，吃几个硫磺熏白了的馒头，或者是废纸箱当肉馅的包子，就点儿废旧油漆桶里腌的榨菜，包里放个安徽人05年的粽子（上班吃了吃），吃饱喝足，出门，深吸一口富含PX的空气，到断成两截的九江大桥上溜溜腿儿，找找白娘子和许相公在断桥的感觉。　　
中午跟同事一起到肯德基吃顿苏丹红炸鸡，了杯苯超标的可乐。下午给朋友打电话，就听见她哭哭啼啼，大约是炒股炒赔地，约她出来到新开的菜馆吃顿地沟油炒的菜，来一盘避孕药催大的香辣鳝鱼，再来一盘臭水沟捞来的麻辣龙虾，还有个农药高残留的清炒菠菜，老板上一杯重金属超标100倍的碧螺春茶，再点含甲醛的啤酒……，算帐的时候168(太黑了，还不打折）吉利，老板又找回了一张假币。
回家的时候被宝马撞倒，太幸运！得让丫出点血，所以躺着不动，一睁眼，看宝马调回头来碾压……以史无前例的速度爬起来跑掉。
回家。要睡觉的时候，被刚装修完的赠品甲醛呛得眼泪直流，只好把脑袋蒙到黑心棉被子里。想起房子还有四十万贷款加利息，辗转反侧到天半亮都没眯。找安眠药吃了半瓶也没用，含在嘴里，哦，还好是糯米粉

还有一个

一个中国人幸福的一天！ 早晨起床，掀开黑心绵作的被子，用致癌牙膏刷完牙，喝杯过了期的碘超标还掺了三聚氰胺的牛奶，吃根柴油炸的洗衣粉油条，外加一个苏丹红咸蛋，在票贩子手里买张车票，准时赶到地下烟厂上班，九点三十分偷偷用山寨手机看股票从6124.04点跌到1240.46点，中午在餐馆点一盘用地沟油炒的避孕药喂的黄膳，再加一碟敌敌畏喷过的白菜，盛两碗杯陈化粮煮的毒米饭；晚上蒸一盘病的瘦肉精养大的死猪肉做的腊肉，沾上点毛发勾兑的毒酱油，夹两片大粪水浸泡的臭豆腐，还有用福尔马林泡过的凉拌海蜇皮，抓两个添加了漂白粉和吊白块的大馒头，还喝上两杯富含甲醇的白酒。唉……这日子过的真是那个爽!!!这就是一个中国人幸福的一天

        Java中自带了Stack类，但是其父类为Vector，这恰恰是最不应该的。因为Vector的底层为数组，且Vector拥有get方法（意味着它可能访问到并不属于最后一个位置元素的其他元素，很不安全）（摘自http://www.blogjava.net/bounce/archive/2007/03/19/104831.html）。因此实现Stack的最佳方式是使用LinkedList，并且不要提供能够让不是最后一个元素的元素出栈的方法。

import java.util.LinkedList;

class Stack {
 LinkedList ll = new LinkedList();

 public void push(Object o) {
  ll.addFirst(o);
 }

 public Object pop() {
  return ll.removeFirst();
 }

 public Object peek() {
  return ll.getFirst();
 }

 public boolean empty() {
  return ll.isEmpty();
 }
 
 public int size() {
  return ll.size();
 }

 public static void main(String[] args) {
  Stack ms = new Stack();
  ms.push("a");
  ms.push("b");
  ms.push("c");
  System.out.println(ms.size());

  System.out.println(ms.pop());
  System.out.println(ms.size());
  System.out.println(ms.empty());
 }
}

最近颇受打击，YY买了房，188平的，无语。。。

看大家过的都不错，工资高，奖金高，工作轻松，而我却还为了那可怜的工资没日没夜的加班，心里的酸楚只有自己知啊。。

下面从MOP看到的，聊以自嘲吧

去年公司来一Ａｓｓｉｓｔａｎｔ,女,刚满30,外貌平平
一日说一起出去k歌　正讨论哪几个一起打的拼车　那女说,我带你们去下楼，porsche
随问：自己买的？
答：偶男人的求婚礼物　年底偶们结婚 他看我家开的是porsche　就买了同一系列的送偶
问：你男人和你住一起？
答：还没 他在我家别墅对面买了一栋 现在和我们是门对门的
恍然大悟：什么叫门当户对~~

继续：你还来工作干嘛？
答：每天蹦迪泡把也没意思啊
ORZ~~~~

婚后3个月后此女怀孕 立马炒了sap鱿鱼 从此偶在公司再也米有看到过
porsche............

痛苦的捂住脸扭向一边系列
--------------------------------------------------------------------------------

朋友在某地移动上班，这天来了个新同事，跟他一样都是业务员，工资1300
第一天，朋友带他跑业务，开公司的面包车
这位仁兄见了面包车直摇头，"这车空调太弱，会很热的，干脆坐我的车"
朋友："哟？你开了车来上班的嗦？车在哪呢？"
他：（抬头、努嘴）"呐，那辆黑色的"
奔驰S600
朋友痛苦的捂住脸扭向一边
后来他们经理看不下去了，觉得这样会影响团结。就把他叫去谈话。
经理："你能不能低调一点？在这很多人都是走关系进来的，但是大家都很低调，你不要搞特殊化嘛"
他："恩恩恩"（相当的诚恳）
于是第二天
银灰色宝马
经理觉得输人不能输气势，又把他叫去谈话
"你能不能再低调一点？"
"恩恩恩"（相当的诚恳）
第三天
凯美瑞
经理痛苦的捂住脸扭向一边
朋友就很好奇啊，问他，"你条件这么好，为啥还来我们这公司上班喃？杂不直接跟着父母做生意哦？"

你们猜杂回答的？

"我不想依靠父母"

--------------------------------------------------------------------------------

去年公司来一QC,女的,30出头,外貌平平
第一天,总经理喊副科,带她去工厂看看,熟悉一下(去工厂全是坐公交的)
那女的说,在哪边的？我带你们去下楼，凯美瑞2.4
我们总经理才凯美瑞1.8
第2天，公司说给她配个电脑，她说不用了，从包里掏出一notebook
下午，经理喊她进去，你走吧，你比我有钱....然后痛苦的捂住脸扭向一边
她走前我们问她，你这样还来上班做啥？
她说，老公是工厂老总，每天太忙，没人陪她，只好自己出来找点事儿做
--------------------------------------------------------------------------------

前几个月单位招了个些新人,分配到楼下的网点了,刚好是季度末,要算存款额的,负责人希望下面的人大力一些拉存款.结果第二天一妇女来那新人那做了个750w的7天通知存款. 一些老员工问这女孩啥能耐.
"没有,那是我妈,昨晚跟她说过一下,她说今天从信用社那边划些钱过来帮我做做绩效任务囖."
--------------------------------------------------------------------------------

上班遇到的第一个同事，跟我一样住宿舍、吃食堂、骑自行车上下班，甚至手提电脑都没有。。。超级低调的一个女生，用钱也是精打细算的。

后来才知道，她家有一架直升飞机。。。
--------------------------------------------------------------------------------

我朋友的女朋友是某房地产大亨的千金，曾经在某投资公司打工，小职员。然则干了2-3个月后对这公司产生感情，第二天变成公司股东了。。
--------------------------------------------------------------------------------

朋友工作的某银行新进一海龟女生，职务普通业务，开锐志上班，亲爹是财厅某把手。一日行长为某政策问题焦头烂额上蹿下跳，只见该女生施施然拿出手机拨通电话："喂，陈叔叔啊，好久不见，我爸？挺好的。我吗，前几个月回来，现在在X行上班。有件事拜托你，blablabla...什么，你来找我？不用不用……"……
相关链接: 行长自然也是痛苦的捂住脸扭向一边
--------------------------------------------------------------------------------

面试过一个开着别克君威来的，应聘Designer, 25岁。简历里直接写，希望公司提供停车位
--------------------------------------------------------------------------------

我也讲一个，我大学有个同学每天拿个那个2升的可乐瓶子灌满开水，背个书包那种登山那种装的满满的（都是书，不管每天有几节课），每顿饭几乎都是4个馒头5毛的素菜，后来听说他爹是湖南省林业厅厅长，他爷爷曾和zm.j同事过

大学舍友..相当低调的一女生..每个月只用500多的生活费..长得挺漂亮..大二放假去她家玩才知道..她家企业进福清10强..北京上海深圳都有别墅...T.T~~还跟我说以后去那些城市玩可以住她家..反正她家平常没人住..只有保姆看着房子...我和几个舍友当场被雷..

------------------------------------------------------------------------------------------

之前在某银行做的时候..见行长天天坐着a8 3.2出门,觉得这行福利真好啊~~~后来跟个同事混熟了..才知道那是他家的车T.T...无语..因为行长的配车是太差..就征用他的车了..1个月后,我那同事忍无可忍..说那车加了油都行长在开..又没给抱邮费..觉得非常不爽...跟我抱怨的下个星期一开了辆凯美瑞来..说:怎样..刚买的!绿色!你看这车牌(*9138)!行长肯定不找我要车开了~~....之前很疑惑的问过他为什么不接他爸生意..他的回答也是:不想靠父母..听了我都愤怒..PS..他家在我们福州机场10分钟的车程买了个山头..盖了个...类似庭院类似别墅..还有小桥流水的..房子..专门渡假....

--------------------------------------------------------------------------

也说个我们系统的。。
某男，公务员，年仅20，刚上班时开了辆大红的bmw,跑车，z4
后来被局长找去谈话，说公务员要低调，大男人不要开红色的车，然后他第二天开了辆白的bmw，5系
又被局长找去谈话，说最好不要开宝马来上班，这小子立马去雪弗兰订了一辆spark，过了几天开了辆spark上班，中间这段时间倒是没开宝马，开了辆雅阁，自此没再被领导找过。。。。。

--------------------------------------------------------------------------

我以前一同事也极BH，我当时做事的是个小杂志，她在里面做广告业务，工资挺低，平时穿着打扮也不怎么样，人倒是很好，后来和她熟了，才知道她家超有米，开工厂的，还是那种家族企业，挺大的，然后每次出去跑业务，就是先自己开着摩托车去，然后到一个地方等她老公开车来接，说是不想太张扬，不过后来估计做得觉得没意思了，就开始很BH的懒散了，经常就不来上班，有次我们主编看她没来，实在忍不住，就打电话给她问她怎么回事，她答得巨BH，说：昨天晚上老公回来晚了，然后我们ML了，结果今天没力气爬起来，所以请假吧~~——全公司的人都被雷昏了！！！！  反正她来公司就是消遣，工资被扣光了她也不在乎，每次来就是为了找几个人陪她一起出去逛街然后大吃大喝~~~记得后来她叫我们去她家玩，我有事没去，另一个去了的同事说吓死了，说从她家大门到进屋开车开了15分钟，娘的……

1.由于我用的是JDK1.6，自带了jce.jar，这样会与插件产生冲突，报如下错

association.Association Unsupported algorithm: HmacSHA1, size: 160
java.security.NoSuchAlgorithmException: HmacSHA1 KeyGenerator not available

在library中将JDK中的该包去掉就可以了，不过好像不除去也不影响插件的使用。。。

2.在建好Acegi的Role后（参见http://www.grails.org/AcegiSecurity+Plugin+-+Basic+Tutorial），用user注册时会提示找不到默认的Role，这是因为在securityCofing.groovy中指定了

defaultRole = 'ROLE_USER'

而在Role.groovy中我们可以看见

String authority = 'ROLE_'

所以只要在RoleController中新建一个角色user，记住不是ROLE_USER，这样就可以在usercontroller中注册了。

----------------------------
一键转贴，快速捕捉生活精彩，赢每周好礼！查看活动首页>>

When Runtime.exec() won't

Navigate yourself around pitfalls related to the Runtime.exec() method Summary

In this installment of Java Traps, Michael Daconta discusses one new pitfall and revisits another from his previous column. Originating in the java.lang package, the pitfall specifically involves problems with the Runtime.exec() method. Daconta also corrects an error from Pitfall 3 and offers a simpler solution. (2,500 words)

s part of the Java language, the java.lang package is implicitly imported into every Java program. This package's pitfalls surface often, affecting most programmers. This month, I'll discuss the traps lurking in the Runtime.exec() method.

Pitfall 4: When Runtime.exec() won't

The class java.lang.Runtime features a static method called getRuntime(), which retrieves the current Java Runtime Environment.

That is the only way to obtain a reference to the Runtime object. With that reference, you can run external programs by invoking the Runtime class's exec() method. Developers often call this method to launch a browser for displaying a help page in HTML.

There are four overloaded versions of the exec() command: public Process exec(String command); public Process exec(String [] cmdArray); public Process exec(String command, String [] envp); public Process exec(String [] cmdArray, String [] envp);

For each of these methods, a command -- and possibly a set of arguments -- is passed to an operating-system-specific function call. This subsequently creates an operating-system-specific process (a running program) with a reference to a Process class returned to the Java VM. The Process class is an abstract class, because a specific subclass of Process exists for each operating system.

You can pass three possible input parameters into these methods: A single string that represents both the program to execute and any arguments to that program An array of strings that separate the program from its arguments

Pass in the environment variables in the form If you use the version of exec() with a single string for both the program and its arguments, note that the string is parsed using white space as the delimiter via the StringTokenizer class.

Stumbling into an IllegalThreadStateException

The first pitfall relating to Runtime.exec() is the IllegalThreadStateException. The prevalent first test of an API is to code its most obvious methods. For example, to execute a process that is external to the Java VM, we use the exec() method. To see the value that the external process returns, we use the exitValue() method on the Process class. In our first example, we will attempt to execute the Java compiler (javac.exe):

Listing 4.1 BadExecJavac.java

import java.util.*;

import java.io.*;

public class BadExecJavac

{

    public static void main(String args[])

    {

        try

        {            

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("javac");

            int exitVal = proc.exitValue();

            System.out.println("Process exitValue: " + exitVal);

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

A run of BadExecJavac produces:

E:\classes\com\javaworld\jpitfalls\article2>java BadExecJavac

java.lang.IllegalThreadStateException: process has not exited

        at java.lang.Win32Process.exitValue(Native Method)

        at BadExecJavac.main(BadExecJavac.java:13)

If an external process has not yet completed, the exitValue() method will throw an IllegalThreadStateException; that's why this program failed. While the documentation states this fact, why can't this method wait until it can give a valid answer?

A more thorough look at the methods available in the Process class reveals a waitFor() method that does precisely that. In fact, waitFor() also returns the exit value, which means that you would not use exitValue() and waitFor() in conjunction with each other, but rather would choose one or the other. The only possible time you would use exitValue() instead of waitFor() would be when you don't want your program to block waiting on an external process that may never complete. Instead of using the waitFor() method, I would prefer passing a boolean parameter called waitFor into the exitValue() method to determine whether or not the current thread should wait. A boolean would be more beneficial because exitValue() is a more appropriate name for this method, and it isn't necessary for two methods to perform the same function under different conditions. Such simple condition discrimination is the domain of an input parameter.

Therefore, to avoid this trap, either catch the IllegalThreadStateException or wait for the process to complete.

Now, let's fix the problem in Listing 4.1 and wait for the process to complete. In Listing 4.2, the program again attempts to execute javac.exe and then waits for the external process to complete:

Listing 4.2 BadExecJavac2.java

import java.util.*;

import java.io.*;

public class BadExecJavac2

{

    public static void main(String args[])

    {

        try

        {            

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("javac");

            int exitVal = proc.waitFor();

            System.out.println("Process exitValue: " + exitVal);

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

Unfortunately, a run of BadExecJavac2 produces no output. The program hangs and never completes. Why does the javac process never complete?

Why Runtime.exec() hangs

The JDK's Javadoc documentation provides the answer to this question:

Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock.

Is this just a case of programmers not reading the documentation, as implied in the oft-quoted advice: read the fine manual (RTFM)? The answer is partially yes. In this case, reading the Javadoc would get you halfway there; it explains that you need to handle the streams to your external process, but it does not tell you how.

Another variable is at play here, as is evident by the large number of programmer questions and misconceptions concerning this API in the newsgroups: though Runtime.exec() and the Process APIs seem extremely simple, that simplicity is deceiving because the simple, or obvious, use of the API is prone to error. The lesson here for the API designer is to reserve simple APIs for simple operations. Operations prone to complexities and platform-specific dependencies should reflect the domain accurately. It is possible for an abstraction to be carried too far. The JConfig library provides an example of a more complete API to handle file and process operations (see Resources below for more information).

Now, let's follow the JDK documentation and handle the output of the javac process. When you run javac without any arguments, it produces a set of usage statements that describe how to run the program and the meaning of all the available program options. Knowing that this is going to the stderr stream, you can easily write a program to exhaust that stream before waiting for the process to exit. Listing 4.3 completes that task. While this approach will work, it is not a good general solution. Thus, Listing 4.3's program is named MediocreExecJavac; it provides only a mediocre solution. A better solution would empty both the standard error stream and the standard output stream. And the best solution would empty these streams simultaneously (I'll demonstrate that later).

Listing 4.3 MediocreExecJavac.java

import java.util.*;

import java.io.*;

public class MediocreExecJavac

{

    public static void main(String args[])

    {

        try

        {            

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("javac");

            InputStream stderr = proc.getErrorStream();

            InputStreamReader isr = new InputStreamReader(stderr);

            BufferedReader br = new BufferedReader(isr);

            String line = null;

            System.out.println("<ERROR>");

            while ( (line = br.readLine()) != null)

                System.out.println(line);

            System.out.println("</ERROR>");

            int exitVal = proc.waitFor();

            System.out.println("Process exitValue: " + exitVal);

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

A run of MediocreExecJavac generates:

E:\classes\com\javaworld\jpitfalls\article2>java MediocreExecJavac

<ERROR>

Usage: javac <options> <source files>

where <options> includes:

  -g                     Generate all debugging info

  -g:none                Generate no debugging info

  -g:{lines,vars,source} Generate only some debugging info

  -O                     Optimize; may hinder debugging or enlarge class files

  -nowarn                Generate no warnings

  -verbose               Output messages about what the compiler is doing

  -deprecation           Output source locations where deprecated APIs are used

  -classpath <path>      Specify where to find user class files

  -sourcepath <path>     Specify where to find input source files

  -bootclasspath <path>  Override location of bootstrap class files

  -extdirs <dirs>        Override location of installed extensions

  -d <directory>         Specify where to place generated class files

  -encoding <encoding>   Specify character encoding used by source files

  -target <release>      Generate class files for specific VM version

</ERROR>

Process exitValue: 2

So, MediocreExecJavac works and produces an exit value of 2. Normally, an exit value of 0 indicates success; any nonzero value indicates an error. The meaning of these exit values depends on the particular operating system. A Win32 error with a value of 2 is a "file not found" error. That makes sense, since javac expects us to follow the program with the source code file to compile.

Thus, to circumvent the second pitfall -- hanging forever in Runtime.exec() -- if the program you launch produces output or expects input, ensure that you process the input and output streams.

Assuming a command is an executable program

Under the Windows operating system, many new programmers stumble upon Runtime.exec() when trying to use it for nonexecutable commands like dir and copy. Subsequently, they run into Runtime.exec()'s third pitfall. Listing 4.4 demonstrates exactly that:

Listing 4.4 BadExecWinDir.java

import java.util.*;

import java.io.*;

public class BadExecWinDir

{

    public static void main(String args[])

    {

        try

        {            

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("dir");

            InputStream stdin = proc.getInputStream();

            InputStreamReader isr = new InputStreamReader(stdin);

            BufferedReader br = new BufferedReader(isr);

            String line = null;

            System.out.println("<OUTPUT>");

            while ( (line = br.readLine()) != null)

                System.out.println(line);

            System.out.println("</OUTPUT>");

            int exitVal = proc.waitFor();            

            System.out.println("Process exitValue: " + exitVal);

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

A run of BadExecWinDir produces:

E:\classes\com\javaworld\jpitfalls\article2>java BadExecWinDir

java.io.IOException: CreateProcess: dir error=2

        at java.lang.Win32Process.create(Native Method)

        at java.lang.Win32Process.<init>(Unknown Source)

        at java.lang.Runtime.execInternal(Native Method)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at BadExecWinDir.main(BadExecWinDir.java:12)

Listing 4.5 GoodWindowsExec.java

import java.util.*;

import java.io.*;

class StreamGobbler extends Thread

{

    InputStream is;

    String type;

    StreamGobbler(InputStream is, String type)

    {

        this.is = is;

        this.type = type;

    }

    public void run()

    {

        try

        {

            InputStreamReader isr = new InputStreamReader(is);

            BufferedReader br = new BufferedReader(isr);

            String line=null;

            while ( (line = br.readLine()) != null)

                System.out.println(type + ">" + line);    

            } catch (IOException ioe)

              {

                ioe.printStackTrace();  

              }

    }

}

public class GoodWindowsExec

{

    public static void main(String args[])

    {

        if (args.length < 1)

        {

            System.out.println("USAGE: java GoodWindowsExec <cmd>");

            System.exit(1);

        }

        try

        {            

            String osName = System.getProperty("os.name" );

            String[] cmd = new String[3];

            if( osName.equals( "Windows NT" ) )

            {

                cmd[0] = "cmd.exe" ;

                cmd[1] = "/C" ;

                cmd[2] = args[0];

            }

            else if( osName.equals( "Windows 95" ) )

            {

                cmd[0] = "command.com" ;

                cmd[1] = "/C" ;

                cmd[2] = args[0];

            }

            Runtime rt = Runtime.getRuntime();

            System.out.println("Execing " + cmd[0] + " " + cmd[1]

                               + " " + cmd[2]);

            Process proc = rt.exec(cmd);

            // any error message?

            StreamGobbler errorGobbler = new

                StreamGobbler(proc.getErrorStream(), "ERROR");            

            // any output?

            StreamGobbler outputGobbler = new

                StreamGobbler(proc.getInputStream(), "OUTPUT");

            // kick them off

            errorGobbler.start();

            outputGobbler.start();

            // any error???

            int exitVal = proc.waitFor();

            System.out.println("ExitValue: " + exitVal);        

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

Running GoodWindowsExec with the dir command generates:

E:\classes\com\javaworld\jpitfalls\article2>java GoodWindowsExec "dir *.java"

Execing cmd.exe /C dir *.java

OUTPUT> Volume in drive E has no label.

OUTPUT> Volume Serial Number is 5C5F-0CC9

OUTPUT>

OUTPUT> Directory of E:\classes\com\javaworld\jpitfalls\article2

OUTPUT>

OUTPUT>10/23/00  09:01p                   805 BadExecBrowser.java

OUTPUT>10/22/00  09:35a                   770 BadExecBrowser1.java

OUTPUT>10/24/00  08:45p                   488 BadExecJavac.java

OUTPUT>10/24/00  08:46p                   519 BadExecJavac2.java

OUTPUT>10/24/00  09:13p                   930 BadExecWinDir.java

OUTPUT>10/22/00  09:21a                 2,282 BadURLPost.java

OUTPUT>10/22/00  09:20a                 2,273 BadURLPost1.java

... (some output omitted for brevity)

OUTPUT>10/12/00  09:29p                   151 SuperFrame.java

OUTPUT>10/24/00  09:23p                 1,814 TestExec.java

OUTPUT>10/09/00  05:47p                23,543 TestStringReplace.java

OUTPUT>10/12/00  08:55p                   228 TopLevel.java

OUTPUT>              22 File(s)         46,661 bytes

OUTPUT>                         19,678,420,992 bytes free

ExitValue: 0

Running GoodWindowsExec with any associated document type will launch the application associated with that document type. For example, to launch Microsoft Word to display a Word document (i.e., one with a .doc extension), type:

>java GoodWindowsExec "yourdoc.doc"

Notice that GoodWindowsExec uses the os.name system property to determine which Windows operating system you are running -- and thus determine the appropriate command interpreter. After executing the command interpreter, handle the standard error and standard input streams with the StreamGobbler class. StreamGobbler empties any stream passed into it in a separate thread. The class uses a simple String type to denote the stream it empties when it prints the line just read to the console.

Thus, to avoid the third pitfall related to Runtime.exec(), do not assume that a command is an executable program; know whether you are executing a standalone executable or an interpreted command. At the end of this section, I will demonstrate a simple command-line tool that will help you with that analysis.

It is important to note that the method used to obtain a process's output stream is called getInputStream(). The thing to remember is that the API sees things from the perspective of the Java program and not the external process. Therefore, the external program's output is the Java program's input. And that logic carries over to the external program's input stream, which is an output stream to the Java program.

Runtime.exec() is not a command line

One final pitfall to cover with Runtime.exec() is mistakenly assuming that exec() accepts any String that your command line (or shell) accepts. Runtime.exec() is much more limited and not cross-platform. This pitfall is caused by users attempting to use the exec() method to accept a single String as a command line would. The confusion may be due to the fact that command is the parameter name for the exec() method. Thus, the programmer incorrectly associates the parameter command with anything that he or she can type on a command line, instead of associating it with a single program and its arguments. In listing 4.6 below, a user tries to execute a command and redirect its output in one call to exec():

Listing 4.6 BadWinRedirect.java

import java.util.*;

import java.io.*;

// StreamGobbler omitted for brevity

public class BadWinRedirect

{

    public static void main(String args[])

    {

        try

        {            

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("java jecho 'Hello World' > test.txt");

            // any error message?

            StreamGobbler errorGobbler = new

                StreamGobbler(proc.getErrorStream(), "ERROR");            

            // any output?

            StreamGobbler outputGobbler = new

                StreamGobbler(proc.getInputStream(), "OUTPUT");

            // kick them off

            errorGobbler.start();

            outputGobbler.start();

            // any error???

            int exitVal = proc.waitFor();

            System.out.println("ExitValue: " + exitVal);        

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

Running BadWinRedirect produces:

E:\classes\com\javaworld\jpitfalls\article2>java BadWinRedirect

OUTPUT>'Hello World' > test.txt

ExitValue: 0

The program BadWinRedirect attempted to redirect the output of an echo program's simple Java version into the file test.txt. However, we find that the file test.txt does not exist. The jecho program simply takes its command-line arguments and writes them to the standard output stream. (You will find the source for jecho in the source code available for download in Resources.) In Listing 4.6, the user assumed that you could redirect standard output into a file just as you could on a DOS command line. Nevertheless, you do not redirect the output through this approach. The incorrect assumption here is that the exec() method acts like a shell interpreter; it does not. Instead, exec() executes a single executable (a program or script). If you want to process the stream to either redirect it or pipe it into another program, you must do so programmatically, using the java.io package. Listing 4.7 properly redirects the standard output stream of the jecho process into a file.

Listing 4.7 GoodWinRedirect.java

import java.util.*;

import java.io.*;

class StreamGobbler extends Thread

{

    InputStream is;

    String type;

    OutputStream os;

    StreamGobbler(InputStream is, String type)

    {

        this(is, type, null);

    }

    StreamGobbler(InputStream is, String type, OutputStream redirect)

    {

        this.is = is;

        this.type = type;

        this.os = redirect;

    }

    public void run()

    {

        try

        {

            PrintWriter pw = null;

            if (os != null)

                pw = new PrintWriter(os);

            InputStreamReader isr = new InputStreamReader(is);

            BufferedReader br = new BufferedReader(isr);

            String line=null;

            while ( (line = br.readLine()) != null)

            {

                if (pw != null)

                    pw.println(line);

                System.out.println(type + ">" + line);    

            }

            if (pw != null)

                pw.flush();

        } catch (IOException ioe)

            {

            ioe.printStackTrace();  

            }

    }

}

public class GoodWinRedirect

{

    public static void main(String args[])

    {

        if (args.length < 1)

        {

            System.out.println("USAGE java GoodWinRedirect <outputfile>");

            System.exit(1);

        }

        try

        {            

            FileOutputStream fos = new FileOutputStream(args[0]);

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec("java jecho 'Hello World'");

            // any error message?

            StreamGobbler errorGobbler = new

                StreamGobbler(proc.getErrorStream(), "ERROR");            

            // any output?

            StreamGobbler outputGobbler = new

                StreamGobbler(proc.getInputStream(), "OUTPUT", fos);

            // kick them off

            errorGobbler.start();

            outputGobbler.start();

            // any error???

            int exitVal = proc.waitFor();

            System.out.println("ExitValue: " + exitVal);

            fos.flush();

            fos.close();        

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

Running GoodWinRedirect produces:

E:\classes\com\javaworld\jpitfalls\article2>java GoodWinRedirect test.txt

OUTPUT>'Hello World'

ExitValue: 0

After running GoodWinRedirect, test.txt does exist. The solution to the pitfall was to simply control the redirection by handling the external process's standard output stream separately from the Runtime.exec() method. We create a separate OutputStream, read in the filename to which we redirect the output, open the file, and write the output that we receive from the spawned process's standard output to the file. Listing 4.7 completes that task by adding a new constructor to our StreamGobbler class. The new constructor takes three arguments: the input stream to gobble, the type String that labels the stream we are gobbling, and the output stream to which we redirect the input. This new version of StreamGobbler does not break any of the code in which it was previously used, as we have not changed the existing public API -- we only extended it.

Since the argument to Runtime.exec() is dependent on the operating system, the proper commands to use will vary from one OS to another. So, before finalizing arguments to Runtime.exec() and writing the code, quickly test the arguments. Listing 4.8 is a simple command-line utility that allows you to do just that.

Here's a useful exercise: try to modify TestExec to redirect the standard input or standard output to a file. When executing the javac compiler on Windows 95 or Windows 98, that would solve the problem of error messages scrolling off the top of the limited command-line buffer.

Listing 4.8 TestExec.java

import java.util.*;

import java.io.*;

// class StreamGobbler omitted for brevity

public class TestExec

{

    public static void main(String args[])

    {

        if (args.length < 1)

        {

            System.out.println("USAGE: java TestExec \"cmd\"");

            System.exit(1);

        }

        try

        {

            String cmd = args[0];

            Runtime rt = Runtime.getRuntime();

            Process proc = rt.exec(cmd);

            // any error message?

            StreamGobbler errorGobbler = new

                StreamGobbler(proc.getErrorStream(), "ERR");            

            // any output?

            StreamGobbler outputGobbler = new

                StreamGobbler(proc.getInputStream(), "OUT");

            // kick them off

            errorGobbler.start();

            outputGobbler.start();

            // any error???

            int exitVal = proc.waitFor();

            System.out.println("ExitValue: " + exitVal);

        } catch (Throwable t)

          {

            t.printStackTrace();

          }

    }

}

Running TestExec to launch the Netscape browser and load the Java help documentation produces:

E:\classes\com\javaworld\jpitfalls\article2>java TestExec "e:\java\docs\index.html"

java.io.IOException: CreateProcess: e:\java\docs\index.html error=193

        at java.lang.Win32Process.create(Native Method)

        at java.lang.Win32Process.<init>(Unknown Source)

        at java.lang.Runtime.execInternal(Native Method)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at TestExec.main(TestExec.java:45)

Our first test failed with an error of 193. The Win32 error for value 193 is "not a valid Win32 application." This error tells us that no path to an associated application (e.g., Netscape) exists, and that the process cannot run an HTML file without an associated application.

Therefore, we try the test again, this time giving it a full path to Netscape. (Alternately, we could add Netscape to our PATH environment variable.) A second run of TestExec produces:

E:\classes\com\javaworld\jpitfalls\article2>java TestExec

"e:\program files\netscape\program\netscape.exe e:\java\docs\index.html"

ExitValue: 0

This worked! The Netscape browser launches, and it then loads the Java help documentation.

One additional improvement to TestExec would include a command-line switch to accept input from standard input. You would then use the Process.getOutputStream() method to pass the input to the spawned external program.

To sum up, follow these rules of thumb to avoid the pitfalls in Runtime.exec(): You cannot obtain an exit status from an external process until it has exited You must immediately handle the input, output, and error streams from your spawned external process You must use Runtime.exec() to execute programs You cannot use Runtime.exec() like a command line

Correction to Pitfall 3

In the discussion of Pitfall 3 ("Don't mix floats and doubles when generating text or XML messages") in my last column, I incorrectly stated that the different string representation of a decimal number after casting it from a float to a double was a bug. While this is a pitfall, its cause is not a bug, but the fact that the decimal numbers in question -- 100.28 and 91.09 -- do not represent precisely in binary. I'd like to thank Thomas Okken and the others who straightened me out. If you enjoy discussing the finer points of numerical methods, you can email Thomas.

The combination of forgetting my numerical methods class, the numerous bug reports on the bug parade, and the automatic rounding of floats and doubles when printing (but not after casting a float to a double) threw me. I apologize for confusing anyone who read the article, especially to new Java programmers. I present two better solutions to the problem:

The first possible solution is to always specify the desired rounding explicitly with NumberFormat. In my case, I use the float and double to represent dollars and cents; therefore, I need only two significant digits. Listing C3.1 demonstrates how to use the NumberFormat class to specify a maximum of two fraction digits.

Listing C3.1 FormatNumbers.java

import java.text.*;

public class FormatNumbers

{

    public static void main(String [] args)

    {

        try

        {

            NumberFormat fmt = NumberFormat.getInstance();

            fmt.setMaximumFractionDigits(2);

            float f = 100.28f;

            System.out.println("As a float        : " + f);

            double d = f;

            System.out.println("Cast to a double  : " + d);

            System.out.println("Using NumberFormat: " + fmt.format(d));            

        } catch (Throwable t)

          {

            t.printStackTrace();

          }          

    }

}

When we run the FormatNumbers program, it produces:

E:\classes\com\javaworld\jpitfalls\article2>java FormatNumbers

As a float        : 100.28

Cast to a double  : 100.27999877929688

Using NumberFormat: 100.28

As you can see -- regardless of whether we cast the float to a double -- when we specify the number of digits we want, it properly rounds to that precision -- even if the number is infinitely repeating in binary. To circumvent this pitfall, control the formatting of your doubles and floats when converting to a String.

A second, simpler solution would be to not use a float to represent cents. Integers (number of pennies) can represent cents, with a legal range of 0 to 99. You can check the range in the mutator method.

评论：没有评论。

发表评论请输入评论

引文来源  (转贴)Runtime.exec()的陷阱 - westwin的专栏 - CSDNBlog

I Love parkour! 

----------------------------
一键转贴，快速捕捉生活精彩，赢每周好礼！查看活动首页>>

        http://www.open-open.com/ajax/

        真是越来越爱你了！

        由我、王铮、马连浩共同翻译的《Rails项目实战剖析与技巧大全》 一书，已经在电子工业出版社的网站上发布了订购信息，相信马上就能与大家见面了。
       PS： 其中的内容简介不知道是谁写的，我不是太满意。。。可能是考虑到我比较忙，出版社自己搞定了，不管怎样，还是感谢一下：）

地址如下

http://www.phei.com.cn/bookshop/bookinfo.asp?bookcode=TP068770%20&booktype=main

现在正在翻《Ajax Security》一书，说实话，这本书写的真是挺好的（绝不是老王买瓜）。幸好以前做过很多网络安全方面的研究，现在在Ajax开发中结合思考一下，发现以前写的许多程序还是挺危险的（自己寒一个）。。。不过内容比较多，翻译的时间可能会稍微长些，也是本着对读者负责的态度，希望朋友们不要着急，估计12月份能够上市。

----------------------------
一键转贴，快速捕捉生活精彩，赢每周好礼！查看活动首页>>

        最近在项目中要做Google Suggestion的效果，采用了Scriptaculous的AutoComplete控件，后发现其对中文支持不是很好，而且没有Focus事件，所以修改了一下源代码，在此分享。

       关于中文，我是进行了两次encodeURIComponent编码，修改代码中的

Ajax.Autocompleter = Class.create(Autocompleter.Base, {
  initialize: function(element, update, url, options) {
    this.baseInitialize(element, update, options);
    this.options.asynchronous  = true;
    this.options.onComplete    = this.onComplete.bind(this);
    this.options.defaultParams = this.options.parameters || null;
    this.url                   = url;
  },

  getUpdatedChoices: function() {
    this.startIndicator();
   
    var entry = encodeURIComponent(this.options.paramName) + '=' +
      encodeURIComponent(encodeURIComponent(this.getToken()));
    this.options.parameters = this.options.callback ?
      this.options.callback(this.element, entry) : entry;

    if(this.options.defaultParams)
      this.options.parameters += '&' + this.options.defaultParams;
    new Ajax.Request(this.url, this.options);
  },

  onComplete: function(request) {
    this.updateChoices(request.responseText);
  }
});

在Java中用

String name = java.net.URLDecoder.decode(request.getParameter("name"),"UTF-8");

就可以取出

focus事件

    Event.observe(this.element, 'blur', this.onBlur.bindAsEventListener(this));
    Event.observe(this.element, 'keyup', this.onKeyPress.bindAsEventListener(this));

添加

    Event.observe(this.element, 'focus', this.onFocus.bindAsEventListener(this));

然后添加方法

activate: function() {
    this.changed = false;
    this.hasFocus = true;
    this.getUpdatedChoices();
  },

onFocus: function() {
    this.changed = false;
    this.hasFocus = true;
    this.getUpdatedChoices();
  },

或者直接

 Event.observe(this.element, 'focus', this.activate.bindAsEventListener(this));

JQuery的插件也存在相应的问题，也可以这样来修改

----------------------------
一键转贴，快速捕捉生活精彩，赢每周好礼！查看活动首页>>

作为世界最著名的搜索引擎之一，Google公司的市值已飙升至500亿英镑。想象中在这种大公司工作必定会忙得呼喘气都得计算时间，事实上Google美国总部内部的工作环境却以不拘一格出名：员工没有专门制服，他们爱穿什么就穿什么。甚至连老板的办公桌上也乱糟糟地堆着一堆儿童拼装玩具！前去采访的美国记者都大跌眼镜。

这不，不久前，美国《时代周刊》又发布了一组有关Google总部Googleplex的照片，看罢不禁感慨：人家怎么能把美容院、高尔夫球场、游乐园、游泳池……都搬到公司里？员工还能带着自己的狗狗来上班？唉，“腐败”呀！可是，这样的工作谁不爱？难怪李开复博士也被挖了过来……

Google总部Googleplex位于美国加州山景城，图为Google员工使用滑板车往来于不同的工作场所。

桌上的各类小玩意和熔岩灯向我们展示了Google宽松的工作环境。

技术人员24小时待命，计算机或其他数码产品可以随时送修。

Google员工在公司总部的迷你泳池内游泳（居然还配备了救生员！）。

两名Google员工坐在灵感涂鸦板前享用工间咖啡。

在员工休息室打桌球。

Google与专业发型设计师签有合约，员工在这里美发可以打折。

午休时间，Google员工在公司沙地球场打排球。

Google每天三次向员工提供美味餐点，图为员工在自助餐厅就餐，墙上所挂绘画作品均为Google员工自己所作。

公司内部员工子女托管中心，当然各类电动玩具必不可少。

Google员工可到公司赞助的按摩休息室按摩，消除一日的工作疲劳。

Google的员工甚至可以带上自己的宠物狗到公司上班！（但不可以带猫）。

Google总部的工作环境轻松写意，摒弃了一般企业所具有的繁文缛节，处处体现以人为本的管理理念，正如一位公司代表所言，“我们没有正式的公司文化，因为这样比较容易激发创意和灵感。”

看留言就行了，我就不发表什么评论了。。。

据 网易新闻 报道： 中国地震科考队称在四川取得世界级突破

核心提示：科考队在地震当天赶赴四川，首先进行救援，之后做评估、科考。获得的第一首数据将为震后重建提供防震数据。查看全文>>

网易网友对这条新闻的看法是：