내가 하는일/[JAVA] Java Language

프롤로그 필자는 요즘 java web application server를 만들고 있다. 그렇다 톰켓 같은거... 베타 버전을 배포해서 몇 몇 사용자로 부터 요구사항이 들어왔다. jps 명령으로 확인해봐도 되지만 JRE 만 깔려 있어 jps를 쓸수 없는 경우, 실행된지 모르고 또 실행한 경우가 있다는거다. 서버 프로세스의 실행을 감지하여 만약 같은 서버가 동작 중이면 실행한 서비스를 중단 시킬수 있냐는 것이다. 이번 글은 해당 요구사항을 해결하기 위한 필수 요소인 현재 시스템내에 실행 중인 VM 리스트를 구하는 방법에 대해 다루려 한다. 본론 참조 필자가 프로그램 코드에서 사용한 라이브러리는 JDK를 통해 배포되는 라이브러리로 알고 있다. 그래서 JRE만 설치되었거나 classpath에 문제가 있는경우 프..

프롤로그 이번 글은 다국어 리소스가 포함되어 있는 프로젝트에서 다국어 문자열을 대상으로 하는 테스트가 필요한 경우에 대한 이야기다. 이런 상황에서 단정문을 작성하는 개발자는 혼란을 경험하게 된다. @Test void testGetMessage() { assertEquals("이 클래스 [{0}]는 생성할 수 없습니다." , Global.getMessage(Global.CANNOT_BE_CREATED, "CTest")); } 위와 같은 테스트가 내 한글 윈도우10에서는 잘 돌아 갔었는데 CI 서버로 올라가 빌드를 하면 위 테스트의 단정 메서드는 fail을 뱉어낼 것이다. 우리 빌드 서버 역할을 하는 github는 영문 OS를 제공하기 때문이다. 필자가 격은 이 상황을 해결해 나간 과정을 정리하려 한다. 참..

프롤로그 요즘 IDE 또는 그 확장 솔루션들 예를들어 SonarLint 등이 아주 아주 성능이 좋아져서 중복된 코드나 복잡도가 높은 코드를 발견하면 잔소리를 늘어 놓는다. 사람이 하는 잔소리라면 한번 듣고 넘어가겠지만 계속 노란줄로 너 이거 “계속 안고칠꺼야?” 하고 경고를 한다. 테스트를 작성하다 보면 흐름은 거의 비슷하고 데이터 만 바뀌고 여기에 따라서 단정문도 살짝 바뀌는 수준의 테스트 메서드를 여러개 작성하게 된다. 이 경우 요즘 정적 분석기는 이런 중복도 잡아 준다. 뭐 정적 분석기가 잔소리를 하던 말던 제품 코드 뿐만 아니라 테스트 코드도 중복되어 좋을 것이 없다. 오늘은 이 문제를 해결하기 위한 방법을 하나 소개한다. Parameterized test 궂이 우리 말로 번역하자면 인자화 테스트..

프롤로그 현재 필자의 개발 프로젝트에서 사용하고 있는 빌드 시스템이 그런것인지 원래 JUnit이 그런것인지 모르겠으나 테스트 메서드가 여러개 존재하는 경우에 테스트 에이전트가 이를 동시에 실행하는 현상이 발생 했다. 예를 들어 동일한 TCP 포트를 사용하는 테스트 메서드가 존재하는 경우 이미 열려있는 포트로 인해 다음과 같은 예외가 발생한다. java.net.BindException: Address already in use: bind 물론 테스트 메서드마다 각자 다른 포트를 사용하게끔 하여 문제를 원천적으로 막으면 된다. 그러나 현실을 그렇지 못하다. 보통 이런 포트들은 서버 리스닝 포트고 테스트 및 단정을 하기위해서 클라이언트 모듈로 접속을 해봐야 하는데 각기 다른 포트로 클라이언트-서버 짝을 맞추어..

프롤로그 테스트를 작성하고 관리하던 중 특정 PC에서만 동작하는 테스트가 발생 했다. 원칙적으로는 모든 환경에서 테스트가 가능해야 하지만 진짜 그렇게 하려면 엄청난 노력을 해야 한다. 예를 들어 JNDI로 DB pool을 테스트 하기 위해 리얼 DB를 접속해서 쿼리를 해보는거 까지 진행되는 테스트 시나리오의 테스트 코드가 있다고 가정 했을때 이 테스트를 내 개발환경이 아닌 다른 머신에서도 동작하게 하기 위해서는 DBMS가 모두 접근 할 수 있는 위치에 있거나 테스트 수행전에 관련 설치를 해야 하는데 현실적으로 쉽지 않다. 특히나 현재 우리팀이 사용하고 있는 GitHub Actions를 통한 빌드를 하는 경우 더더욱 힘든 일이다. 본론 트레이드 오프(현실과의 타협) 이런 테스트 코드를 남겨둔체 소스를 서버..

프롤로그 지난 글에서 JAVA의 Throwable 그리고 Exception 클래스들의 계층 관계를 살펴보고 Unchecked, Checked 가 어떻게 구별되는지 왜 구별을 해야 하는지 생각해보는 기회를 갖었다. 이번 글에서는 이렇게 발생한 예외를 어떻게 다루어야 할지를 정리해보도록 하겠다. 일전에 C#의 예외처리에 대한 글을 쓸 때도 언급을 했는데 필자는 예외처리를 위해 try... catch를 남발하는 것을 매우 경계한다. 이는 가독성을 떨어뜨리고 전체적인 로직의 흐름에 방해 요소로 작용하여 유지 보수성을 떨어뜨려 결국 프로그램 품질에 까지 영향을 주는 요소로 작용한다. 프로그램 매니저 역할을 하던 시절에는 단위 모듈 개발자들에게 "그 어디에서도 try... catch를 쓰지 마세요."라고 하고 메인..

프롤로그 필자가 프로그래밍을 하면서 가장 신경 쓰는 부분이 예외처리다. C# 관련 글에도 예외 처리를 쓴 적이 있는데 완수를 못해서 늘 마음에 걸린다. 지금은 어찌하다 보니 현 개발 프로젝트가 JAVA가 되는 바람에 상당기간 동안 JAVA를 주력 언어로 써야 한다. 그래서 C#은 나중으로 미루고 JAVA의 예외 처리를 먼저 정리해보려 한다. 이번 글에서는 JAVA의 예외 처리 Class들에 대해서 고민해보는 시간을 먼저 갖으려 한다. Throwable, Exception, Error 위 그림은 JAVA의 예외처리 Class들의 상속체계이다. 가장 super 위치에 Throwable 이 자리 잡고 (있다. 그렇다 모든 예외 처리 Class의 super base이다. 모든 예외나 에러가 이 Class로부터 ..

프롤로그 이전 글에서 교착상태가 무엇인지 이를 재현해보고 교착상태의 thread를 검출해봤다. 이번글은 명시적인 Lock을 이용하여 교착상태에 빠진 thread를 탈출시키는 방법을 제시 해보려 한다. 명시적 Lock의 사용 JAVA의 명시적인 Lock은 표준 JDK 에서 총 3가지로 제공된다. ReentrantLock, ReentrantReadWirteLock, 그리고 일전에 다루었던 StampedLock이다. 명시적인 Lock은 Java의 Object에 숨어있는 암묵적인 Lock보다 그 야말로 명확하다. 블록이 아닌 lock / unlock의 명시적인 호출로 Lock을 건다. 그렇기에 위험하기도 하다. private ReentrantLock lock = new ReentrantLock(); // 중략 ..

프롤로그 필자는 전산학을 공부했다. 요즘은 컴퓨터 공학이라고 하는데 틀린말이다. 우린 컴퓨터를 만드는 법을 배우지 않았다. 컴퓨터 사이언스가 맞다. 필자의 사견이니 학과명 변경을 주도하시고 찬성하신 "교수님들 노여워 마세요!" 왜 전공 운운 했냐면 교착상태/Dead Lock 학교다닐때 다 배운거라는 것이다. 그런데 오랜 세월 요즘 말로 하면 프로트엔드 그것도 웹이 아닌 VC++,C#으로 Native 프로그램을 주로 해오다 보니 Thread를 만들더라도 그저 UI에 Lock이 안걸리게 하는 수준 이였다. 그런데 요즘 서버에서 동작하는 서비스 프로그램을 작성하다 보니 불량 Thread를 검출해야 하는 미션이 생겼다. 그러다 보니 소위 DeadLock이 되는 상황을 만들어 놓고 Test case를 돌리려 하는..

JAVA concurrent의 번외편으로 인터럽트를 검사하는 interrupted, isInterrupt 두 함수에 대해서 간략히 다루고자 한다. 살짝 불만부터 늘어 놓자. 도대체 왜 헷갈리게 이름이 비슷한 함수를 정적 함수와 인스턴스 함수 두 개로 분리해서 제공하는지? 이렇게 불만을 늘어 놓은 계기를 마련해준 두 함수의 차이점에 대해 알아보자. thread control 편에서 interrupt()와 InterruptedException 그리고 isInterrupt() 함수에 대해서 다루었다. 아차 그런데 빼 놓은 것이 생각이 났다 Thread Class에 정적으로 구현되어 있는 interrupted() 함수이다. 현재 thread의 interrupt상태를 검사하는 함수라는 측면에서는 같은 작용을 하는..

프롤로그 JAVA7 이전 기준으로 동시성 제어(스레드 안정성)를 위해 Lock을 설정하는 방법은 소위 Monitor Lock이라고 하는 synchronized 블럭을 사용하는 방법과 재 진입성이 보장되는 명시적인 Lock인 ReentrantLock과 Reentrant-ReadWriteLock을 이용하여 Lock을 구현 하였다. 필자가 ReentrantReadWriteLock을 처음 봤을때 아 이쯤이면 뭐 됐지 Lock을 안걸고 Lock Free로 구현하면 되지 이 이상 뭐가 필요할까 했는데 JAVA8 부터 지원한는 StampedLock이 이라는 것이 아닌가? "그래 새로운것을 계속 무시하면 난 아직도 dos에서 GW-BASIC으로 개발하고 있을꺼야! 이제 이 놈이 뭔지 들춰봐야 할 때가 되었어...." ..

프롤로그 가시성과 원자성을 이해 해야 문제없는 Thead 프로그램을 작성할 가능성이 높다. Thread 프로그램을 한다는 것은 나 혼자 목공소를 운영하다가 조수라도 한명 더 들어와 그의 작업까지 내가 정의 해야하고 서로 업무에 방해가 되지 않도록 동선을 고려하여 업무를 분장해야 하는 상황과 비유 할 수 있다. 그러기 위해서 적절한 시기와 방법으로 Thread는 생성되어야 하고 쉬어야(WAIT) 하며 때로는 멈춰야(BLOCK) 한다. 그리고 (제일 중요)완벽하게 Task를 완수 해야 한다. 필자는 이런 일련의 Thread 운영을 Thread Control이라 부르기로 했다. 그리고 이번 편에서는 소위 Thread Pool을 이용한 Thread Control 이 아닌 전통적인 방법으로 Thread를 생성하고..