컴퓨터 언어 혁명은 두 가지 요소에 의해 이루어졌다. 프로그래밍 과학의 진보와 컴퓨터 환경의 변화가 바로 그것이다. 자바도 예외는 아니다. 자바는 C, C++에서 물려받은 풍부한 유산을 선별하여 채택하였고, 그것에 최신 프로그래밍 경향을 반영하는 요소들로 채워졌었다.

온라인 환경의 출현에 맞추어, 자바는 고도의 분산형 구조에 적합한 능률적인 프로그래밍 방식을 제공한다. 자바는 1991년, Sun Microsystems의 제임스 고슬링(James Gosling,) 패트릭 노튼(Patrick Naughton), 크리스 와츠(Chris Warth), 에드 프랭크(Ed Frank), 그리고 마이크 쉐리든(Mike Sheridan)에 의해 창안되었다.

플랫폼 독립적인 언어를 만들자!

초기에 이 언어는 Oak라 명명 되었으나 1995년에 Java로 바뀌었다. 다소 놀라운 일이지만, 원래 자바는 인터넷을 통한 웹 서비스 또는 Android와 같은 모바일 환경을 위해 개발된 것이 아니었다.

자바가 지향했던 것은 토스터, 전자레인지, 리모콘 등의 가전제품에 내장될 소프트웨어를 위한 플랫폼(platform) 독립적인(Independent) 언어였다. 대충 짐작할 수 있듯이 중심 제어기로 사용되는 CPU는 매우 다양하다. 문제는 대부분의 컴퓨터 언어가 특수한 아키텍쳐나 OS에 맞게 컴파일 되도록 설계된다는 것이였다.

Write Once Run Anywhere!

가령 C++를 예를 들어 보자. C++ 프로그램은 모든 종류의 CPU에 맞게 컴파일될 수 있지만, 그것을 위해서는 해당 CPU에 맞는 C++컴파일러가 필요하다. 하지만, 각각의 환경의 컴파일러를 위한 비용은 비싸고 개발하는데 시간이 너무 많이 소요되는 문제가 있다.

좀 더 나은 방식을 찾기 위해 James Gosling 과 그 동료들은 다양한 환경의 CPU에서 실행 되는 코드를 생성 할 수 있는, 이식성이 뛰어난 Cross Platform 언어의 개발에 착수 했다. 이러한 배경을 바탕으로 Write Once, Run Anywhere와 같은 철학을 가지고 있는 자바의 탄생으로 이어 지게된 것 이다.

인터넷과 자바의 만남

자바의 세부적인 부분이 개발되고 있을 무렵, 2차적이긴 하지만 자바의 미래를 결정지을 만큼 중요한 요인이 나타났다. 바로 월드 와이드 웹(WWW) 의 출현 으로, 만일 자바가 개발되던 시기에 웹이 형태를 갖추지 못했다면, 자바는 가전제품의 프로그램 개발에만 쓰이는 언어로 남았을 것이다. 그러나 이식 가능한 언어를 요구하는 웹의 출현으로 인해 자바는 당시 컴퓨터 언어 설계 프로젝트의 선두로 부상하게 된다.

대부분의 프로그래머는 초기 경험을 통해 이식성이 좋은 프로그램은 그만큼 구현하기가 어렵다는 것을 깨닫게 된다. 효율적이며 플랫폼 독립적인 이식성이 뛰어난 프로그램 개발에 대한 요구는 거의 프로그래밍이라는 학문 자체 만큼이나 오래 계속 되어 오긴 했지만, 지금까지는 다른 문제들에 의해 뒷전으로 밀려나 있었다.

그러나, 인터넷과 웹의 출현으로 이식성의 문제가 다시 전면으로 떠올랐다. 아무튼, 인터넷은 다양한 컴퓨터, 운영 체제, 그리고 CPU로 넘쳐나는 광대한 분산형 시스템인 것이다.

한 때는 성가시기만 하고 우선 순위에서도 밀려나 있었던 문제가 이제는 명백하게 가장 중요한 사안이 되어버렸다. 1993년 경, 자바 팀은 임베디드(Embeded) 제어기에서 사용할 코드를 개발할 때 자주 나타나던 이식성의 문제가 인터넷을 위한 코드를 개발할 때도 나타난다는 사실을 알게 되었다.

이리하여 자바의 초점은 가전제품에서 인터넷으로 옮겨지게 된 것이다. 따라서 자바 언어 설계에 최초의 영감을 제공한 것은 아키텍처 중립적인 프로그래밍 언어에 대한 요구이지만 궁극적으로 자바가 대성공을 거두도록 이끈 것은 인터넷이라고 해야 할 것이다.

자바의 발전

인터넷은 자바가 프로그래밍 세계의 전면으로 부상하도록 했으며 자바는 인터넷에 큰 영형을 미쳤다. 이유는 간단하다. 자바가 가상 공간을 자유롭게 돌아 다닐 수 있는 객체의 세계를 확장 했기 때문이다. 네트워크에는 서버와 PC사이에 전송 되는 두 가지 객체 영역이 존재하는데, 수동적 정보와 동적이고 능동적인 프로그램이 그것이다.

예를 들면, e-메일을 읽는 것은 수동적 정보를 보는 것이다. 프로그램을 다운로드할 때도 그것을 실행하기 전까지는 프로그램 코드는 수동적 정보가 된다. 하지만 또 다른 형태의 객체가 PC 컴퓨터에 전송될 수 있는데, 그것이 바로 동적인 자가 실행 프로그램이다. 이러한 프로그램은 서버에 의해 시작되지만 클라이언트 컴퓨터에서 실행된다. 그 예로 서버가 보내는 정보를 클라이언트 컴퓨터의 화면에 표시하기 위해 서버가 제공하는 프로그램을 들 수 있다.

네트워크 상에서 동작하는 프로그램이 동적일수록 보안이나 이식성의 문제가 심각해진다. 자바 이전의 가상 공간은 현재에 존재하는 실체들의 절반에게만 열려 있었다. 자바는 이 문제에 관심을 가졌고, 이 과정에서 애플릿 이라는 새로운 형식의 프로그램을 정의하게 되었다.

JDK와 JRE

JRE(Java Runtime Environment)는 Java 애플리케이션을 실행하기 위한 Java Virtual Machine을 구현하는 환경입니다.

JDK(Java Development Kit)은 Java 기반의 애플리케이션을 개발하는데 필요한 번들을 말한다. JDK는 다양한 도구를 비롯해 JRE 포함하므로 더욱 넓은 디스크 공간이 필요합니다. JDK는 Java 애플리케이션과 애플릿을 작성하는데 필요한 JRE, API 클래스 집합, Java 컴파일러 Web Start 및 추가 파일을 제공합니다.

JVM, JRE, JDK는 플랫폼에 의존적이지만 덕분에 JDK를 통해 작성된 프로그램은 플랫폼 독립적으로 실행될 수가 있습니다.

자바 애플리케이션과 애플릿

자바로 애플리케이션과 애플릿이라는 두 가지 형태의 프로그램을 만들 수 있다. 애플리케이션은 컴퓨터의 운영체제하에서 실행되는 프로그램을 말한다. 자바로 만들어진 프로그램은 비주얼 베이직이나 C++과 같은 그 밖의 컴퓨터 언어로 개발된 프로그램과 비슷하다.

애플리케이션 개발에 쓰일 경우 자바는 다른 컴퓨터 언어와 별반 다르지 않다. 자바를 독특하게 만드는 것은 애플릿을 개발할 수 있는 자바의 기능이다. 애플릿은 인터넷 상에서 전송되고, 자바를 지원하는 웹브라우저에서 실행될 수 있도록 설계된 프로그램이다. 다른 많은 컴퓨터 언어로도 애플리케이션을 개발할 수 있지만 애플릿은 오직 자바로만 개발 할 수 있는 것이다. 자바가 애플릿을 통해 두 가지 곤란한 문제, 즉 보안과 이식성을 해결했기 때문이다. 인터넷과 관련하여 두 용어가 무엇을 의미하는지 알아보자.

애플릿

네트워크에 연결된 컴퓨터의 사용자는 정상적인 프로그램을 다운로드할 때마다 바이러스에 감염될 위험을 안고 있는 것이다. 자바 이전에는 많은 사용자들이 실행 가능한 프로그램을 자주 다운로드하지 않았으며, 다운로드한 경우라도 그것을 실행하기 전에 바이러스 검사를 했었다. 이렇게 신중을 기하더라도, 대부분의 사용자는 그들의 시스템이 바이러스에 감염되거나 악성 프로그램이 시스템에서 마구잡이로 실행되는 것을 우려했다.(악성 프로그램은 개인 컴퓨터의 파일을 조사해서 신용카드 번호, 은행 계좌 잔고 상태, 암호 등의 개인 정보를 빼돌릴 수도 있다)

자바는 사용자의 컴퓨터와 네트워크 애플리케이션 사이에 방화벽(firewall)을 제공하여 이 문제를 해결한다. 자바를 지원하는 웹 브라우저를 사용하면 바이러스 감염에 대한 두려움 없이 안전하게 자바 애플릿을 다운로드할 수 있다. 자바가 사용한 방법은 자바 프로그램이 컴퓨터의 다른 부분에는 접근하지 못하게 하고, 제한된 자바 실행 환경 내에서만 접근할 수 있도록 허용하는 것이다. 사실 클라이언트 컴퓨터에 아무런 해를 끼치지 않고 애플릿을 다운로드하는 기능은 자바의 가장 중요한 부분이다.

이식성

앞서 논한 바와 같이 인터넷에는 다양한 타입의 컴퓨터와 운영체제가 연결되어 있다. 다양한 플랫폼에 동적으로 다운로드되는 프로그램을 위해서는 이식성이 있는 실행 코드를 생성하는 방법이 필요하다. 보안 문제를 해결하는 메커니즘은 이식성 문제를 해결하는 데도 도움이 된다. 이 두 가지 문제에 대한 자바의 솔루션은 우아할 뿐 아니라 효과적이기도 하다.

웹의 발전과 애플릿의 쇠퇴

애플릿은 자바로 작성한 프로그램을 미리 업로드 하고 브라우저 상에서 애플릿 태그로 불러온다. 애플릿 태그가 실행되면 브라우저에서는 프로그램을 다운로드 한 다음 실행한다. 방식으로 보자면 액티브X, 어도비 플래시 및 AIR, 실버라이트와 크게 다를 것은 없지만, 특징은 운영체제 상에서 직접 실행되는 것이 아니라 자바답게 자바 가상 머신에서 실행된다. 따라서 애플릿을 실행하려면 자바 가상머신을 운영체제에 미리 깔아야 한다.

액티브X보다는 이미지가 좋은 편이지만, 애플릿 역시 시간이 지날수록 만만치 않게 엄청난 보안 구멍이 있었다. 일반적인 액티브X와는 달리 운영체제와 통합된게 아니라 자바 가상머신에서 돌아가므로 조금 나을 수도 있지만, 초기에는 별 제한 없이 로컬 파일을 액세스 할 수 있었으므로 보안이 뚫린 적도 꽤 많았다. 후에 지속적으로 보안 패치를 했지만 취약점 없는 프로그램이란건 사실상 존재하지 않기에 꾸준히 뚫리고, 막는 창과 방패의 전쟁이 지속됐다. 거기다가 자바 가상 머신을 통해서 실행되며 실행 속도가 비교적 느리다.

그 와중에 터진 브라우저에서의 자바 플러그인의 보안 취약성으로 인한 일련의 사고 및 이에 대한 오라클의 뒤늦은 대응은 개발자 뿐 아니라 기업의 IT 인프라의 아키텍쳐를 결정하는 데 영향을 줄 수 있는 경영자를 포함한 일반인들에게 까지 자바에 대한 부정적인 인식을 퍼뜨리는 치명적인 결과를 가져오게 된다.

인터넷의 실행 환경인 웹브라우저가 점점 발전하고 거기다 HTML5, Javascript가 발전하면서 더이상 추가적인 설치가 필요하고 번거로운 애플릿, 플래시같은 웹 플러그인은 그 장점을 점점 잃어갔다.

모질라 재단에서 2015년 10월 파이어폭스에서 NPAPI 플러그인 지원을 중단하겠다는 발표를 했고, 곧 이어 오라클에서는 2016년 1월 Java 9 부터 애플릿을 위한 자바 플러그인 지원을 중단하겠다고 발표했다. 따라서 자바 애플릿은 Java 9 이후 역사속으로 사라질 예정이며, 이후 자바 애플릿이 했던 역할은 유사한 기술인 Java Web Start 가 대신하게 된다.

HTML5에서는 폐지되었으며 대신 embed 태그를 쓴다. 사실 이건 웹 플러그인들의 공통점이다. 널리 쓰이는 플래시랑 AIR, 실버라이트도 보안 문제가 많았다.

Java EE

Java는 이렇게 애플릿이 쇠퇴하였지만 여전히 서버측 애플리케이션을 개발하기 위한 중심적인 역할을 하고 있다. J2EE는 자바를 이용한 서버측 개발을 위한 플랫폼이다. Java EE 플랫폼은 PC에서 동작하는 표준 플랫폼인 Java SE에 부가하여, 웹 애플리케이션 서버에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는 J2EE라 불리었으나 버전 5.0 이후로 Java EE로 개칭되었다.

이러한 Java EE 스펙에 따라 제품으로 구현한 것을 웹 애플리케이션 서버 또는 WAS라 불린다. 현재는 Java EE의 복잡도로 인해 스프링과 같은 프레임워크를 통해 웹 애플리케이션 서버를 개발하는 추세이다.

스프링 프레임워크

스프링은 로드 존슨(Rod Johnson)이 2002년에 출판한 저서 Expert One-on-One J2EE Design and Development에서 선보인 소스 코드를 시작으로 점점 발전하게 되었다. 2003년 6월에 최초로 아파치 라이선스 2.0으로 공개되었다.

동적 웹을 개발하기 위한 어플리케이션 프레임워크로 JVM 환경에서 작동하며 아파치 라이선스 2.0를 따르고 있다. 전자정부 표준 프레임워크의 기반 기술이며 한국정보화진흥원에서 공공기관의 웹 서비스 제공시 권장하고 있다.

스프링 프레임워크(Spring Framework)의 특징은 아래와 같다

  • POJO(Plain Old Java Object) 방식 : POJO는 Java EE 등 무거운 프레임워크들을 사용하면서 해당 프레임워크에 종속되어 있는 무거운 객체들을 만드는 것에 반발하며 나타난 용어다. J2EE Framework에 비해 특정 인터페이스를 구현하거나 상속받을 필요가 없어 기존 라이브러리를 지원하기에 용이하고 객체가 가볍다.

  • 관점 지향 프로그래밍(Aspect Oriented Programming, AOP) : 로깅, 트랜잭션, 보안 등 여러 모듈에서 공통적으로 사용하는 기능을 분리하여 관리할 수 있다. AspectJ를 포함하여 사용할 수 있고, 스프링에서 지원하는 실행에 조합하는 방식도 지원한다.

  • 의존성 주입(Dependency Injection, DI) : 프로그래밍에서 구성요소간의 의존 관계가 소스코드 내부가 아닌 외부의 설정파일을 통해 정의되는 방식이다. 코드 재사용을 높여 소스코드를 다양한 곳에 사용할 수 있으며 모듈간의 결합도도 낮출 수 있다. 계층, 서비스 간에 의존성이 존재하는 경우 스프링 프레임워크가 서로 연결시켜준다.

  • 제어 반전(Inversion of Control, IoC) : 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 외부 라이브러리의 코드를 호출해서 이용했다. 제어 반전은 이와 반대로 외부 라이브러리 코드가 개발자의 코드를 호출하게 된다. 즉, 제어권이 프레임워크에게 있어 필요에 따라 스프링 프레임워크가 사용자의 코드를 호출한다.

  • MVC 패턴(Model-View-Controller pattern, MVC) : 웹 프로그래밍 개발에서 필수적인 디자인 패턴인 MVC 패턴을 사용한다. DispatcherServlet이 Controller를 담당하며 요청에 따라@(Annotation)으로 선언되어 있는 각 서비스로 분산시켜준다.

  • 트랜잭션 관리 : 추상화된 트랜잭션을 XML 설정파일 등을 이용해 관리할 수 있다.

  • 생명주기 : 스프링 프레임워크는 자바 객체의 생성, 소멸을 직접 관리하며 필요한 객체만 사용할 수 있다.

  • 다양한 서비스 : myBatis와 같은 데이터베이스 처리 라이브러리나 tiles 같은 유용한 인터페이스를 제공한다.

웹 애플리케이션 서버

웹 애플리케이션 서버(Web Application Server, WAS)는 인터넷 상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어이다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다. 한국에서는 일반적으로 WAS로 통칭하고 있으며 공공기관에서는 웹 응용 서버로 사용되고, 영어권에서는 Application Server 로 불린다.

안드로이드의 출현

안드로이드(Android)는 휴대 전화를 비롯한 휴대용 장치를 위한 운영 체제와 미들웨어, 사용자 인터페이스 그리고 표준 응용 프로그램(웹 브라우저, 이메일 클라이언트, 단문 메시지 서비스(SMS), 멀티미디어 메시지 서비스(MMS)등을 포함하고 있는 소프트웨어 스택이자 모바일 운영 체제이다. 안드로이드는 개발자들이 자바 언어로 응용 프로그램을 작성할 수 있게 하였으며, 컴파일된 바이트코드를 구동할 수 있는 런타임 라이브러리를 제공한다. 또한 안드로이드 소프트웨어 개발 키트(Android SDK)를 통해 응용 프로그램을 개발하기 위해 필요한 각종 도구들과 API를 제공한다.

안드로이드는 리눅스 커널 위에서 동작하며, 다양한 안드로이드 시스템 구성 요소에서 사용되는 C/C++ 라이브러리들을 포함하고 있다. 안드로이드는 기존의 자바 가상 머신과는 다른 가상 머신인 달빅 가상 머신을 통해 자바로 작성된 응용 프로그램을 별도의 프로세스에서 실행하는 구조로 되어 있다.

Dalvik VM

대부분의 안드로이드 응용 프로그램은 자바로 작성되어 있으나 자바와 안드로이드의 API에는 많은 차이가 있으며, 안드로이드는 자바 가상 머신(이하 JVM)이 아닌 달빅(Dalvik)이라는 별개의 가상 머신을 사용한다.

안드로이드 안에는 JVM이 없고, 따라서 자바 바이트코드도 안드로이드에서 실행되지 않는다. 안드로이드에서는 자바 클래스를 또다른 바이트코드로 컴파일한 것을 달빅이라는 독자적인 가상 머신에서 구동한다.

JVM과 달빅은 몇 가지 다른 점이 있다.

  • JVM은 스택 머신이며, 달빅은 레지스터 머신이다.
  • 달빅은 디스크 공간을 JVM에 비해 덜 사용하도록 설계되었다.
  • 달빅의 상수 풀은 32비트 인덱스만을 사용하도록 설계되었다.
  • JVM에서는 바이트코드가 8비트 스택 인스트럭션을 실행하며 이 때 지역 변수는 별개의 인스트럭션을 따라 피연산자 스택으로부터 또는 피연산자 스택으로 복사되어야 한다. 반면 달빅에서는 지역 변수에 직접 접근하는 독자적인 16비트 인스트럭션을 사용하며 지역 변수는 통상 4비트짜리 가상 레지스터 영역에 의해 채택된다.

달빅이 읽는 바이트코드도 JVM이 읽는 그것과 다르고, 달빅이 클래스를 읽는 방식도 JVM의 그것과 다르기 때문에 달빅에서는 JVM으로 패키징된 자바 라이브러리를 읽지 못하며 안드로이드 라이브러리를 읽는 데에도 별도의 로직이 필요하다. (특히 안드로이드 라이브러리를 읽을 수 있게 되기 전에 내부 .dex 파일의 내용이 응용 프로그램 내부의 격리된 공간에 복사되어야 하는 것이 있다)

Dalvik의 클래스 라이브러리

달빅은 자바 SE나 자바 ME의 클래스 라이브러리 프로필에 기대지 않으며, 이에 따라 자바 ME의 클래스, AWT, 스윙도 지원하지 않는다. 달빅이 사용하는 라이브러리는 아파치 하모니를 기반으로 한다.

java.lang 패키지

자바의 기본 출력 스트림인 System.out과 System.err은 안드로이드에서 기본적으로는 아무것도 출력하지 않는다(ADB를 통해 설정을 변경해 출력하게 할 수는 있다). 안드로이드에서는 기본적으로 Log 클래스를 통해 출력이 이루어지며 출력된 내용은 logcat 툴을 통해 확인할 수 있다.

그래픽스와 위젯

안드로이드는 AWT나 스윙 대신 View 기반의 여러 클래스들로 스윙과 비슷하게 구성한 독자적인 프레임워크를 사용하며, 응용 프로그램의 Context는 생성될 때 위젯에 제공되어야 한다.

외형

안드로이드의 위젯 라이브러리는 기본적으로 스윙의 교체 가능한 외형같은 것이 없고, 외형은 위젯 자체에 코딩되어 있어야 한다. 그러나 스타일과 테마 일부는 응용 프로그램별로 지정할 수 있다.

레이아웃 관리기

레이아웃 관리기가 어느 컨테이너 위젯에든 적용될 수 있는 자바와 달리 안드로이드는 컨테이너 안에 레이아웃이 인코딩된다.

Open JDK와 자바의 현재

2010년 자바 진영을 이끌던 Sun사가 오라클에 인수 합병되면서 자바의 미래에도 어둠의 그림자가 드리우기 시작했다. 오라클 스스로도 JDK 6 이후에 무척 어려운 기간이었다고 말하고 있다. 이후 자바 7과 그 이후로 넘어갈 때까지 상당히 오랜 시간이 걸렸다. JDK 코드 베이스를 가져와 OpenJDK를 구성하는 데 많은 시간과 노력이 투입됐다.

Sun(현재의 Oracle)사가 JDK 7을 개발하기 시작할 때 이전과 다른 점이 하나 있었는데, Sun이 JDK를 오픈소스화 하기 위해 2007년 OpenJDK를 만들었다는 것이다.

다음 주요 릴리스가 나올 때까지 너무 오랜 시간이 걸렸다는 측면에서 실망스러운 일이었지만, 결국 그것도 지금의 OpenJDK 커뮤니티가 형성되고 자바 7과 8이 나오게 된 과정의 일부였다.

Sun이 3rd-Party 라이브러리의 저작권자에게 오픈소스로 공개할 수 있도록 설득하고자 했으나 잘되지 않았고, 저작권자가 오픈소스화를 거부한 일부 컴포넌트를 제외한 나머지 JDK 소스코드 전부를 OpenJDK에 제공했고, OpenJDK는 이를 기반으로 이외의 컴포넌트들의 대안 코드를 마련하면서 JDK7 프로젝트를 시작했다.

Java 주요 릴리즈 히스토리

Version Date Issues
1.0 1996 Oak로 출시되었으며 1.0.2 버전부터 Java로 불리우기 시작
1.1 1997 AWT, Innner Class, JDBC, RMI, 윈도우즈 시스템의 JIT(Just In Time) 컴파일러, 유니코드 통합
1.2 1998 애플릿, Sun의 JVM에 처음으로 JIT이 탑재, Collections
1.3 2000 HotSpot JVM 추가, JNDI
1.4 2002 NIO, Logging API, IPv6 지원, XML 파서 통합, Java Web Start
1.5 2004 Generics, Autoboxing/Unboxing, Enumerations, 향상된 for 문, static imports
1.6 2006 Security
1.7 2011 Null-safe Method invocaton, Multi-Exception catch, Type Inference, String in Switch, Automatic Resource Management, NIO 2.0, G1 Garbage Collector
1.8 2014 Lambda Expression, Streams, Method Reference

JVM에서 작동하는 다양한 언어들의 출현

자바가 1.7로 업데이트가 늦을 이유 때문이였을까? JVM에서 동작하는 새로운 언어들이 출현하기 시작하였다.

최근에는 대량의 데이터와 클라우드 환경에서 동시성의 문제가 중요한 화두로 대두되었고 이러한 문제를 해결하기 위해서는 불변(Immutable)의 데이터형의 활용을 핵심으로 하는 접근이 대세로 떠오르게 되었다.

이러한 맥락에서 함수형 패러다임의 접근 방법이나 메시징 기반 아키텍쳐가 빠르게 입지를 넓혀 나가기 시작했고 스칼라와 같은 함수형 언어나 기술들이 그 대안으로 떠오르고 있다.

따라서 JVM 플랫폼 자체와 그 위에서 돌아가는 여러 라이브러리는 그대로 두고, 컴파일을 통해 클래스 파일을 생성하는 원본 언어만을 대체하는 접근이 널리 쓰이고 있으며, JVM 환경에서 작동하는 자바의 대안 언어들이 이와 같은 방식을 채택하고 있다.

JVM에서 동작하는 언어는 컴퓨터 프로그래밍 언어로 문자 그대로 자바 가상 머신 위에서 실행될 수 있도록 바이트코드를 생성하거나 자바 가상 머신 위에서 실행되는 인터프리터를 지원하는 언어를 말한다. 다양한 언어가 출현했는데 현재 대표적인 JVM 언어는 아래와 같다.

  • Clojure
  • Groovy
  • Kotlin
  • Scala

자바의 미래

JVM에서 작동하는 언어가 많아지는 것은 자바에게도 좋은 일이다. 한 가지 상기해야 할 점은 자바는 가장 광범위하게 사용되는 언어이며, 실제 사용되는 애플리케이션 수도 가장 많다는 사실이다. 따라서 그만큼 책임도 크다. 따라서 잘 작동하리란 보장이 없는 기능을 함부로 실험하는 것은 자바에겐 무책임한 일이다. 자바 입장에서는 시행착오를 감수하고 다양한 것들을 시도하는 방식은 지양하는 것이 바람직하다.

그보다 자바는 새로운 발전과 새로운 기술을 충분한 시간동안 검토해 매끄럽게 작동하고 이해하고 사용하기 쉬우며 확장 가능한 상태로 만든 다음 최대한 폭넓은 사용자에게 제공하는 방식을 추구한다. 자바 8의 람다가 바로 이런 예다.

자바는 앞으로 JVM의 다양한 언어를 개발하는 사람들 사이에서 대화도 활발히 이뤄지는 만큼 흥미롭게 지켜볼 부분이라고 생각한다.

References