장비 업그레이드의 가장 큰 이슈가 JDK 설치 가능 여부였다.
세계 최초 국내 선 출시라 검증된 부분이 없어서 혹시 될까 싶은 맘에 마련했는데 결과는 좋았다.
머 어찌보면 CPU 차이로 가능성을 고려한거니 정상 작동하는게 당연한 것일지도 모르겠다.
SUN JDK 최신 버젼을 설치해 봤다.
0. 설치를 위해 작업 디렉토리를 만든다. 다음은 예이다.
0.1. mkdir /volume1/dev ; 디렉토리 생성
0.2. cd /volume1/dev ; 디렉토리 이동
1. JDK 다운로드
1.1. 직접 링크; NAS에 telent/SSH로 접속 후, 아래 명령을 수행한다.
wget http://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/VerifyItem-Start/jdk-6u18-linux-i586.bin?BundledLineItemUUID=JeBIBe.ppagAAAEmJehBgayD&OrderID=CR1IBe.pYLwAAAEmGuhBgayD&ProductID=6XdIBe.pudAAAAElYStRSbJV&FileName=/jdk-6u18-linux-i586.bin
* 다운로드 후 다운로드한 파일명이 URL전체로 비정상적으로 길 경우, 파일명을 jdk-6u18-linux-i586.bin으로 수정한다.
2. 설치
2.1. 설치 파일을 실행하는 위치가 파일 설치 경로가 되니 고려해서 설치하도록 한다.
2.2. 다운로드한 jdk-6u18-linux-i586.bin 파일을 실행한다.
./jdk-6u18-linux-i586.bin
2.3. 진행시 질문에 yes....
3. 환경 구축
3.1. link 걸기
3.1.1. 설치된 디렉토리 접근을 용이하게 하기 위해 link를 설정한다.
cd /opt
ln -s /volume1/dev/jdk1.6.0_18/ java
3.2. java path 설정
3.2.1. 부팅 때마다 자동으로 JDK 경로 인식시키기 위해 시스템 환경변수로 등록한다.
3.2.1.1. /etc/profile 파일을 편집, 저장한다.
vi /etc/profile
맨 아랫줄에 다음을 추가한다.
export JAVA_HOME=/opt/java
3.2.2. 리부팅 또는 . /etc/profile 실행
3.3. 테스트
3.3.1. /opt/java/bin/java -version 실행.
> 이제 tomcat을 올려봐야겠다.
*** JDK 다운로드 경로가 바뀌었다.
오라클 영향인지, 버젼 릴리즈 때마다 바뀌는 탓인지 모르겠다.
http://java.sun.com/javase/downloads/index.jsp
이곳에서 해당 버젼을 다운로드한 후 NAS로 복사해서 작업하길 권한다.
'JAVA'에 해당되는 글 6건
보통 컴포넌트는 컨테이너 add 되어 사용되어진다.
Panel panel = new Panel();
Label label = new Label("NAME CARD");
panel.add(label);
화면의 부드러운 표현을 위해 더블 버퍼링을 쓸 경우가 있는데, 이때 더블 버퍼링이 필요한 해당 객체-컴포넌트-단위로 더블 버퍼링을 구현해야지, 컴포넌트가 add되어 있는 컨테이너를 더블 버퍼링 구현하면 예상치 못한 경우가 발생한다.
이는 setVisible(false)를 통해 해당 컴포넌트를 표시하지 않을 경우, 상위 컨테이너의 update()메소드를 호출하여 화면을 지우고(clearRect()) setVisible(true) 상태의 자식 컴포넌트를 그리기 때문이다.
이때문에, 컨테이너의 update()를 오버라이딩할 경우, 지우는 효과가 없어져(clearRect()) 기존 그림이 그대로 남아있게 된다.
물론, 오버라이딩 이후 따로 화면 정리 코드를 삽입하면 달라지겠다.
Panel panel = new Panel();
Label label = new Label("NAME CARD");
panel.add(label);
화면의 부드러운 표현을 위해 더블 버퍼링을 쓸 경우가 있는데, 이때 더블 버퍼링이 필요한 해당 객체-컴포넌트-단위로 더블 버퍼링을 구현해야지, 컴포넌트가 add되어 있는 컨테이너를 더블 버퍼링 구현하면 예상치 못한 경우가 발생한다.
이는 setVisible(false)를 통해 해당 컴포넌트를 표시하지 않을 경우, 상위 컨테이너의 update()메소드를 호출하여 화면을 지우고(clearRect()) setVisible(true) 상태의 자식 컴포넌트를 그리기 때문이다.
이때문에, 컨테이너의 update()를 오버라이딩할 경우, 지우는 효과가 없어져(clearRect()) 기존 그림이 그대로 남아있게 된다.
물론, 오버라이딩 이후 따로 화면 정리 코드를 삽입하면 달라지겠다.
며칠을 고심 끝에, 찾아냈다고 해야하나 당연하다고 해야 하나...ㅡ,.ㅡa
이전 STB(셋탑박스)에 들어갈 미들웨어의 일부분이 될 application 인 SETUP 프로그램을 개발 중이었다.
TV STB인 관계로 프로그램을 시청하는 중에 "메뉴"버튼을 클릭하면 SETUP 메뉴가 나타나야 한다.
그러다 보니, SETUP 프로그램이 화면 전체를 가리지 않는 이상, SETUP 프로그램 뒤 배경에 영상이 나오게 된다.
디자인적인 미적 효과를 넣게 되면, 뒤 배경 영상 위로 알파값(alpha)을 적용해서 뿌옇게 처리한다던가 등의 왜곡(?)을 줄 수 있겠다.
그 알파값 적용을,
Color c = new Color(r,g,b,a);
g.setColor(c);
g.fillRect(x, y, width, height);
메소드를 통해 화면 구현을 했다.
이 내용을 더블버퍼링으로 변경하면,
Dimension d = getSize();
if ((offGraphics == null) || (d.width != offDimension.width) || (d.height != offDimension.height)) {
offDimension = d;
offImage = createImage(d.width, d.height);
offGraphics = offImage.getGraphics();
}
// (1) offGraphics.clearRect(0, 0, d.width, d.height);
// (2) 최초 배경색으로 채운다. 알파값 적용.
offGraphics.setColor(getBackground());
offGraphics.fillRect(0, 0, d.width, d.height);
// (3) 원하는 알파값을 채운다.
offGraphics.setColor(new java.awt.Color(255, 0, 0, 45));
offGraphics.fillRect(0, 0, 500, 100);
//화면 개체를 그린다.
paintUI(offGraphics);
//실제 화면에 출력한다.
if (offImage != null)
g.drawImage(offImage, 0, 0, null);
위와 같이 구현할 수 있다.
그런데, 알파값을 적용할 경우, 고려 사항이 있는데, 더블 버퍼링을 구현 함에 있어, 내부 버퍼에서 그림을 그리는 Graphics context를 초기화-clear- 를 하지 않으면, 실제 화면 출력시에 알파값 적용 부분이 처음부터 중첩이 되어 나타나게 된다. 즉, 알파값 적용 부분이 점점 진해져서 알파값 적용이 없어지게 된다.
이때에는, 필히 내부 버퍼의 Graphics context를 clear 해 주도록 하자.
위 코드에서 (1) 부분의 주석을 풀어주면 된다.
물론, 보이지않는 내부 버퍼이긴하나 영역 크기만큼 clear 시키는 거라 시간이 지연되긴 한다.
SIGMA8634 chipset 기반에서 시스템 전반에 관여하는 SETUP 프로그래밍을 하고 있다.
havi ui API를 이용하지 않고 java awt api 만을 이용하여 개발 중이다. jvm 호환성만 의존한 상태로 다양한 플랫폼을 지원하기 위해서이다.
SETUP UI 를 개발하면서 가장 큰 애로사항 또는 고려할 점은,
1. 사용자 액션-리모콘 입력-에 따라 즉시 화면이 출력되어야 하므로 빠른 반응을 위해서 SETUP UI 는 미리 메모리에 객체 생성/초기화 되어 있어야 한다.(객체, 리소스(이미지, 사운드 등))
2. STB 과 같은 제한된 자원의 임베디드 환경이라는 점.
3. 메뉴 간 이동(전환) 빠르기가 적절해야 한다.
4. UI 가 편리해야 한다.
..정도로 생각할 수 있겠다.
이 중에서 구현하는 데 있어 깊은(?) 내공을 가지지 않고서는 힘든 부분이 있는데-다른 부분도 마찬가지지만..ㅡ,.ㅡa- , 3번을 고심해 볼 필요가 있다.
예로, A 메뉴가 있고, A 메뉴 내 B 서브 메뉴가 있는 등,
- A
----- B
----------- E
----------- F
----------- G
----- C
----- D
위와 같이 가정하면,
A 메뉴 내에는 B, C, D 메뉴가,
B 메뉴 내에는 E, F, G 메뉴가 구성되어 있다는 것을 알 수 있다.
즉, A 메뉴에서 B 메뉴를 선택하면, 화면이 바뀌면서 전체 화면이 B 메뉴가 주관이 된다.
이때, 전체 A 메뉴에서 B 메뉴로 바뀔 때,
여럿 graphics api 를 이용하여 실시간으로 그림을 그릴 것인지, 미리 화면을 그려놓았다가 화면 전환을 할 것인지는 개발자 몫이다.
하드웨어 성능이 뒷받침이 된다면야 실시간도 무리가 아니지만 임베디드라는 환경에서, 보통은 화면 깜빡임이 나타나는데-큰 화면을 부분적으로 그리더라도, 빠른 PC에서 조차도 나타난다.- 이를 방지하고자 더블버퍼링 기술을 쓰기도 한다.
그래서, 고심 끝에 각 메뉴별 장면을 미리 그려놓았다가 메뉴 전환시 메뉴별 장면을 바꿔치는 방법을 선택했다.-자원 문제에 대해서 다음에 다룬다.-
이를 쉽게 응용할 수 있는 방법으로, awt CardLayout 있었다.
CardLayout 은 장면 전환이 쉽게 되도록 지원하는 배치 관리자 중 하나인데, 카드를 여러 개 포개어 놓고, 필요한 카드만 보는 레이아웃이다.
처음 개발 중에는 저 레이아웃을 이용해 각 장면 단위로 어떤 컴포넌트를 이용할까 고민하다가 고른 것이 Canvas 였다.
java에서 그림 그리기 딱인 컴포넌트가 Canvas 이니까 말이다.
그래서 각 장면을 Canvas를 상속받아 Scene 이란 컴포넌트를 만들게 되었고, 아래와 같이 각 장면 컴포넌트는 CardLayout 에 이용해 출력했다.
//장면 생성
//MainMenu와 SystemMenu는 Scene을 상속
MainMenu mainMenu = new MainMenu();
SystemMenu systemMenu = new SystemMenu();
.
.
//장면을 출력할 container
Frame frame = new Frame("Setup");
Window window = new Window(frame);
//레이아웃매니저
CardLayout cardLayout = new CardLayout();
window.setLayout(cardLayout);
//장면을 등록
window.add("MainMenu", mainMenu);
window.add("SystemMenu", systemMenu);
.
.
//원하는 장면 출력
cardLayout.show(window, "MainMenu");
.
.
cardLayout.show(window, "SystemMenu");
.
.
위와 같은 형태로 코딩했다. 그리고 테스트를 수행...
그런데 생각지 못한 결과가 나왔다.
장면 전환시 깜빡임이 발생했다. 미리 장면을 다 그려놓고 장면을 바꿔치기 한 것 뿐인데 화면 깜빡임이 발생한 것이다.
시간 차를 주고 디버깅을 해보니, 분명 장면을 그리는 중에 나타나는 현상을 아닌 것 같았는데 한참이나 고심을 했다.
그런데 아주 쉽게 풀리는 열쇠를 발견 했으니, 장면이 상속받은 개체에 문제가 있었다.
쉽게 그림그리는 장면 단위만 생각해서 Canvas 개체를 가져다 쓴 것인데, 이게 jvm 내에서 Canvas를 교체할 경우-장면전환- 화면을 다시 지우는 현상이 있었다.
Canvas에서 Container 로 변경하니 깜빡임이 없어졌다.
//변경 전
public abstract class Scene extends Canvas
//변경 후
public abstract class Scene extends Container
Container 를 상속받느냐 Canvas를 상속받느냐에 따른 화면 처리 차이가 궁금해진다.
둘다 Component에서 시작한 것들인데 CardLayout에서 화면 출력시 처리가 다른 모양이다.
언제 찾아보기나 할까나~ ^^;;
havi ui API를 이용하지 않고 java awt api 만을 이용하여 개발 중이다. jvm 호환성만 의존한 상태로 다양한 플랫폼을 지원하기 위해서이다.
SETUP UI 를 개발하면서 가장 큰 애로사항 또는 고려할 점은,
1. 사용자 액션-리모콘 입력-에 따라 즉시 화면이 출력되어야 하므로 빠른 반응을 위해서 SETUP UI 는 미리 메모리에 객체 생성/초기화 되어 있어야 한다.(객체, 리소스(이미지, 사운드 등))
2. STB 과 같은 제한된 자원의 임베디드 환경이라는 점.
3. 메뉴 간 이동(전환) 빠르기가 적절해야 한다.
4. UI 가 편리해야 한다.
..정도로 생각할 수 있겠다.
이 중에서 구현하는 데 있어 깊은(?) 내공을 가지지 않고서는 힘든 부분이 있는데-다른 부분도 마찬가지지만..ㅡ,.ㅡa- , 3번을 고심해 볼 필요가 있다.
예로, A 메뉴가 있고, A 메뉴 내 B 서브 메뉴가 있는 등,
- A
----- B
----------- E
----------- F
----------- G
----- C
----- D
위와 같이 가정하면,
A 메뉴 내에는 B, C, D 메뉴가,
B 메뉴 내에는 E, F, G 메뉴가 구성되어 있다는 것을 알 수 있다.
즉, A 메뉴에서 B 메뉴를 선택하면, 화면이 바뀌면서 전체 화면이 B 메뉴가 주관이 된다.
이때, 전체 A 메뉴에서 B 메뉴로 바뀔 때,
여럿 graphics api 를 이용하여 실시간으로 그림을 그릴 것인지, 미리 화면을 그려놓았다가 화면 전환을 할 것인지는 개발자 몫이다.
하드웨어 성능이 뒷받침이 된다면야 실시간도 무리가 아니지만 임베디드라는 환경에서, 보통은 화면 깜빡임이 나타나는데-큰 화면을 부분적으로 그리더라도, 빠른 PC에서 조차도 나타난다.- 이를 방지하고자 더블버퍼링 기술을 쓰기도 한다.
그래서, 고심 끝에 각 메뉴별 장면을 미리 그려놓았다가 메뉴 전환시 메뉴별 장면을 바꿔치는 방법을 선택했다.-자원 문제에 대해서 다음에 다룬다.-
이를 쉽게 응용할 수 있는 방법으로, awt CardLayout 있었다.
CardLayout 은 장면 전환이 쉽게 되도록 지원하는 배치 관리자 중 하나인데, 카드를 여러 개 포개어 놓고, 필요한 카드만 보는 레이아웃이다.
처음 개발 중에는 저 레이아웃을 이용해 각 장면 단위로 어떤 컴포넌트를 이용할까 고민하다가 고른 것이 Canvas 였다.
java에서 그림 그리기 딱인 컴포넌트가 Canvas 이니까 말이다.
그래서 각 장면을 Canvas를 상속받아 Scene 이란 컴포넌트를 만들게 되었고, 아래와 같이 각 장면 컴포넌트는 CardLayout 에 이용해 출력했다.
//장면 생성
//MainMenu와 SystemMenu는 Scene을 상속
MainMenu mainMenu = new MainMenu();
SystemMenu systemMenu = new SystemMenu();
.
.
//장면을 출력할 container
Frame frame = new Frame("Setup");
Window window = new Window(frame);
//레이아웃매니저
CardLayout cardLayout = new CardLayout();
window.setLayout(cardLayout);
//장면을 등록
window.add("MainMenu", mainMenu);
window.add("SystemMenu", systemMenu);
.
.
//원하는 장면 출력
cardLayout.show(window, "MainMenu");
.
.
cardLayout.show(window, "SystemMenu");
.
.
위와 같은 형태로 코딩했다. 그리고 테스트를 수행...
그런데 생각지 못한 결과가 나왔다.
장면 전환시 깜빡임이 발생했다. 미리 장면을 다 그려놓고 장면을 바꿔치기 한 것 뿐인데 화면 깜빡임이 발생한 것이다.
시간 차를 주고 디버깅을 해보니, 분명 장면을 그리는 중에 나타나는 현상을 아닌 것 같았는데 한참이나 고심을 했다.
그런데 아주 쉽게 풀리는 열쇠를 발견 했으니, 장면이 상속받은 개체에 문제가 있었다.
쉽게 그림그리는 장면 단위만 생각해서 Canvas 개체를 가져다 쓴 것인데, 이게 jvm 내에서 Canvas를 교체할 경우-장면전환- 화면을 다시 지우는 현상이 있었다.
Canvas에서 Container 로 변경하니 깜빡임이 없어졌다.
//변경 전
public abstract class Scene extends Canvas
//변경 후
public abstract class Scene extends Container
Container 를 상속받느냐 Canvas를 상속받느냐에 따른 화면 처리 차이가 궁금해진다.
둘다 Component에서 시작한 것들인데 CardLayout에서 화면 출력시 처리가 다른 모양이다.
언제 찾아보기나 할까나~ ^^;;
현재 IP-TV middle ware를 개발 중이다.
java 언어의 태생 근간이었던 전자 제품에 java 솔루션을 개발하고 적용시키는 일은 정말 재미가 있다.
개발 환경이 이러다보니 정상적인 테스트를 위해서라면 관련 장비, STB(셋톱박스)를 연결하고 m/w를 설치하고, 방송데이터서버를 통해 어플리케이션을 받고 하는 등의 과정이 필요하지만 이는 불편하다.
테스트 장비를 개발자별로 마련하기도 어렵거니와 개발 시간 측면 등 작업 효율이 떨어지는 것이 사실이다.
이런 환경을 개선코자 개발자 환경인 PC에서 STB를 가상으로 구현해주는 에뮬레이터가 필요하다.
xlet 관련 개발에 있어서는 무리없는 성능에 단순 명료한 인터페이스와 로그정보를 보여주는 xletview가 있다.
[ xletview 프로젝트 바로가기 ]
xletview 또한 JAVA로 개발되어 있다.
그림에서 왼쪽은 TV화면이 되며, 오른쪽은 보시다시피 리모컨을 보여주고 있다.
사내 개발 결과물인 예제 어플리케이션을 구동해 보았는데 단순한 만큼 미려하게 잘 보여준다.
xletview 프로젝트 사이트에서 제공하는 소스는 eclipse 환경에서 운영하기가 개인적으로 미덥지 않아 디렉토리 구조 및 약간의 수정을 거쳐 사용하게 되었다.
JAVA 프로그래밍을 두고 api 싸움이라고도 하죠.
JAVA 코딩을 하다보면 상당량의 이미 제공되는 api를 많이 사용하게 됩니다.
또, 기본적인 api 사용법은 eclipse 같은 툴에서 인스턴스명.(쩜)을 찍고 나면 자동으로 메소드명이나 참조 변수명이 설명과 함께 나와 편합니다.
그러나, 제공되는 메소드명만으로 확연한 결과값을 예상할 수 없을 경우, 호출해야 할 메소드의 실 내용을 보고 싶고, 검증하고 싶기도 합니다.
이때, 이미 컴파일된 .class 파일을 다시 .java 파일로 변환해주는 decompile 과정이 필요합니다.
JAVA는 일반적으로 바이너리 파일을 만들어 내는 컴파일러 언어와 달리, .class파일 구동시 JVM을 통해 번역하게(인터프리터) 되는데, 이 과정이 있기 때문에 소스로 돌이킬 수 있습니다.
이때 사용하는 프로그램이 자바 class 디컴파일러입니다. JAD 입니다.
[JAD 홈]
JAVA 개발자들이 가장 보편적으로 많이 쓰는 디컴파일러라 생각됩니다.
그렇다고 원본소스 그대로를 돌려주진 않습니다. 변수명이나 메소명과 같은 경우, 상이한 부분이 나올 수 있고, 또 어디까지나 jvm 입장에서 해석할 수 있는 코드로 환원됩니다.
어떻게 보면 JVM입장을 헤아릴 수 있다고 해야하나요? ㅋ
JAD는 javac처럼 명령프롬프트에서 실행하게 되는데, 이런 불편함을 개선하고자 윈도우 사용자 인터페이스 부분만 따로 만들어진 프로그램들이 여럿 있습니다.
이 윈도우가 있는 UI 프로그램에서 JAD를 호출하는 방식인 거죠.
전 개인적으로 단순한 DJ Java Decompiler를 씁니다.
더 편하고 기능이 좋은 UI 프로그램이 있을까요?
한편, 현시점에서는 JAVA개발자들이 개발툴로 eclipse를 많이 애용하는데, 이와 더불어 쓸 수 있는 jad 플러그인이 좀더 간단하고 편하다고 봅니다.
[ jadclipse 홈 ]
특정 메소드나 클래스명에 커서를 맞추고 F3키를 누르면 바로 실시간으로 디컴파일하여 소스를 새창에 띄워줍니다. 한방인 거죠. ^^-
jad와 jadclipse의 설치 및 사용법은 해당 링크를 따라 가세요.
