⑴ 甲骨文公司是什么意思
甲骨文公司，全称甲骨文股份有限公司是全球最大的数据库软件公司，总部位于美国加州的红木滩
基本信息
公司类型：上市公司 (NASDAQ: ORCL)
公司规模：世界五百强
市值：1466.43亿美元（2011年）
年收入：268.2亿美元（2011年）
口号：信息驱动
成立于：加利福尼亚 (1977年)
总部位于：美国加州红木滩市
重要人物：劳伦斯·埃里森 Lawrence (Larry) J. Ellison
产业：数据库软件
雇员数目：108429 （2011年)
CEO:Larry Ellison
Oracle公司（甲骨文公司）是世界上最大的企业软件公司，向遍及145个国家的用户提供数据库、工具和应用软件以及相关的咨询、培训和支持服务。甲骨文公司1989年正式进入中国。
⑵ java中eclipse，jdk,jvm,jre,编译器的区别
Eclipse 是一个开放源代码的、基于Java的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。最初主要用来Java语言开发，通过安装不同的插件Eclipse可以支持不同的计算机语言，比如C++和Python等开发工具。Eclipse的本身只是一个框架平台，但是众多插件的支持使得Eclipse拥有其他功能相对固定的IDE软件很难具有的灵活性。许多软件开发商以Eclipse为框架开发自己的IDE。
JDK是java开发工具包，基本上每个学java的人都会先在机器 上装一个JDK，那他都包含哪几部分呢？看一下JDK的安装目录。在目录下面有 六个文件夹、一个src类库源码压缩包、和其他几个声明文件。其中，真正在运行java时起作用的 是以下四个文件夹：bin、include、lib、 jre。可以看出这样一个关系，JDK包含JRE，而JRE包 含JVM。
bin:最主要的是编译器(javac.exe)
include:java和JVM交互用的头文件
lib：类库
jre:java运行环境
（注意：这里的bin、lib文件夹和jre里的bin、lib是不同的）总的来说JDK是用于java程序的开发,而jre则是只能运行class而没有编译的功能。
eclipse、idea等其他IDE有自己的编译器而不是用JDK bin目录中自带的，所以在安装时会发现他们只要求选中jre路径就ok了。
JVM就是常说的java虚拟机，它是整个java实现跨平台的 最核心的部分，所有的java程序会首先被编译为.class的类文件，这种类文件可以在虚拟机上执行，也就是说class并不直接与机器的操作系统相对应，而是经过虚拟机间接与操作系统交互，由虚拟机将程序解释给本地系统执行。
JVM 是 Java 平台的基础，和实际的机器一样，它也有自己的指令集，并且在运行 时操作不同的内存区域。 JVM 通过抽象操作系统和 CPU 结构，提供了一种与平台无关的代码执行方法，即与特殊的实现方 法、主机硬件、主机操作系统无关。但是在一些小的方面， JVM 的实现也是互不相同的，比如垃圾回收 算法，线程调度算法（可能不同 OS 有不同的实现）。
JVM 的主要工作是解释自己的指令集（即字节码）到 CPU 的指令集或 OS 的系统调用，保护用户免被恶意程序骚扰。 JVM 对上层的 Java 源文件是不关心的，它关注的只是由源文件生成的类文件（ class file ）。类文件的 组成包括 JVM 指令集，符号表以及一些补助信息。
JRE是指java运行环境。光有JVM还不能成class的执行，因为在解释class的时候JVM需要调用解释所需要的类库lib。 在JDK的安装目录里可以找到jre目录，里面有两个文件夹bin和lib,在 这里可以认为bin里的就是jvm，lib中则是jvm工 作所需要的类库，而jvm和 lib和起来就称为jre。
JRE 是 Sun 公司发布的一个更大的系统，它里面就有一个 JVM 。 JRE 就与具体的 CPU 结构和操作系统有关，从 Sun 下载 JRE 的时候就看到了不同的各种版本。同 JVM 一起组成 JRE 的还有一些 API （如 awt ， swing 等）。 JRE 是运行 Java 程序必不可少的。
JRE （ Java Runtime Environment ），是运行 Java 程序必不可少的（除非用其他一些编译环境编译成.exe可执行文件……），JRE的地位就象一台PC机一样，写好的Win32应用程序需要操作系统帮助运行，同样的，编写的Java程序也必须要JRE才能运行。
JRE里面有一个 JVM ， JRE 与具体的 CPU 结构和操作系统有关，从 Sun 下载 JRE 的时候就看到了不同的各种版本，同 JVM 一起组成 JRE 的还有 一些 API （如 awt ， swing 等）， JRE 是运行 Java 程序必不可少的。
⑶ free pascal 和 lazarus 有什么区别
本人已经离开软件行业多年了，现在主要是做做小生意，炒炒股票，但也经常关注一下软件业的发展，这几天心血来潮，下了个LAZARUS，玩了一下，一下子被它迷住了，感叹真是太牛了！现在把这几天玩的感受写下来，从各个方面比较，供大家看看。
先说下LAZARUS是个啥东西，它是一个OBJECT PASCAL的集成开发环境，其编译器用的是FREE PASCAL，跟DELPHI 几乎一个模样，很多基本的单元，类库，都是用同样的名字，会DELPHI 的人毫不费力就可以使用LAZARUS，凡是FREE PASCAL编译器能运行的平台，LAZARUS就能运行，口号是：“一次编写，到处编译”，官方网站是：http://www.freepascal.org/
为了简单点，把FREE PASCAL/LAZARUS统称为FPC
1） 运行硬件平台：
DELPHI ：仅仅在INTEL X86上运行。
FPC： INTEL、POWER PC、SPARC、ARM\ 、Motorola 680x0等，同时还支持64位
2）操作系统：
DELPHI： WINDOWS。
FPC： Linux, FreeBSD, Mac OS X, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic) and MorphOS，其最新版本2.4还支持IPHONE、SymbianOS。看起来比DELPHI 多的多了。
更牛的是：可以为没有操作系统的一些微控制器开发程序！从这点上，可以与C平起平坐了。
3） 图形库接口
DELPHI(VCL) ： WIN32：
FPC(LCL)： WIN32/64、GTK、QT、WINCE、MAC OS X 的COCOA等等。
4） 第三方控件库：
相对来说，FPC要少些，但现在移植的工作非常快，很多重要的库都可以从DELPHI 那里移过来，比如着名的网络控件INDY 、数据库访问控件：ZEOSLIB都能在LAZARUS下使用了。
我做了下测试，在DELPHI 下创建一个窗体，上面堆满了很多控件，然后在LAZARUS下用它带的功能转换一下，一些最基本的控件（如STANDARD页和ADDTIONAL页的），不用任何修改就能用，其他的有可能用不了，随着以后移植的增多，相信大部分都能用，但在运行的时候，老会出现一个DOS窗口，不知道是啥原因，我还没搞清楚。
5)语言区别：
都是OBJECT PASCAL语言，高度兼容DELPHI ，其类，封装，关键字等都一样，但我发现，FPC在某些方面引用了C的风格，如：+=、 -= 、*=、/=。而在DELPHI中，这是不行的，从我个人角度看，不赞成这种写法，这会让代码变得复杂，破坏PASCAL语言的简明。RTL运行库的函数也几乎全部一样，真的很佩服那些牛人，要搞出这样的东西出来，确实要花不少心血的哦！
在FPC的2.4最新版本中，引进了FOR .. IN .. .DO循环，可以兼容DELPHI 2010了。其实我觉得PASCAL语言中，要把FOR … TO … DO 改进下，增加一个STEP，这样就可以加快某些情况下的循环，而现在只能每次加1个，效率有时候就低了。其他语言都可以的，比如 MODULA都有，不知道以前的BORLAND和现在的CODEGEAR为啥不加？很难吗？
在UNICODE支持方面，FPC早就支持了，DELPHI 直到2009才开始。FPC用的UTF8，DELPHI 用的UCS-2方式。
在测算的时候是不同的，比如一个字符串：“abcdefg程序”，如果在DELPHI 2010中，用LENGTH算出的长度是9，而在FPC中则是13。在UTF8中，非ASCII码用三字节编码，而在DELPHI 中，无论中文英文，都看成是一个字。所以才造成这样的区别。
所以同样的字符串在DELPHI 和FPC中得出不同的长度，千万不要大惊小怪。
在64位支持方面：FPC早就有了，而DELPHI 现在都还没点影，真搞不懂那么多专业工程师怎么干不过这些业余的呢？DELPHI 这几年确实太没落了，啥也没改进，整天跟MS后面玩.NET，结果玩到半途，发现这样玩下去，小命也没了，才又反回来。可惜浪费太多时间了。
6）代码编辑器：
我个人感觉，其编辑器要比DELPHI 7好用，风格跟DELPHI 2010差不多。
7）编译效率：
FPC比DELPHI 要慢一些
8）执行效率：
我写过一个对整数的快速排序算法，随机生成个数，存在数组中，数据规模是5000万，FPC比DELPHI 7要慢30%。
我又测试了浮点数计算：数据规模也是5000万，测试时候分成二个方面：
一个是只做基本的加减乘除：如这样的公式 sum := sqrt(sum+((arr_float[i] / arr_float[i-1]) / 7.7) * 0.056) ; FPC也是比DELPHI 7慢30%左右。
但在进一步测试科学计算时，FPC慢很多了，将近慢1.5倍。如增加了一条语句： sum := power(sum,random * 1.5)+sin(100 * 3.14/180)+cos(100 * 3.14 /180)+log10(sum * 100); 也就是说，FPC在进行POWER，SIN,COS,LOG等函数计算时，效率下降很快，我大致看了下，发现RTL中，FPC是用PASCAL写的函数，而DELPHI 很多使用汇编写的。但如果只是语言差异，效率应该也不会下降那么多，应该还跟一些算法有关。
在这方面，FPC应该还有很大的改善空间，一是提升编译器本身，二是改进RTL库。在RTL库方面，DELPHI 最新的版本中，都引进了开源的FASTCODE，我想FPC应该也可以引进，移植到FPC上面来，这样就可以利用开源的成果，快速提高RTL品质，如果什么都要自己造轮子的话，那效率就会太慢了。
如果FPC在整体效率上能与DELPHI 缩小到10%左右的差距时候，那FPC的实际应用领域就大大拓展了！会给DELPHI 造成极大的威胁。
顺便提一下，前几天下了个DELPHI 2010，跟DELPHI 7对比测试后，发现DELPHI 2010要比DELPHI 7慢那么一点点，大概在3-5%之间。当然，DELPHI 2010也加了很多花哨的东西，比如泛型模板、反射等，由于没有许可，只能用14天，还时不时弹出公司试用许可警告，要重新启动才能用，一怒之下，把它删除了。
9）程序体积：
不得不说，FPC编译后的程序体积太大了，当然，如果去掉调试信息后，体积可大幅度减少，但还是比DELPHI 大很多，这是非常需要改进的地方。
10）结论：
总体上，FREE PASCAL已经很不错了，做一些要求不是很高的软件开发，没啥问题。同时其发展速度很快，假以时日，应该会有很好的表现，特别对于需要做跨平台的开发，FPC是一个非常好的选择。