1995년 Java라는 언어가 생겼고, Web의 부흥과 맞물려 초창기에는 Java Applet, 현재는 Java Platform EE(Enterprise Edition)로 IT의 한 축을 그었다. Applet은 잠깐 반짝 하다 말았지만, 특히 Java Platform EE의 성공은 경이적이어서, 기업 전산 환경의 필수 middleware인 Web Application Server(이하 WAS)는 당연히 Java Platform EE 명세서에 준하는 것으로 생각하고(예전엔 Netscape Application Server라는 C/C++ 기반의 WAS도 있었지만 지금은 모두 Java Platform EE 명세를 따르는 WAS만 있는 것 같다), 따라서 기업/조직 전산 환경에서 Java는 가히 예전의 COBOL의 위치를 차지한다 해도 과언이 아니다. Embedded System 쪽으로는 특히 휴대전화 쪽으로 Java Platform ME(Micro Edition)이 널리 퍼졌고, Desktop이 조금 빈약하지만 Sun Microsystems가 Swing 다듬기에 여념이 없고, 특히 Eclipse의 SWT/JFace, RCP의 출현으로 말미암아, Platform 독립적인 Desktop Application 개발에도 Java가 세를 늘리고 있다(겪어보면 알겠지만 compile도 필요 없이 내가 짠 application이 Windows에서도 돌고 Linux에서도 돈다는 것은 정말 대단히 매력적인 일이다).

 분명 Java는 문법이, 특히 C++에 비하면, 깔끔하다. Java 이전에 OOP를 한다고 하면 C++로 coding한다는 이야기였던 때가 있었는데, C도 그렇지만 이 C++도 code 자체가 대단히 난잡하다. 특히 MFC로 짠 Windows program code는 지금 봐도 그 너저분함에 질린다(그래서 개인적으로 C#의 등장을 환영한다. 최소한 Windows program도 깔끔하게 짤 수 있으니까). 그런데 이 Java는 C++에 비하면 상당히 우아한 code가 나올 수 있다. 그러다보니 요새는 'Java로 된 자료 구조', 'Java로 된 algorithm', 'Java로 된 OOP' 등, 학계에서도 교육용 목적으로 Java를 많이 가르치며 S/W 공학 같은 것을 논할 때 예제 code도 Java로 짠 것을 심심찮게 볼 수 있다.

 또한, Java는 open source 개발자들에게도 매력적이었는지 Apache 재단, Eclipse 재단 등을 위시한 수많은 곳에서 Java 관련 제품을 개발하고 정보를 교류하고 있으며 이러한 산출물들은 Java 개발을 편리하게 하고, 새내기 개발자들이 참고할만한 교재 역할을 하며, Sun Microsystems 같은 Java 명세에 칼자루를 쥐고 있는 자들이 명세를 재정할 때 idea를 주고, 아울러 독단에 빠지지 않고 실질적으로 개발자들이 원하는 바를 잘 반영하게 하는 일종의 압력으로도 작용하여, 궁극적으로 Java의 세 확산을 일조하는 선순환 구조를 만들어냈다.

 즉 현재 Java는 Thomas Kuhn이 '과학 혁명의 구조'라는 책에서 말한 바로 그 Paradigm이다.

 Java의 비대화

java.util.EnumMap이라는 class의 생성자이다. JDK 1.4 이전 code였으면 public EnumMap(EnumMap m)이라고 끝났을 code이다. 물론 Generics를 도입한 결과 Type 확인을 compile 시에 할 수 있게 되어 ClassCastException 꼴은 덜 보게 되어서 결과적으로 program 안정성 향상에 기여한 것은 사실이나 위 code를 보면 "먼 소린지~"다. Java 문법도 간결했던 문법이, 슬슬 사용자의 요구를 수용하다 보니 점점 난잡해지고 있는 한 예라 하겠다. API적인 측면은 더하다. 지금 Java Platform SE 6의 API는 JDK 1.2의 API에 비하면 훨씬 방대하다. 즉, 기술이 복잡해지고 있다. 그리고 이 복잡도를 사용자들이 수용하기 어려울 때, Java는 스스로의 무게에 비틀댈 것이다. 많은 기술들이 그랬었던 것처럼. Java도 entrophy의 증가라는 열역학 법칙에 자유롭지 못한 것은 아닐까.

sciprt 언어들의 도전

Java Platform이 Web 개발에는 거대하고 복잡하여 부적절하다는 말들이 여기저기서 나오고 있다. 이들 주장은 주로 PHP나 Python, Ruby와 같은 script 언어를 좋아하는 사람들에게서 많이 나오는데, 그동안 Java 진영은 그런 언어로 개발한 Web은 고가용성 등에 문제가 있어 mission-critical한 기업 업무 개발에는 부적절하다고 주장했다(재미있는 것은 이러한 주장은 이제는 한 물 간 것으로 취급하는 TP Monitor 진영, 더 한 물 간 것으로 여기는 Mainfram 진영이 Java를 폄하할 때 하는 주장이다). 확실히, script 언어들은 개발 생산성은 좋다. 그러나 Java 진영은 IBM, Sun Microsystems, BEA, Oracle 같은 IT 업계 거물이 버티고 돈은 받지만 동작을 보증함에 비해, 동적 type 언어들은 open source 진영에서 나온 것이다 보니, Do-it-yourself인 이런 open source 결과물을 자신의 업무 환경에 턱 적용했다가 문제 생기면 본인이 스스로 뒷감당을 해야 하므로, 혁신보다 보신이 중요한 (거대) 기업 조직 생리 상 이런 것들을 채용하기는 어렵다. 실제로 그러한 언어로 된 Web 개발은 기업 규모의 전산 환경에서는 underground 취급당했다. 그러나 RubyOnRails로 대표하는 쾌속 Web 개발이 개발자들의 이목을 끌고, Google이나 Wikipedia 같은, 무시무시한 traffic을 견디는 동적 type 언어들로 개발한 site들이 출현하다 보니, 과연 고가용성 때문에 거대함과 복잡함을 감내해야 하는지, 과연 그런 것들이 고가용성에 문제가 있는지에 대한 회의가 많이 늘었다. Java는 이러한 도전에 대한 응전으로 이번 Java Platform SE 6부터 JVM 상에서 script 언어를 돌릴 수 있는 길을 열어놓았다. 하지만 script 언어라는 것이 Java를 제치고 Paradigm의 영예를 순식간에 대체할 수 있는 가능성은 적지 않다.

 
Java 새 version의 비활성화

 요새 Microsoft는 Windows Vista를 열심히 팔고 있다. 그런데 이 Windows Vista 판매의 걸림돌은 Linux나 Solaris 같은 다른 운영체제가 아니라 바로 Windows XP, Windows 2000 같은 이전 version의 Windows이다. 그런데 이 현상이 Java에도 나타나고 있으니, Java Platform SE 6가 나오고 Java Platform EE 5가 나왔건만 아직도 현장에서는 JDK 1.4와 J2EE 1.4 기반의 WAS가 판을 치고 있다. 또한 WAS 제작사들도 Java Platform EE 5 인증 받는데 그닥 열의가 없다. TmaxSoft는 Java SE Platform EE 5 기반 WAS인 JEUS 6을 개발했지만, 현재 그 회사 site는 JEUS 5 위주로 소개하고 있다. BEA는 Java Platform EE 5 기반 WAS로 이제서야 WebLogic Server 10을 내놓았고, IBM 또한 J2EE 1.4 기반인 WebSphere Application Server 6.1에 머물러 있다. Open Source WAS의 대표 주자인 JBoss Application Server도 J2EE 1.4 명세에 일부 Java Platoform EE 5를 이루는 명세의 구현체 몇 개를 추가 탑재하는 식이다. 즉, 시장의 평가는 어떻게 보면 J2EE 1.4 기반 WAS로도 충분하다는 신호를 보내는 것이다. 또한 J2EE 1.4 명세는 JDK 1.4를 명시하므로 Java Platform SE 6은 고사하고 5도 각광을 덜 받는 것이다(이것은 위에서 언급한 문법 변화를 개발자들이 잘 수용하지 않기 때문이기도 하다).