특집기사:자바 정규 표현식 대안 라이브러리

위클립스
이동: 둘러보기, 찾기
Article.png 특집기사 정보
Jeeeyul.jpg
저자 이지율

이 문서는 정규 표현식 대안 라이브러리 및 이클립스 텍스트 에디터의 문서의 파티셔닝 시스템에 관해 얄팍한 지식을 제공한다.

목차

[편집] 개요

Regex-util.png

기존 텍스트 에디터를 유지 보수하는 일을 하면서 겪은 일이다.

이 에디터의 입력문서는 기본은 XHTML이지만, 내부적으로 스크립트 및 JSON이 포함될 수 있고, 이들의 편집 지원을 위해(자동 완성이나, 인덴테이션, 자동 편집 전략등등) 새로운 도큐먼트 파티셔닝이 필요해졌다.

이클립스 텍스트 에디터의 문서는 여러 파티션들로 구성되고, 각 파티션마다 편집 지원이 다르게 묶인다. 예를 들어 자바 주석 영역에서는 전혀 다른 컨텐트 어시스트가 제공된다. 또한 JSP 에디터들은 HTML영역과 Java 영역이 혼재 되어 있는데, 이러한 영역들은 각기 다른 파티션으로 나누어지게 되고, 이에 따라 개별적인 편집 지원이 모듈화 된다. 이렇게 문서를 파티션들로 나누는 작업을 파티셔닝이라고 하며, 보통 도큐먼트 프로바이더가 문서를 공급하는 시점에 파티셔너를 연결해서 보내주게 된다.

몇몇 문법적인 특성상 룰 기반 패스트 파티셔닝을 이용할 수 없는 상황이었기 때문에, 정규 표현식 기반 파티셔너를 작성하기로 했다.

애용하는 플러그인인 Regex Util을 이용해 몇몇 정규표현식 작업을 마치고 곧바로 구현에 들어갔다.

그러자, 괴현상이 발생했다. 간헐적으로 StackOverflowError가 발생하였고, 이 에러를 관측하려고 하면 사라지기도 하는 일이 발생했다. 이 것은 말로만 듣던 하이젠버그!!

[편집] 디버깅 삽질

처음 시도한 것은 어떤 경우에 그런 문제가 발생하는지 특정하는 것이었고, 사용한 전략은 StackOverflowError가 발생하면 즉시 JDT디버거가 브레이크 포인트를 걸리게 하는 것이었다. 대게 이클립스 사용자들은 라인 브레이크 포인트만을 주로 사용하는 데, 그 외에도 유용한 브레이크 포인트들[1]이 많다.

Exception-breakpoint.png

위 그림에서 처럼, 붉은 화살표가 가리키는 툴 아이템을 클릭하면, 익셉션 브레이크 포인트를 걸 수 있다.

자, 그러면 재현이다!


...


응? 그런데, 스택오버플로가 날 만큼 스택이 가득찬 상태에서는 디버그 포트로의 연결이 제대로 되질 않았다. 결국 타임 아웃. 오 맘마미아.

Life-is-hard.jpg

[편집] 서드 파티 정규 표현식 라이브러리

Java의 PatternMatcher의 소스를 뜯어본 결과, 백트래킹등의 작업이 일어날 때마다 재귀호출이 지속적으로 일어나므로, 이를 막을 방법이 전혀 없어 보였다.

내 정규표현식이 좀 덜 백트래킹이 일어나게 해 볼까 했지만, 별로 가능해 보이지도 않았고, 한 번 쓰고나면 절대로 다시는 고칠 수 없다[2]는 정규표현식 아닌가.

그런데 Regex Util 뷰에서는 같은 조건에서도 멀쩡하게 패턴 매칭이 잘 되고 있었다. 읭?

그렇다면 이유는 뻔하지. 이놈은 Java에 탑재된 기본 정규표현식 API를 사용하는게 아니라는 것!

정규 표현식 라이브러리는 어떤 놈들이 있을까.

정규표현식 라이브러리 성능 비교, 출처[1]
라이브러리 10,000회 이터레이션 속도 (Java 1.6.x) JDK 1.4.2 Perl5 문법 지원
http://jakarta.apache.org/regexp/ 14372ms 25590ms X
http://www.javaregex.com/ 17514ms 61702ms X
자바 기본 6556ms 12117ms X
IBM ICU 36ms X (1.5이상만 지원) X
http://jregex.sourceforge.net/ 882ms 820ms O
http://xerces.apache.org/ 11526ms 26755ms O

답은 뻔해 보였다, 밸런스가 잘 맞고, 변수명을 가진 그룹등과 같은 펄5의 고품질 정규표현식이 지원되는 http://jregex.sourceforge.net 로 결정했다. 이 와중에 IBM의 미친 퍼포먼스에 살짝 한 번 좌절해주고, 다음으로 가자.

[편집] 결론

http://jregex.sourceforge.net 를 적용하는 것은 매우 간단했다. 자바 기본 API와 거의 같다. 다른 점이 있다면 Pattern.compile(..)대신 new Pattern(...)을 사용하는 것 뿐이었다.

그리고 나는 매우 잘 작동하는 텍스트 에디터를 볼 수 있었다.

최근 eXERD의 스크립트 엔진을 만들 때도 느낀 것이었지만, JRE에 기본 내장된 라이브러리들이 썩 좋지 않다는 것이었다. 여기에는 정치/철학/이권등과 같은 여러 이유가 복합적으로 존재한다.

왜 애초에 대안 라이브러리들을 검토하지 않았나 반성했다.

끗.

[편집] 참조

  1. 유용한 브레이크 포인트들이클립스 도움말에서 좀 더 자세히 알아볼 수 있다.
  2. Write Once Never Read

이 기사에 대한 의견은 토론 페이지를 통해 나눌 수 있습니다.

개인 도구
이름공간
변수
행위
포탈
탐색
도움
도구모음