안녕하세요 (전)프포자 
안드로이드의 출현
안드로이드(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의 다양한 언어를 개발하는 사람들 사이에서 대화도 활발히 이뤄지는 만큼 흥미롭게 지켜볼 부분이라고 생각한다.