⑴ 甲骨文公司是什麼意思
甲骨文公司，全稱甲骨文股份有限公司是全球最大的資料庫軟體公司，總部位於美國加州的紅木灘
基本信息
公司類型：上市公司 (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是一個非常好的選擇。