MDL에 뛰어든다

엔터프라이즈 자바 2009. 4. 16. 17:12 posted by 엔트웍스

.......

  1. Commented by Favicon of http://seal.tistory.com BlogIcon 물개 at 2009.04.17 09:52

    뭐예요, 내용을 기대했더니.. ㅋ

Loose coupling

엔터프라이즈 자바 2007. 12. 4. 22:03 posted by 엔트웍스
Loose coupling이란?

Proramming to Interface? 아니다.
SOA? 아니다.

내가 정의한다면,

딱 필요한 만큼의 의존성만큼 결합되는 것

이지 않을까 한다.

의존성은 본질적으로 강제로 제거하기 어려우며 제거할 가치도 없다. 다만 불필요한 결합이 있을 뿐이다. 제거할 수 있다 해도 보다 상위 수준에서 제거해야 한다.

중요한 것은 '딱 필요한 만큼의 의존성'을 파악하는 방법과, 딱 그만큼만 '결합'되게 만드는 기술을 아는 것이다.

인터페이스 많이 만든다고 loosely coupled 시스템은 아니다.

  1. Commented by Favicon of http://toby.epril.com BlogIcon 토비 at 2007.12.05 06:18

    "딱 필요한 만큼"이 무엇인지 알 수 있는 비결을 알려주세요..

클래스 리로딩 솔루션... 진짜?

엔터프라이즈 자바 2007. 10. 11. 13:00 posted by 엔트웍스

JavaRebel Brings Class Reloading to Java

$99이라.
설마 낚시는 아니겠지?
정말이라면 진짜 반역이군.

heap의 인스턴스와 리로딩된 클래스와의 미스매치가 풀 수 있는 문제였단 말인가??

  1. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.10.11 16:01

    소개하는 동영상 보니까 진짜 그러네...
    대규모에선 어떨지 모르겠지만 서도 말야..
    그런데 어쨌든 바로 리로딩되서 미스매치를 풀어주는건 좋은데, 컴포넌트간의 의존관계는 어쩔 수 없으니..
    해결되는건 별로 없는건가..
    어쨋든 소스코드 고쳤는데 왜 안되냐.. 이런 소린 줄겠군.. ㅋㅋ

2007 JCO 오픈소스 컨퍼런스

엔터프라이즈 자바 2007. 9. 21. 12:37 posted by 엔트웍스
2007 JCO 오픈소스 컨퍼런스



TAG JCO

A short Primer to Java Memory Pool Sizing and Garbage Collectors
TAG GC

RIA와 Memory-Managed Programming

엔터프라이즈 자바 2007. 8. 4. 16:48 posted by 엔트웍스
자바 프로그래머는 메모리 할당과 해제에 신경쓸 필요가 없다. 자바는 메모리를 VM이 관리해주는 Memory-Managed Programming 언어이기 때문이다. 그저 new 키워드로 객체를 생성하고 쓰다가 잊어버리면 그만이다. C에서처럼 delete를 잊어버려 메모리 누수가 발생하는 문제도 없다. delete 키워드 따위는 애초에 존재하지도 않으며, C처럼 메모리 주소를 알아 낼 수 있는 방법도 없다. 겉보기에는 메모리라는 개념은 자바에 애초에 존재하지도 않으며, 메모리라는 저수준의 개념을 가지고 더 이상 머리를 싸맬 필요가 없다.

그러나 자바는 메모리 개념을 감추기만 했을 뿐 없애지는 못했다. 그리고 우리에게 가비지 컬렉터라는 신종 부라퀴를 풀어 놓았다. 참조가 해제된 객체가 가지고 있는 메모리를 해제하기 위한 가비지 컬렉터는, J2EE 환경에서 GC로 인한 성능저하 문제를 안겨준다.

게다가 메모리 누수 가능성이 0이 되지는 않았다. GC가 아무리 완벽하게 구현되었더라도 메모리 누수 가능성은 낮아질 뿐 0은 아니다. 간단히 어떤 클래스의 static 변수에 HashMap을 만들어 두면, 거기다 객체를 넣어두는 순간 이 객체는 영생을 얻고 메모리는 누수된다. 간단한 예지만 복잡하게 만들면 끝도 없이 복잡하게 만들 수도 있다. 자바는 메모리 누수에 대해 신경을 안쓰게 만들어 놓고 나중에 뒷통수를 때리는 언어일 수 있다.

결국 자바에서 메모리 관련한 문제가 해결된 것은 아무것도 없다. 나아진 것이라면 문제점들이 좀 더 정리되고 좀 더 컴포넌트화 되었다는 것이 달라졌을 뿐.

프로젝트에서 RIA(Rich Internet Application)를 적용하다 보니 문제는 돌고 도는 것이라는 진리를 다시금 깨닫는다. RIA도 메모리 문제에서 자유로울 수 없다.

기존의 DHTML 기반의 UI를 가진 시스템은, 클라이언트는 어느 정도 메모리 문제에서 자유롭다. 사용자는 하나의 페이지에서 길어야 분 단위로 머무를 뿐이다. 페이지가 갱신되고 나면  클라이언트 메모리는 다시 리셋된다. 따라서 하드코어하게 AJAX라도 사용하지 않는 한, 자바스크립트로 인한 누수된 메모리는 사용자가 인식하기 전에 새로운 페이지에서 사라져 버린다. 신경쓸 이유가 없으니 기억하거나 배울 필요도 없었다.

이제 RIA가 등장했다. RIA를 지원하는 환경은 모두 Memory-Managed Programming 언어를 제공한다. 그것이 어떤 언어이든지. 애시당초 웹 개발 언어가 Memory-Managed가 아니라면 보안문제가 발생할 것이다. 웹으로 다운로드 받은 프로그램이 내 OS의 메모리의 포인터를 얻어가는 걸 허용할 사람이 있을까?

그런데 대부분의 RIA 애플리케이션은 브라우저 입장에서는 하나의 웹페이지일 뿐이다. Rich한 애플리케이션은 러닝타임 또한 길 것이다. 러닝 타임이 길 수록 메모리 누수는 문제를 일으킬 가능성이 높아진다.

웹기반 시스템의 클라이언트 메모리 누수 문제? 심각하게 고민할 필요가 있나?

이것이 심각한 이유는, 대부분의 RIA 프로그램 들은 그 특성상 자체적으로도 하나하나의 객체가 상대적으로 메모리를 많이 차지하기 때문에, 메모리 누수는 매우 치명적일 가능성이 높다. RIA 애플리케이션은 각종 아이콘이나 이미지를 하나의 애플리케이션 메모리에서 처리함을 기억하라.

게다가 대부분의 RIA 프로그래머는 커리어의 특성상 이러한 메모리 누수의 개념 자체가 희박하거나, 기존 웹페이지 방식의 개발에 익숙한 나머지 그만 잊어버렸다는 것이다. 따라서 메모리 누수를 일으키는 프로그램을 작성할 가능성이 매우 높다. 팝업 윈도우 하나 띄우는데 1메가의 메모리가 필요하고, 이 팝업 윈도우를 닫아도 메모리가 해제되지 않는다면 그것은 재앙이나 다름없다.

게다가 대부분의 RIA 플랫폼은 GC를 통해 메모리를 해제하게 된다. 그런데 각 RIA 플랫폼의 GC 알고리즘은 아직 성숙되지도 않았고, 제대로 된 프로파일링 도구도 제공되지 않기 때문에 GC가 수행되었는지 알기 조차 힘들다. 또 GC는 대부분 수동 제어가 불가능하다.

메모리 누수 문제는 치명적인데 메모리 관리의 근간이 허술하니, 결국 인력으로 돌파할 수 밖에 없다. 경험 많은 엔지니어가 프로젝트 초기에 메모리 문제에 관해 명시하고 해결방법을 모색하고 가이드라인을 제공하고 프레임워크화하지 않는다면, 아마 대부분의 프로젝트는 막판에, 최악의 경우에는 프로젝트 완료 후에 진정한 고생길이 열릴 것이다.

Flex? Silverlight? JavaFX?
DHTML 기반에서는 꿈도 꾸지 못하던 멋진 사용자 인터페이스. 마치 데스크탑 애플리케이션같은 User Experience를 제공하는 매력적인 웹기반 시스템.
그러나 세상에 공짜는 없는 법이다.
모든 문제는 해결되지 않고 다른 곳에서 나타날 뿐이다.
RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다.

  1. Commented by 얼음공주 at 2007.08.21 15:23

    블로그 구경잘 하였습니다. 블로그에 필요한 동영상, boom4u.net 도 구경 오세요~~

  2. Commented by 민재 at 2007.12.05 17:53

    Memory-Managed가 아니라면 보안문제가 발생
    RIA는 메모리 관리가 되므로 보안 문제가 발생하지 않는다는 말이죠?

    이 부분은 여전히 헷갈리는 부분입니다. 개념적으로 잘 안 서요..

    • Commented by Favicon of http://crosscutter.info BlogIcon entworks at 2007.12.06 18:27

      아니 갑자기 이 글이 왜 최신으로 갱신되었죠.. -_-
      Memory-managed 프로그래밍 환경이 사용자측 리소스 보안 문제를 예방하는 충분조건은 아니고, 중요한 필요조건 정도가 아닐까요? 파일이나 키보드같은 자원에 액세스하는 걸 프로그래밍 언어가 막는건 아니니까요.

  3. Commented by 민재 at 2007.12.05 17:53

    "RIA는 웹과 Rich Client의 빛을 함께 지녔지만, 중첩된 그림자는 더 진하다." 이 말 멋지군요.. 음.

같기도

엔터프라이즈 자바 2007. 8. 3. 12:22 posted by 엔트웍스
- 자바는 메모리 누수가 있는 것도 아니고 없는 것도 아니다.
- 자바는 C보다 빠른 것도 아니고 느린 것도 아니다.
- EJB는 비즈니스 로직에만 집중하게 하기도 하면서 기술적 이슈에 더 깊은 이해를 필요로 한다.
- RIA는 웹과 리치 클라이언트의 장점을 모두 가진다. 한편 웹과 리치 클라이언트의 단점도 모두 가진다.
- Memory-managed Programming은 메모리 할당과 해제에서 해방시켰지만 Garbage Collection이라는 숙제를 던졌다.
- 오픈 스탠다드는 모두의 허기는 채워주지만 각자의 입맛은 만족시키지 못한다.


.... 세상에 공짜는 없다.

  1. Commented by Favicon of http://uggi.tistory.com BlogIcon 어기 at 2007.08.09 14:30

    와우~~

아래는 현재 프로젝트에서 발생한 문제점을 해결하기 위해 검색하여 찾은 정보를 정리한 것이다.

[GC의 수행 조건]

1. 고정 크기 메모리 블록의 chunk 단위로 OS의 메모리를 할당/해제
2. chunk의 집합이 Flash의 Memory Pool(JVM의 Heap과 같은 개념)이 됨
3. 객체 생성시마다 Pool에서 메모리를 할당 받음
4. 할당시 Pool이 바닥나면 GC 수행
5. GC는 4번 이벤트 시점에만 수행됨(!)

[GC 수행 규칙]
1. Java와 동일하에 Reference Count로 GC 대상을  분류함
2. 한 번의 GC 수행이 모든 GC 대상을 collect 하는 것은 아님(!)
3. GC 후 chunk를 정리하여 사용율 0인 chunk는 OS로 반환함

[Memory Leak 문제]
1. GC 자체의 Memory Leak 버그는 입증된 바 없음
2. EventListener의 reference 규칙을 이해하지 못하면 leak 위험성 상존

[Memory Leak의 해결]
1. EventListener에 의한 leak 해결방법은 정확한 이해와 함께 weak reference를 적극/정확히 사용하는 것
2. Flex 자체 제공 컴포넌트 일부에서도 leak를 유발한다고 함.

[요약]
1. GC 자체는 버그가 없다고 볼 수 있으나 애매한 작동 방식은 각종 FUD의 원인이 됨.
2. Memory Leak를 일으킬 수 있는 케이스에 대해 반드시 숙지하고 개발해야 함

Limitations of the Java Virtual Machine

엔터프라이즈 자바 2007. 7. 27. 09:41 posted by 엔트웍스
역시 OOOO....
(OOOO는 무엇일까요? 힌트: 네 글자 이름의 프레임워크입니다.)

자바의 한계를 또 하나 깨닫게 했다.
(정확히 이야기자면, 현실에서도 발생할 수 있는 것임을 깨닫게 했다.)
자바 개발 시에는 메소드 크기가 64K가 넘지 않도록 주의해야 한다.
다음 링크에서 볼 수 있다.
Limitations of the Java Virtual Machine

JSP 개발시에 이 제약조건에 주의하라는 경고 - 하나의 JSP 페이지는 전체가 하나의 메소드 내 구현 코드로 변환되어 컴파일 된다 - 를 책에서는 본 적이 있으나,
말 그대로 책 속의 이야기였다. 64K가 넘는 메소드는 경험해 본 적이 없다.

그런데 OOOO은 이것이 책 속의 이야기가 아님을 알게 해줬다.

보다 심각한 사실은,
컴파일이 안되는 소스가 JSP가 아니라 제품의 코드생성기에 의해 생성된 자바 코드라는 것이다.

OOOO의 코드 생성기를 고치던가,
DTO 구조를 분해하던가 해야 한다.

이번 일로 새롭게 알게 된 한 가지 교훈이다.

컴파일된 자바 메소드의 바이트코드는 64K를 넘어가면 컴파일시 오류 발생. 따라서 혹시라도 소스 생성기를 만들 때는 메소드의 크기에도 신경쓰자(손으로 코딩할 때는 하고 싶어도 하기 힘들다).


개인적 감상.
- 역시 OOOO과는 친해지기 어렵다.

TAG 64k, OOOO, 제한
  1. Commented by Favicon of http://younghoe.info BlogIcon 영회 at 2007.07.30 12:28

    답을 알 듯... 혹시.. 그거?

  2. Commented by Favicon of http://www.ologist.co.kr BlogIcon ologist at 2007.08.08 00:05

    정말 놀라운 사실이네요. 그런 제약사항이 있었다니~
    근데, 코드생성이 넘 과도하네요..^^

  3. Commented by Favicon of http://wookay.egloos.com BlogIcon ㄴㅇㄱ at 2007.12.05 23:59

    후후. 메소드가 얼마나 크길래 ^^

  4. Commented by Favicon of http://daeheekim.tistory.com BlogIcon kazami at 2008.05.16 12:56

    저도 몇년전에 프로젝트하면서 옆의 팀원이 겪은 상황이었는데,
    기존 PL/SQL의 로직을 떼서 java에 전환시키는데 분기되는 경우의수가 많아서.. 쪼개고 쪼개서 나눈적이 있었습니다.

Flex 적용 프로젝트의 이슈

엔터프라이즈 자바 2007. 7. 24. 10:02 posted by 엔트웍스
[성능]

A. Application이 전체적으로 무거움
    -> Flex Runtime 개선 필요
    -> 결론은 UI 디자인 시 이미지와 효과 등을 배제하고 최대한 단순하게
   -> 방법론적 해결은... 초기에 디자인 방향을 몇가지 설정하고 이에 대한 BMT 실시. 각 방향에 따른 사용자 PC 사양 컨펌

B. Flex Builder가 무거움
    -> Java 기반의 개발환경의 근본적인 문제점
    -> 개발자 PC 사양을 높일 수 밖에(P4급 CPU & 2G Memory)

[한글문제]

A. 한글 입력시 반응이 다소 느림
   -> Flex Runtime의 개선이 없는 한 해결 불가

B. 한글 폰트에 따라 컴포넌트 내의 수직 align 문제 발생
   -> Flex Runtime의 개선이 없는 한 근본적 해결 불가
  -> 임시 해결책은 문제가 없는 폰트와 사이즈로 통일 시키는 것

[Flex Architecture]

A. 개발시 컴파일 오버헤드
    -> Flex의 근본 아키텍처임
    -> 로컬 개발/테스트 환경 및 서버 빌드/배포 도구/프로세스를 초반에 확립해야 함

B. Rich Internet Application
    -> Rich 하다는 것은 Thin Internet Application(ex. JSP)에 비해 Presentation & Application 코드량과 복잡도 증가를 의미함
    -> 아키텍처링시 Flex Application 설계를 기존에 비해 더 고민할 것
    -> Flex 전문가를 초기에 프로젝트에 참여시켜 프레임워크 개발 & 컴포넌트화에 노력

[기타]

A. 서버 주소가 하드코딩된 URL
    -> 개발서버/QA서버/Production서버 간 이관에 따른 형상관리가 어려워짐
    -> Flex 만의 문제는 아니지만 Flex 만 놓고 보자면...
   -> 초기에 Flex App내에 사용될 URL의 종류를 분류하고 각각에 대해 App 내에서 하드코딩을 피하는 메커니즘 및 정책 강구

B. Flex Application의 컴포넌트화
    -> SWF 용량과 응집도를 고려한 컴포넌트 식별 프로세스를 반드시 거쳐야 함


TAG flex, 이슈
  1. Commented by Favicon of http://thetree.tistory.com BlogIcon pisteuo at 2007.07.25 13:33

    직접 경험해 보지 않고도 상황을 그릴 수가 있게 잘 정리해 놓으신 것 같습니다.
    아주 유용한 정보 감사합니다. 행복하세요~ ^^

  2. Commented by Favicon of http://cbiscuit.info BlogIcon cbiscuit at 2007.07.26 16:36

    아래와 같은 형식으로 정리하면 더 좋은 글이 될 수 있을 것 같네요. ^^

    1 문제점
    - 제품측면
    - 사용측면
    - 타제품연계측면

    2 예상원인
    - 플렉스 아키텍처
    - 개발환경 및 프로세스

    3 해결방안
    - 기술지원 강화
    - 프로세스 개선
    - 미해결