举个例子，假如有人要用Java实现一个单向链表类，可能会这样写：
// 编译成 java-int-list_1.0.jarpublic final class JavaIntList { static class Node { public Node next; public int value; } public Node head; public int size;}
上述实现为了能够快速获取链表的大小，把链表大小缓存在size变量中。用法如下：
JavaIntList myList = new JavaIntList();System.out.println(myList.size);
JavaIntList的作者很满意，于是开源了java-int-list库的1.0版。文件名是java-int-list_1.0.jar。发布后，吸引了许多用户来使用java-int-list_1.0.jar。
有一天，作者决定要节省内存，不要缓存size变量了，把代码改成这样：
// 编译成 java-int-list_2.0.jarpublic final class JavaIntList { static final class Node { public Node next; public int value; } public Node head; public int getSize() { Node n = head; int i = 0; while (n != null) { n = n.next; i++; } return i; }}
然后发布了2.0版：java-int-list_2.0.jar。发布后，原有java-int-list_1.0.jar的用户纷纷升级版本到2.0。这些用户一升级，就发现自己的程序全部坏掉了，说是找不到什么size变量。于是这些用户就把作者暴打一顿，再也不敢用java-int-list库了。
这个故事告诉我们，如果不想被暴打致死，你就必须保持向后兼容性。太阳公司在设计Java语言时，也懂得这个道理。所以Java标准库中，绝对不会出现public int size这样的代码，而一定会一开始就写成：
private int size;public int getSize() { return size; }
让用户一开始就使用getSize，以便有朝一日修改getSize实现时，不破坏向后兼容性。这种public int getSize() { return size; }的惯用手法，就是Java Bean。
比如，假如有个Scala版的ScalaIntList：
// 编译成 scala-int-list_1.0.jarobject ScalaIntList { final case class Node(next: Node, value: Int)}final class ScalaIntList { var head: ScalaIntList.Node = null var size: Int = 0}
用户这样用：
val myList = new ScalaIntListprintln(myList.size)
有一天你心血来潮改成这样：
// 编译成 scala-int-list_2.0.jarobject ScalaIntList { final case class Node(next: Node, value: Int)}final class ScalaIntList { var head: ScalaIntList.Node = null final def size: Int = { var n = head var i = 0 while (n != null) { n = n.next i++ } i }}
用户还是照样能用，根本不破坏向后兼容性。所以Scala程序只要不考虑和Java交互，一般就不需要类似Java Bean这样的约定。