닷넷 환경이란 어떠한 운영체제에서도 닷넷 플랫폼만 설치되어 있다면 플랫폼 독립적으로 프로그램들을 실행할 수 있습니다. 자바의 플랫폼 독립성은 닷넷의 플랫폼 독립성과 일치합니다. 현재 자바는 UNIX, Window, Mac등의 플랫폼에서 동작하지만 닷넷 플랫폼은 아직 윈도우 환경밖에는 지원하지 않습니다. 가까운 미래에는 플랫폼의 독립성을 지원할 수 있을 것입니다.
Common Type System와 Common Language Specification
닷넷에서 지원하는 언어는 여러 종류가 있습니다. 예로 자바가상머신에서 동작하는 프로그램은 자바로 일축 됩니다. 하지만 닷넷은 C# 이외에 다양한 언어를 지원하고 있습니다. 이러한 언어의 상호 융통성을 발휘하게 해 주는 것이 바로 CTS(Common Type System)와 CLS(Common Language Specification)입니다.
|
▣ 닷넷에서 언어의 호환성을 위한 도구 |
|
q CTS(Common Type System) n .Net환경에서 데이터의 형을 관리하는 시스템 q CLS(Common Lanaguae Specification) n CTS에서 지원하는 언어의 일반적인 규약을 정의 |
CTS는 서로 다른 언어로 작성되었다 하더라도 .Net에서 이해할 수 있는 데이터 형식인지 아닌지를 테스트하고 검증 관리하는 역할을 담당합니다. .Net 내에서 동작할 수 있는 데이터 형에 대한 관리를 해주는 것이 바로 CTS(Common Type System)입니다. 그리고 CLS(Common Language Specification)는 .Net을 위한 모든 컴파일러가 지원해야 하는 최소한의 표준 규약입니다.즉, CLS는 .Net의 CTS와 IL을 지원하기 위한 최소한의 규약을 말하는 것입니다. 적어도 .Net에서 동작하기 위해서는 반드시 지켜야 하는 언어 스펙인 것입니다.
결론적으로 CTS를 위한 언어적인 규칙을 CLS에서 명시하고 있다고 생각하시면 됩니다. 만약 여러분이 Visual C++에서 만든 프로그램을 C#에서 이용하고자 하거나 Visual Basic에서 만든 프로그램을 C#에서 이용하고자 한다면 Visual C++는 Managed C++ 프로그램 형식으로 되어 있어야 하며 CLS의 규칙을 따라야만이 C#에서 이용할 수 있습니다. 물론, VB.Net 또한 CLS의 규칙을 따라야 하는 것은 마찬가지 입니다.
기계어와 중간언어(Intermediate Lanaguage)
언어의 상호융통성을 가능하게 해주는 강력한 요소가 중간언어(IL) 형태로 컴파일이 된다는 것입니다. .Net을 직접 지원하는 코드(Managed Code)는 반드시 중간언어 형태로 컴파일 됩니다.
고래적 기계어를 생각해 보죠. 기계어는 완전한 2진 코드로 이루어져 있습니다. 인간이 기계명령을 2진 코드로 직접 내리는 것은 거의 불가능합니다. 물론, 2진코드 명령을 직접 찾아서 내린다면 어쩔 수 없겠죠. 이러한 문제의 해결을 위해서 중간단계로 2진 코드 명령에 사람이 알기 쉬운 이름을 붙이는 것입니다. 이러한 방식으로 2진 코드 명령에 인식할 수 있는 이름을 붙인 언어가 어셈블리(Assembly) 언어입니다. 물론, 이 Assembly는 기계어와 거의 1:1 매칭 될 정도로 기계어에 가까운 언어였습니다.
|
☞ Assembly |
이곳에서 논하는 Assembly는 언어의 일종으로 뒤에서 설명할 C#의 Assembly와는 전혀 다른 개념이다. 초기 C언어 이전의 기계어에 가까운 언어를 Assembly 언어라고 하였으며 C#에서는 컴파일한 후 여러 파일을 묶어서 라이브러리 형태로 묶어 둔 형태를 Assembly라고 한다. |
세월은 흘러 언어가 더욱 발전을 하고 고급으로 가면서 이 과정은 점점 인간이 이해하기 쉬운 범주로 바뀌었습니다. 하지만 이러한 언어는 반드시 기계어로 바뀌어야 한다는 것입니다. 즉, 기계가 이해할 수 있는 언어로 바꾸어야 한다는 것입니다. 예를 들어 대부분의 A라는 언어는 A언어의 해석기가 기계어로 바꿀 수 있었습니다. 하지만 언어에 따라 기계어로 변환하는 방법은 전부 다른 언어 의존적인 형태입니다.
|
▣ 중간언어(Intermediate Language) |
|
q Java의 바이트코드(Byte Code) n 자바의 중간적인 개념의 언어 형태를 바이트코드라고 함 q C#의 중간언어(IL) n C#의 중간적인 개념의 언어 형태를 IL이라고 함 q 바이트코드, 중간언어(IL) n 자바의 바이트코드와 .Net의 중간언어 개념은 똑 같은 개념이다. q 차이점 n 바이트코드는 자바만을 위한 코드이지만 중간언어(IL)은 VB.Net, C#, Managed C++, JScript.Net 등 다양한 언어를 중간 코드 형태로 만든다. |
이러한 단계에서 .Net은 결론을 내립니다. 모든 언어는 중간언어(IL)로 만들면 된다는 것입니다. 즉, 언어와 기계어 사이에 한 단계를 더 두는 것입니다. C#과 VB.Net 사용자들은 컴파일을 해서 기계어로 바뀌는 것이 아니라 기계가 이해하기 쉽도록 만든 중간언어 형태로 만든다는 것입니다. 이러한 중간언어 형태의 표준을 CTS와 CLS가 책임지는 것입니다. 이렇게 되면 언어 사이의 호환성 문제 뿐만 아니라 플랫폼에 독립적인 프로그램을 작성할 수 있습니다. 아마 이것이 범용적으로 모든 언어에 적용된다면 MS는 또다시 프로그램 세계의 제왕이 될 것입니다.
그렇다면 완전한 기계어는 누가 만들까요. 이것은 .Net이 알아서 해줍니다. .Net에서 중간언어가 로드 되었을 때 순간적으로 컴파일을 해주는 JIT(Just-In-Time) 컴파일러가 알아서 해 줍니다.
.Net과 Java
.Net은 CLS, CTS, IL, JIT 컴파일러의 절묘한 조화로 이루어져 있습니다. .Net은 여러 언어를 한꺼번에 지원하며 이것은 닷넷의 개념들이 이를 뒷받침 해주기 때문에 가능한 것입니다. 대부분의 닷넷의 용어에 Common이라는 용어가 말해 주듯이 공통된 언어스펙(CLS), 공통된 타입시스템(CTS)이라고 하는 것도 닷넷의 다양한 언어의 수용 때문에 그런 것입니다.
혹자는 이러한 말을 할 것입니다. 자바는 인터프리터 언어이기 때문에 바이트 코드를 컴파일을 하지 않고 바로 해석하기 때문에 빠르다. 하지만 .Net은 중간언어를 JIT를 이용하여 컴파일을 다시 하지 않느냐. 그러면 엄청 느릴 것이다. 이