Jakarta Project 에피소드Ⅰ
ORO의 보이지 않는 위험
조금 먼 옛날 Jakarta Project 저편에…
1996년 1월 23일 JDK 1.0이 세상에 처음 나온 이후 예상과 달리 많은 사람들로부터 관심을 받기 시작한다. 인기가 많아 질수록 언어 스펙 역시 요구가 많아지게 되는데, 그 중에 하나가 불편한 text-processing이었다.
때마침 1999년 Java Language 창시자인 James Gosling과 Open source 수호자인 Brian Behlendorf가 만나서 Jakarta Project를 설립 하고, Jakarta Project에 힘입은 Savarese는 2000년 7월에 Jakarta ORO project를 발족하여 Java Language에서 Regular Expression(정규 표현식)을 사용할 수 있게 하는데…
Jakarta ORO란?
JAVA는 J2SE 1.4 (February 6, 2002)때부터 Regular Expression(정규 표현식)을 지원하기 시작했다. 그러므로 초창기 JAVA는 text-processing이 타 언어에 비해 사용이 불편했다. 2000년 7월 23일 ORO(Original Reusable Objects) company가 JAVA에서 Regular Expression을 사용할 수 있도록 하기 위해 Set of text-processing Java classes를 Jakarta project에 기증하였다. 그 project가 바로 ORO project이다.
Jakarta ORO가 가진 잠재적 문제점
ORO project는 2003년 12월 30일 마지막 release이후, 많은 개발자로부터 J2SE 1.4에 포함된 JAVA CORE regular expression package(java.util.regex)에 비해서 현저히 떨어지는 성능과 높은 메모리 사용률에 대한 개선 요구사항들이 쇄도하게 된다. 이에 대해 original code contributor인 Daniel Savarese는 J2SE 1.4 이후 추가된 java.lang.CharSequence를 사용하면 위 언급한 성능/메모리에 대한 요구사항을 만족시킬 수는 있지만, backward compatibility(J2SE 1.4 이전 하위 호환성) 문제 때문에 요구사항을 들어줄 수 없었다고 한다.
그러므로 org.apache.oro package는 Perl5/AWK-like compatible regular expression을 사용할 수 있다는 장점이 있으나, java core regular expression package에 비해 현저히 떨어지는 성능과 높은 메모리 사용률이라는 단점 때문에 이를 감수하면서 사용할 경우, 언제 running service에 장애가 발생할 지 모른다.
더 큰 문제는 J2SE 1.4 이전에 개발 시작한 open source가 ORO package를 많이 사용하고 있으며, 특히 Jakarta subproject 상당수가 ORO package를 사용하고 있는 실정이란 점이다.
대응 방법
ORO package에 dependent한 대표적 open source인 spring framework, Jakarta ant 그리고 json-lib가 어떻게 ORO package를 사용하고 있는지 살펴봤다.
Json-lib와 spring framework는 JAVA version 1.4를 기준으로 ORO에 binding할지 Java core regular expression에 binding할지를 결정한다. 그러므로 version 1.4 이후의 JAVA를 사용하면 ORO에 binding되지 않기 때문에 ORO의 잠재적 문제로부터 안전하다.
한편 Jakarta ant는 default로 Java core regular expression에 binding되기 때문에 애초부터ORO의 잠재적 문제로부터 벗어날 수 있다. (jakarta ant는 property설정으로 jakarta ORO, Jakarta Regexp, Java core regular expression중 하나를 선택하여 사용하는 구조임)
위 3가지 open source 조사결과로 미루어 볼 때, ORO는 backward compatibility를 제공하는데 주로 사용되며 version 1.4 이후의 JAVA를 사용할 경우에는 ORO에 binding되지 않을 것이라 추측한다. 왜냐하면 2002년 JAVA version 1.4가 release된 이후 open source는 많은 사람들로부터 오랜 기간 동안 사용되면서 충분히 검증 받은 code라고 생각하기 때문이다. 하지만 직접 눈으로 확인하는 것이 가장 확실한 방법이다.
정리하면,
- The latest stable version of JAVA(가장 최신의 안정버전)를 사용한다.
- 규모가 작은 open source일 경우 직접 눈으로 확인한다.
대응 방법 예시 (직접 눈으로 source code 검증)
- json-lib (version 2.2.2)
- source code > net.sf.json.regexp.RegexpUtils.java
package net.sf.json.regexp; public class RegexpUtils { … (중간 생략) … /** * Returns a RegexpMatcher that works in a specific environment. * When in a JVM 1.3.1 it will return a Perl5RegexpMatcher, if the JVM is * younger (1.4+) it will return a JdkRegexpMatcher. */ public static RegexpMatcher getMatcher( String pattern ) { if( isJDK13() ){ return new Perl5RegexpMatcher( pattern ); }else{ return new JdkRegexpMatcher( pattern ); } } … (중간 생략) … }- Inheritance diagram
- spring framework (version 2.0.6)
- source code > org.springframework.aop.support.RegexpMethodPointcutAdvisor.java
package org.springframework.aop.support; … (중간 생략) … public class RegexpMethodPointcutAdvisor extends AbstractGenericPointcutAdvisor { … (중간 생략) … /** * Create the actual pointcut: By default, a {@link Perl5RegexpMethodPointcut} * will be created if Perl5 syntax is enforced or when running on JDK 1.3. * Else, a {@link JdkRegexpMethodPointcut} (JDK 1.4+) will be used. * @return the Pointcut instance (never <code>null</code>) * @see #setPerl5 * @see Perl5RegexpMethodPointcut * @see JdkRegexpMethodPointcut */ protected AbstractRegexpMethodPointcut createPointcut() { if (this.perl5 || JdkVersion.getMajorJavaVersion() < JdkVersion.JAVA_14) { // needs Jakarta ORO on the classpath return Perl5RegexpPointcutFactory.createPerl5RegexpPointcut(); } else { // needs to run on JDK >= 1.4 return new JdkRegexpMethodPointcut(); } } … (중간 생략) … }- Inheritance diagram
- Jakarta Ant (version 1.8)
- source code > org.apache.tools.ant.util.regexp.RegexpFactory.java
package org.apache.tools.ant.util.regexp; … (중간 생략) … public class RegexpFactory extends RegexpMatcherFactory { … (중간 생략) … /** * Create a new regular expression matcher instance. * Available implementations: * * org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp (default) * Based on the JDK's built-in regular expression package * * org.apache.tools.ant.util.regexp.JakartaOroRegexp * Based on the jakarta-oro package * * org.apache.tools.ant.util.regexp.JakartaRegexpRegexp * Based on the jakarta-regexp package * * @param p Project whose ant.regexp.regexpimpl property will be used. * @return the matcher instance * @throws BuildException on error */ public Regexp newRegexp(Project p) throws BuildException { String systemDefault = null; if (p == null) { systemDefault = System.getProperty(MagicNames.REGEXP_IMPL); } else { systemDefault = p.getProperty(MagicNames.REGEXP_IMPL); } if (systemDefault != null) { return createRegexpInstance(systemDefault); // XXX should we silently catch possible exceptions and try to // load a different implementation? } return new Jdk14RegexpRegexp();// default } … (중간 생략) … }- Inheritance diagram
