가정 먼저 전할 소식은 급한대로 "윈도우즈 XP 마케팅 강화하는 썬"입니다. 먼저
썬의 XP용 자바 플러긴 사이트를 가시면 그 면면을 살펴볼 수 있습니다. "GET JAVA TECHNOLOGY"라는 다소 선동적인 문구와 함께하는 자바 2 기술의 XP 지원은 그러나, 아직도 일부 애플릿과의 호완성에서 문제가 있어 보입니다. 예를 들어
하이홈 쩜 컴(?)이 자랑하는 홈 빌더와 FTP는 인증된 자바 애플릿 기술을 사용하는데, 안타깝게도 썬 자바 플러긴의 경우 특정 클래스 로딩을 실패한 후 한없는 기다림을 요구합니다. (결국 실행도 안되지요.) 저는 이 문제를 하이홈측에 보고했으나 아직 이렇다할 해결책을 제시하지 못하고 있어 보입니다. 요행이도 제가 스타벅스를 비롯한 제 홈피 전체를 하이홈으로 옮기는 통에 이런 경험을 해보게 되었는데, 정말이지 일개 사용자지만 불끈(?) 나서서 고쳐보고 싶을 정도로 답답한 현실이었습니다.
하이 홈의 홈 빌더 2.0 링크 밑에는 옥의 티를 찾으라며 버그 리포트를 독려하는데, 독려만 하지말고 뭔가 적극적인 대처가 있었으면 좋겠습니다. 적어도 애써 글을 올린 사람에게 감사의 표시나 어떻게 하겠다는 정도 답신하는 것조차 못할 정도로 바쁘시다면 사용자가 이해해야겠죠. ^^
기록(Logging) API
J2SE 1.4-멀린에 추가된 신기능중의 하나인
기록(logging) API에 대해 알아보도록 하겠습니다.
멀린이 새로이 선사하는 선호설정(preferences), 신 I/O, 영상(image) I/O, 출력(print) 서비스등은 실제로 특정 작업을 가능하게 하는 시스템의 자바적 프레임워크입니다. 예를 들어 멀린의 로깅 시스템은 멀린의 API가 제공하는 클래스 프레임워크 형식으로 제공됩니다.
특히 로깅 API는 어떤 애플리케이션에도 로깅 기능을 손쉽게 추가할 수 있도록 고안되었습니다. 로깅 기능은 서버측에서 가장 필요한 기능중의 하나로 많은 사람들이 여기고 있지만, 클라이언트 애플리케이션에서도 쓰지 말라는 법은 없을 정도로 중요한 것입니다. 또한 기존의 로그가 단순히 파일 기반이었다면, 멀린의 로깅 시스템은 자바 특유의 다양한 출력 방향성을 바탕으로 로그 파일, 콘솔 화면, 네트웍 소켓, 메모리내 버퍼등을 활용할 수 있습니다. 아주 환상적이게도 로깅 처리기가 이메일을 보낸다거나, 핸드폰에 문자 메시지를 남긴다거나, 홈페이지를 자동 생성하여 올린다던가 하느 일도 가능하다는군요.
그러면 여기서 로깅 API의 주요 구성 성분(?)을 살펴보죠.
- Logger[기록기] - 기록할 메시지를 넘길 메쏘드를 듬뿍 담은 클래스
- LogRecord[기록] - 이것은 Logger와는 반대로 기록된 메시지를 나타내는 기록 객체. Logger가 만들어낼 것은 당연하고, 기록할 사건에 대한 전모가 들어있습니다.
- Handler[처리기] - 앞서 소개했듯이 여러 가지 방법으로 기록을 남기게 해주는 처리기
- Formatter[형식기] - 이름만 봐도 눈치챌 수 있듯이 Handler가 LogRecord를 작성하는데 다듬는 역할을 합니다.
- Filter[정제기] - 이건 아예 메시지를 기록할지 안할지를 기록기가 선택할 때, 메시지를 다듬을지 안다듬을지 형식기가 선택할 때의 결정에 관한 정책을 제시합니다.
이렇게 역할별로 객체를 분리해둠으로서 하나의 기록에 대해 여러 가지 로그 시스템을 구가할 수 있습니다. 이쯤에서 로깅 시스템의 흐름을 따라가보면,
기록 → 기록기에 들어감 → 기록기와 연동하는 정제기에 의해 걸러짐 → 통과안하면 기록 꽝! 통과하면 일단 기록 가능성 높아짐 → 이번에는 처리기와 연동한는 정제기를 통과 → 잘 걸러진 기록은 형식기로 마무리된 후 파일이나 화면으로 출력
따라서 하나의 로깅 시스템을 구축하려면 기록기, 처리기, 정제기가 필요하며, 그것들을 하나로 묶어 협업하도록 하면 됩니다. 유기적인 구조를 위해 기록기는 처리기의 집합으로 이루어지며, 각각의 처리기는 자신만의 정제기를 가질 수 있습니다. (기록기도 정제기를 가질 수 있습니다.) 기본적으로 기록기와 처리기는 내장된 경량(lightweight) 정제기를 가지고 있으며, 기록 수준(log level)이라는 독특한 개념을 구현하는 중량(heavy weight) 정제기도 장착 가능하죠. (경량-중량은 상대적인 용어입니다.)
너무 개론적인 얘기만 해서 지루할까봐 간단한 예제 하나 들어보죠.
import java.util.logging.*;
public class LogIas{
private static Logger logger = Logger.getLogger("global");
public static void main(String args[]){
logger.info("I"m fine.");
if (args.length == 0)
{
logger.warning("Not good...");
}
logger.fine("It"s all over");
}
}
|
(아무리 카피가 가능하다지만 되도록이면 직접 눈으로 보면서 손으로 쳐보시기 바랍니다.)
클래스명은 로그-이아스(소문자 엘 아닙니다. 대문자 아이입니다.)으로서, 무지 간단하게 화면에 어이없는 로그를 출력합니다.
아마 그냥 java LogIas하면(물론 그전에 J2SE 1.4로 컴파일한 후)
2001/11/17 0:09:32 LogIas main
INFO: I"m fine.
2001/11/17 0:09:32 LogIas main
WARNING: Not good...
|
요런 메시지가 나옵니다. 혹시나 해서 java LogIas good 이라고 하면
2001/11/17 0:09:32 LogIas main
INFO: I"m fine.
|
요렇게만 나옵니다. 그런데 소스 파일의 맨 마지막 줄 logger.fine("...")은 실행이 안된 걸까요? 그것이 바로 기록 수준과 관련이 되어 있으며 대략 말하면 java.util.logging.Level 클래스의 INFO이상 수준이 아니면 화면에(정확히는 System.err에) 출력하지 않습니다. (Level 클래스는 API문서에서 꼭 참조하세요!)
너무 간단한가요? 이번에는 조금 발전시켜 평소 우리가 즐겨 쓰는 파일 로그 체제로 전환해봅시다.
import java.util.logging.*;
public class LogIas2
{
public static void main(String args[]) throws Exception
{
LogManager logManager = LogManager.getLogManager();
Handler fh = new FileHandler("%t/ias.log");
logManager.removeAllGlobalHandlers();
logManager.addGlobalHandler(fh);
logManager.setLevel("com.iasandcb",Level.FINEST);
Logger logger = Logger.getLogger("com.iasandcb.test");
logger.info("I"m fine.");
if (args.length == 0)
{
logger.warning("Not good...");
}
logger.fine("It"s all over");
}
}
|
아까보다 복잡해보이는데, 아까는 단순리 기록자를 Logger클래스에서 스태틱하게(정적으로) 받아왔다면, 이번에는 LogManager에서 싱글턴으로 인스턴스를 받아와 파일로 기록을 출력할 처리기를 추가합니다. 그리고 com.iasandcb라는 이름으로 기록자를 얻으면 기록 수준을 FINEST로 하여 사실상 모든 수준의 기록을 실제 작성하도록 정제합니다. 그리고 기록자는 com.iasandcb.test라는 이름으로 얻어와서 아까처럼 똑같이 기록합니다.
그런데 흥미로운 것은 기록 파일의 위치와 내용입니다. %t는 플랫폼 의존적인 임시 디렉토리를 뜻하는데, 한번 하드 디스크에서 ias.log 파일을 찾아보니 저의 경우에는 윈도우즈 2000을 쓰는데 c:￦Documents and Settings￦ias￦Local Settings￦Temp(사용자명 ias인 경우)에 들어있고 내용은 열어보면 XML파일 형식으로 되어있습니다.
위와 같은 방식은 사실상 자바의 로깅 시스템 설정 전체를 총괄하는 기록 관리자 단일 객체에 변화를 가져오는 식이므로 상당히 넓은(gloabl) 사용 방식이고, 좁게 간단히 쓰려면 아래같이 해도 됩니다.
import java.util.logging.*;
public class LogIas3
{
public static void main(String args[]) throws Exception
{
Logger logger = Logger.getLogger("com.iasandcb.test");
FileHandler fh = new FileHandler("ias.log");
logger.addHandler(fh);
logger.setLevel(Level.ALL);
logger.info("I"m fine.");
if (args.length == 0)
{
logger.warning("Not good...");
}
logger.fine("It"s all over");
}
}
|
위 예제의 결과는 아까와는 사뭇 달라서 ias.log도 실행 디렉토리에 바로 생기고, 화면에도 같이 출력됩니다. 이 말은 즉 앞선 기록 관리자 기반의 기록 작성시에는 모든 전역 처리기(global handler)를 지워버리는 logManager.removeAllGlobalHandler를 실행했기때문에 System.err에 출력하는 기본 처리기가 무효화되었던 것입니다. 기록 관리자의 설정은 코드안에서만 할 수 있는 것이 아니라 J2SE SDK가 깔린 홈 디렉토리의 jre/lib에 있는 logging.properties를 통해서도 원천적으로 가능합니다. (logging.properties를 열어보면 많은 주석이 설정에 대해 친절히 알려줍니다.)
더 강력하고 자세한 내용은 제가 곧(출판사에서는 죽어도 올해안으로 내겠다는) 써버릴(?) "감동과 재미를 동시에 선사하는" 자바 입문서(featuring J2SE 1.4-Merlin) "백두대간 자바"에서 확인하세요. (이런 식으로 책 광고를 하는군... T_T)
멀린이 자신있게 내놓은 로깅 시스템은 J2SE가 얼마나 J2EE에 공을 들이고 있는가를 엿보게 해주는 흥미로운 기능입니다. 많은 서버측 애플리케이션이 다중 사용자로부터의 각종 모니터링 정보를 효율적으로 기록, 관리해야하는 상황은 주지의 사실입니다. 그러나 썬은 아직까지 이렇다할 표준적 솔루션을 제공하지 않아왔고, 아파치 재단을 비롯한 비영리 단체, 혹은 상업적 대안들이 발호했던 것도 익히 알려져있습니다. 이런 시점에서 썬의 로깅 시스템, 특히 J2SE의 기본 API로의 흡수 통합은 성능과 활용성이라는 두 마리 토끼를 다 잡겠다는 썬 기술력의 야심찬 일보라고 보여집니다.
참고로 로깅 API는 서버측에 더 많이 쓰일 것으로 본다면, 선호설정 API는 클라이언트측-그중에서도 멀린의 역점 사업 분야인 두터운 손님(thick client, 한자로는 후객(厚客))-을 위한 배려라고 할 수 있을 것입니다.
스윙(Swing)
이전 소식을 통해 소개했던 스윙 진기 명기 그
5회가 공개되었습니다. 방금 확인해보니 그 사이에
6회도 나왔군요. 점차 J2SE, 특히 스윙의 적용 범위가 넓어지고 있다는 느낌입니다. 한동안 찬밥신세였던 씩 클라이언트(thick client-애플릿과 대별되는 애플리케이션적 규모. ASP(Application Service Providing)과 JWS(Java Web Start)가 바로 씩 클라이언트의 이론과 플랫폼이죠.)도 J2SE 1.4-멀린의 혁신적인 윈도우즈상의 렌더린 향상으로 승부를 걸 만하게 된 듯합니다.
5회에서는 MacOS X에서의 JWS, 그리고 Java3D를 활용한 게임, Kunststoff라는 독특한 룩엔필(Look&Feel)을 입은 일본 문자 학습(?) 프로그램, 아주 많은 그림을 보기에 편리한 방법을 제시하고 있는 포토메사, UML 에디터인 포세이돈(JWS로는 무려 13메가를 다운받습니다.) 등이 실려있습니다.
6회에는 XML쪽이 강세네요. 꼭 한번 가보셔서 자바 GUI의 실제상을 맛보시기 바랍니다.
J2ME Wireless Toolkit 이 1.0.3의 베타를 끝내고 정식 릴리스되었습니다. 조금식 향상되고 있는 에뮬레이터 관련 설정과 테스트, 디버깅 지원등 CLDC-MIDP 기반 코어 개발 환경으로는 손색이 없어보입니다. 하지만 현실적으로는 한국의 경우는 그나마 SKT, LGT가 모두 CLDC-MIDP를 기반으로 하고 있어 괜찮지만 일본의 경우 도코모가 DOJA(도자)라는 MIDP와는 다른 프로파일을 쓰고 있어 J2ME WT의 위상이 그다지 높지만은 않습니다. 또한 게임과 같은 멀티미디어 컨텐츠의 경우 사운드나 그래픽 가속 구현이 각 이통사별로 별도 부가 프로파일 형식으로 지원되고 있어 개별적으로 구현해주어야하는 현실이죠. 아무튼 MIDP을 기준으로 우선 알맹이를 만드는 데이는 아주 유용한 도구입니다.
관련되어서
팜OS(PalmOS)용 MIDP 1.0도 나왔습니다. 팜상에서 J2ME 기반의 GUI 프로그래밍을 하고 싶으신 분들에게는 무척 반갑지 않을까 싶네요. 저도 이것때문에 팜을 사고픈 유혹이 들 정도...
J2EE의 대표적인 벤치마킹 겸 스터디(?) 재료인
자바 팻 스토어(Java Pet Store)가 1.3으로 거듭났습니다. 특히 이번 버전은 J2EE 1.3이 간판으로 내세우고 있는 JMS(Java Messaging Service)를 EJB와 결합했으며(일명 MDB-Message Driven Bean), 역시나 최근 썬의 신전략의 일완인 두꺼운 클라이언트(thick client) 시스템인 JWS를 통한 JFC/Swing 기술 적용, CMP(Container Managed Persistence) 기반의 EJB를 통해 DB 특성을 타는 상황을 배제했다고 합니다. (실제로 얼마나 자원 독립적인지는 모르겠지만요.)
여담으로 이 JPS가 최근 MS의 집중 공격을 받으면서 썬을 발끈하게 만들었다고 합니다. JPS는 단순히 J2EE의 테스트용일 뿐만 아니라 J2EE상에서 사이트 디자인에 대한 어떤 모범을 제시하고 있다고 평가받는 바, 사실 성능을 위주로 꾸며졌다고 보기는 어렵습니다. (게다가 CMP까지 구현하고 있으니...) 그런데 이것을 MS가 닷 넷으로 적절히(?) 포팅했더니 엄청나게 빠르고 좋더라는 식의 얘기는 누가 들어도 "눈가리고 아웅"식이지요.
그리고도 근본적으로 자바의 바이트코드 기반의 J2EE 애플리케이션과 와 윈도우즈의 네이티브 코드 기반의 닷 넷 애플리케이션의 속도 비교는 의미가 없습니다. 이미 자바는 인터프리터를 한번 거치면서 피할 수 없는 우회를 거치기 때문이죠. 자바의 강점은 "윈도우즈에서 빨리 돌아간다"가 아니라, "플랫폼에 상관없이 돌아간다"에 있습니다. 윈도우즈에서 죽으라 빨리 돌아가길 바란다면 자바는 절대 NO입니다. 어떤 식으로도 자바 클래스는 윈도우즈 네이티브 프로그램보다 빠를 수 없지요. (악의 없이 정상적으로 둘 다 짰을 경우지만. 이 또한 객관적, 절대적 비교는 사실상 불가능합니다.)
기본 개념이 다른 것을 자꾸 단일한 잣대로 재려고 하면 그것이 바로 정치가 됩니다. 기술은 과학입니다. 합리성을 바탕으로 선택하고 선택받아야 고객과 기업 모두 올바른 사업으로 나아갈 수 있을 것입니다. 남을 헐뜯기보다는 자신이 남과 무엇이 다르며, 어떻게 앞으로 해나가야 할지를 설득해야하는 것인 아닌지, 공정한 시장 경쟁은 누가 만들어주는 것이 아니라 함께 이루어나가는 것이라고 생각합니다.
약속했던 기사외에 새로운 소식들이 또 있어 전합니다.
최근 썬은 J2ME와 J2EE를 잇는 연계 시스템에 대한 홍보를 활발히 하고 있습니다. 며칠전 소개된 "
무선 프로그램을 위한 자바 청사진(The Java Blueprint for Wireless Program)" 기사에서는 자바 스마트 티켓(Java Smart Ticket) 1.0을 소개하며 실전적인 예와 함께 설계 방안에 대한 비젼을 제시하고 있습니다.
윈도우즈XP에서는 깔리지 않았던
포르테 포 자바 J2SE 1.4 코번들이 베타 3로 갱신되었습니다. XP를 쓰시는 분들에게는 무척 기쁜(?) 일이겠군요.
자바3D 1.3이 베타1으로
스펙과
구현이 함께 나왔습니다. 점차 웹을 중심으로 저변을 확대하고 있는 자바3D는 자바 2 클라이언트 기술의 확보를 전제로 하고 있어 아직까지는 폭발적인 장세를 마련하고 있지는 않지만, 점차 필요성과 성능의 쌍곡선이 상승중에 있어보입니다. 1.2에서 지적되었던 많은 문제와 개발자-사용자들이 바라는 부분들에 대한 반응이 어떤식으로 녹아들어있는지 관심있는 분들은 문서를 보시고 실제 테스트해보시기 바랍니다.
자바 XML 팩이 가을01 버전이라는 분위기있는 이름으로 등장했습니다. J2SE 1.4에는 기본으로 포함되어 있지만, 그 이전 버전의 경우에는 자바의 XML기능에 대한 다양한 구현체를 각각 받아서 설치하는 번거러움이 남아있었는데, 이번 썬의 패키징으로 한큐에 자바와 XML의 환상적 궁합을 구경할 수 있게 되었습니다. 포함되어 있는 기술은
- JAXM(Java API for XML Messaging)
- JAXP(Java API for XML Processing)
- JAXB(Java Architecture for XML Binding)
- JAXR(Java API fro XML Registries)
- JAX-RPC(Java API for XML-based RPC)
입니다. 가장 유명한 것이 바로 XML처리의 기본이 되는 JAXP이고, 나머지는 최근 논의가 시작된 XML응용분야입니다. 기회가 되면 자세히 소개하죠.
최근 웹 서비스라는 미묘한(?) 개념이 떠오르면서 업계의 동향이 부산합니다. 처음에는 홈 페이지였다가, 그 다음에는 CGI, 그리고 ASP, PHP, JSP, 나가서 웹 애플리케이션, 이제는 그것도 모자라서 웹 서비스까지, XML과 함께 시장 부풀리기에 여념이 없는 분위기를 읽노라면 정적 만드는 사람과 쓰는 사람의 자리는 어디에 있는지 갑갑합니다. 최근 자바 개발자 저널(Java Developers Journal)에 실린 충격적으로 당연한 기사 "미국의 대다수 J2EE 관련 종사자들, "EJB는 거의 쓰지 않는다""는 말은, 정치(politics)가 얼마나 현실로부터 동떨어져있는가를 극명히 보여주는 한 예에 지나지 않을 것입니다. 정말 "우리"에게 필요한 것이 무엇인지, 다시 생각해보지 않을 수 없었습니다.
