最近在工作上涉及到system的一些源代码，突然想到一个问题：System.out是流，却拥有各种各样的print方法来打印字符，这样大大方便了程序的编写；那么，为什么system.in没有这样的方法呢？

就这个问题我跟同事们探讨了一下，也到usenet上去问了，感谢大家的帮助，最终总结出比较靠谱的解释如下：

System.in与System.out都是字节流而非字符流，PrintStream所做的工作，就是当输出一个非字节流类型的数据的时候，通过平台相关的转换算法将其转化为字节流，但其本质仍然是一个个的字符

而在读取的时候，如果采用相同的处理方法，则会产生这样的一个问题：如何判断一个数据的终止？

就拿int为例，如果读入的int是字符形式的，那如何得知数据长度？没有数据长度就无法停止读取。也许有人提出可以采用分隔符的方式来终止读取，这样做的弊端是作为分隔符的那个字符就被舍弃了，所以sun提供了java.util.scanner来实现此功能而不是将其作为默认配置。如果int是纯字节流呢？那很遗憾，这样就与输出不匹配了，输入输出的一致性始终是最先要考虑的因素。

总的来说，在输出时，java能够清楚地知道用户想输出的是什么，并进行统一的处理；但是在输入时，java难道能够知道用户读的是什么吗？不知道。所以就没有提供一个统一的处理方法，而是交给用户根据自己的需要对输入流进行封装

本文部分内容翻译自ri的java document

ClassLoader，顾名思义，就是用来加载class的。java程序中的所有class都要经由某个classloader的子类来加载

大体上而言，bootstrap classloader负责加载vm启动时所引用的class，extention classloader加载虚拟机需要的扩展class，而system classloader则负责从classpath中寻找各种各样的类

除了bootstrap classloader外，每一个classloader都有一个parent classloader（这是一个field，不是继承关系中的parent），当需要加载一个类时，首先查找这个类是否已经加载过；如果没有，则交由parent classloader去加载；如果parent classloader不能加载，那就由自己加载。当然其中一系列复杂的路径处理权限管理过程被我略掉了。