이모씨

Graalvm native image

yimoc — Wed, 7 Apr 2021 14:52:06 +0900

1.설치

1) Graalvm 설치

www.graalvm.org/docs/getting-started/#install-graalvm

github.com/graalvm/graalvm-ce-builds/releases

os : windows 10 pro

해당하는 파일 다운로드

setx환경변수 설정이지만

그냥 cmd.exe에서 설정함

set PATH=D:\develop\program\graalvm-ce-java8-21.0.0.2\bin;%PATH%
set JAVA_HOME=D:\develop\program\graalvm-ce-java8-21.0.0.2

set PATH=D:\develop\program\graalvm-ce-java8-21.0.0.2\bin;%PATH%
set JAVA_HOME=D:\develop\program\graalvm-ce-java8-21.0.0.2

setx 환경변수 설정방법
setx /M PATH "D:\develop\program\graalvm-ce-java8-21.0.0.2\bin;%PATH%"
setx /M JAVA_HOME "D:\develop\program\graalvm-ce-java8-21.0.0.2"

2) 추가설치

Download the SDK file GRMSDKX_EN_DVD.iso for from Microsoft.

www.microsoft.com/en-us/download/details.aspx?id=8442

Mount the image by opening F:\Setup\SDKSetup.exe directly.

visaul studio Build Tools 2019 설치

Start -> Visual Studio 2019 ->x64 Native Tools Command Prompt

에서 실행해야함

그렇지 않는 경우 아래 2가지 오류가 발생함

1) Error: Default native-compiler executable 'cl.exe' not found via environment varialbe PATH

2) Error: Native-image building on Windows currently only supports target architecture: AMD64 ((x64) unsupported)

2. Code작성

HelloWorld.java

3. native image 빌드

D:\develop\graalvm_ws>native-image HelloWorld
[helloworld:5400]    classlist:   1,195.32 ms,  1.14 GB
[helloworld:5400]        setup:   1,413.75 ms,  1.14 GB
Error: Native-image building on Windows currently only supports target architecture: AMD64 ((x64) unsupported)
Error: To prevent native-toolchain checking provide command-line option -H:-CheckToolchain
Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Error: Image build request failed with exit status 1

D:\develop\graalvm_ws>native-image -H:-CheckToolchain HelloWorld
[helloworld:40832]    classlist:   1,432.10 ms,  1.15 GB
[helloworld:40832]        (cap):   4,629.42 ms,  1.15 GB
[helloworld:40832]        setup:   6,745.06 ms,  1.15 GB
[helloworld:40832]     (clinit):     132.44 ms,  1.61 GB
[helloworld:40832]   (typeflow):   3,455.79 ms,  1.61 GB
[helloworld:40832]    (objects):   2,803.94 ms,  1.61 GB
[helloworld:40832]   (features):     145.35 ms,  1.61 GB
[helloworld:40832]     analysis:   6,665.44 ms,  1.61 GB
[helloworld:40832]     universe:     324.37 ms,  1.61 GB
[helloworld:40832]      (parse):     736.25 ms,  1.64 GB
[helloworld:40832]     (inline):     870.19 ms,  1.64 GB
[helloworld:40832]    (compile):   4,358.17 ms,  1.78 GB
[helloworld:40832]      compile:   6,352.63 ms,  1.78 GB
[helloworld:40832]        image:     568.52 ms,  1.78 GB
[helloworld:40832]        write:     725.91 ms,  1.78 GB
[helloworld:40832]      [total]:  23,002.35 ms,  1.78 GB

성공!!

추가 참고사항

blogs.oracle.com/javakr/graalvm-nativeimage-revisited

Storage 비교 설명

yimoc — Tue, 6 Apr 2021 11:06:28 +0900

출처

aws.amazon.com/ko/blogs/storage/comparing-your-on-premises-storage-patterns-with-aws-storage-services/

Comparing your on-premises storage patterns with AWS Storage services | Amazon Web Services

Many companies want to move to the cloud, and for most of those companies, moving to the cloud starts with an assessment of existing storage infrastructure. It is useful to know how to map existing storage with AWS Storage options to assess the existing st

aws.amazon.com

1. On-premises stroage pattern

일반적인 On-promise 스토리지는 FC SAN, iSCSI SAN, NAS, Object Storage 를 사용한다.

1) FC(Fibre Channel) SAN Storage

SAN은 전용 고속 FC네트워크를 통해 블록스토리지리소스를 공유하는 기술이다.

FCP(Fibre Channel Protocol)는 FC네트워크를 통한 SCSI프로토콜의 매핑입니다. (? -좀더 조사 필요)

DC SAN을 사용하는 애플리케이션은 ERP, CRM, SAP, SQL, Oarcle, DB2, MSSQL등이 있습니다.

2)iSCSI SAN stroage

iSCSI는 IP네트워크를 통해 스토리지리소스를 공유하는 기술이다.

종종, 디스크리소스는 iSCSI SAN에서 공유되는 저장소 리소스이다.

iSCSI는 TCP/IP를 통한 SCSI 프로토콜 매핑이다.

SCSI가 FC와 같은 다른 전송을 통해 매핑 된 것과 동일한 방식으로, 이론적으로 모든 SCSI 장치가 iSCSI SAN을 통해 공유 될 수 있습니다. iSCSI를 사용하는 애플리케이션의 예는 FC SAN을 사용하는 애플리케이션 유형과 동일하지만 IP 네트워킹 인프라 (예 : ERP, CRM, SAP, SQL, Oracle 등)를 사용하는 애플리케이션입니다.

3)Network attached stroage(NAS)

NAS파일시스템은 공유 파일스토리지 자산이며 비정형 혹은 파일 스토리지라고도 합니다.

Linux용 NFS(Network File Storage)와 Windows용 SMB(Server Message Block) 또는 CIFS(Common Internet File System)와 같은 프로토콜을 사용합니다. NSA는 사용자 및 애플리케이션을 위한 공유 폴더 및 문서 저장소에 자주 사용됩니다.

4)Object Storage

Object Storage르 통해 모든 유형의 데이터를 저장할수 있습니다. 객체는 고유의 식별자와 임의의 해싱체계로 식별합니다. 대부분의 객체는 계층구조 없이 하나의 크고 평평한 네임스페이스에 보관됩니다. 이러한 flat name space는 오브젝트 스토리지 시스템에 내재된 대규모 확정성을 가능하게 합니다.(??) 객체 저장장치(OSD)는 REST, SOAP, XAM과 같은 API 작업을 통해 액세스 됩니다.

2.AWS Storage Service

기존 온프라이스 스토리지를 대체하는 AWS에 사용할 수 있는 Storage Service를 소개한다.

1) Amazon EBS(Elastic Block Store)

Amzon EC2와 함께 사용하게 설계되었다.

relational and non-relational databases, enterprise applications, containerized applications, big data analytics engines, file systems, and media workflows처럼 광범위한 워크로드가 EBS에 배포되어사용한다.

EBS는 온프레미스의 iSCSI, FC SAN Storage Arrary에서 서비스하던 어플리케이션 워크로드를 대체할수 있다.

2) Amazon EFS(Elastic File System)

NFS파일시스템을 제공한다. 애플리케이션을 중단하지 않고 페타바이트까지 확장되며, 파일을 추가 제거할때 자동적으로 확장 축소되며, 관리가 가능하다.

최소 3개의 AZ(가용영역)에 데이터를 저장하면서 한자리수의 밀리초의 지연시간을 제공하는 지역서비스이며 99.9999..(11 9)의 내구성을 설계가 되었다.

EFS는 온프레미스의 NFS 프로토콜기반의 NAS Array에서 서비스하던 애플리케이션 및 사용자 워크로드를 대체할수 있다.

3) Amzon FSx(Windows 파일 서버용 )

SMB프로토콜을 통해 액세스 할 수 있는 스토리지이다.

4)Amazon S3(Simple Storage Service)

객체 스토리지 서비스이다. 확장성, 데이터가용성, 보안 및 성능이 유지된다다.

웹사이트, 모바일어플리케이션, 백업 및 복원, 아카이브, 엔터프라이즈 애플리케이션, Iot 장치 및 빅데티어 분석 등 다양한 사례가 있다.

다양한 사용 사례를 위핸 스토리지 클래스(aws.amazon.com/ko/s3/storage-classes/)를 제공한다.

온프레미스의 객체기반 및 파일 기반 스토리지 Array를 대체가능하다.

chorme 의 OPTION Method호출

yimoc — Thu, 27 Jun 2019 15:27:49 +0900

Chorme 브라우져에서 POST를 요청할때 OPTION으로 바뀌어서 서버로 호출하는 경우가 발생한다.

nexacro studio에서 개발툴의 webserver로 구동하고 STS에서 tomcat구동시 발생한다.

console 이경우 아래 처럼 오류가 나온다.

SystemBase_HTML5.js:8133 OPTIONS http://localhost:8080/nexup/simpleresponse.do 500 (Internal Server Error)
nexacro.__startCommunication @ SystemBase_HTML5.js:8133
nexacro._startCommunication @ SystemBase.js:6128
nexacro._loadData @ SystemBase.js:6035
__pLoadManager.loadDataModule @ Platform.js:1157
_pForm.transaction @ FormBase.js:3814
Button00_onclick @ tt.xfdl.js:49
_pEventListener._fireEvent @ SystemBase.js:2632
_pComponent.on_fire_onclick @ CompEventBase.js:3832
_pComponent._on_click @ CompEventBase.js:526
__pWindow._on_default_sys_lbuttonup @ Platform.js:3462
nexacro._syshandler_lock_onmouseup @ Platform_HTML5.js:1481
_cur_win._syshandler_lock_onmouseup_forward @ Platform_HTML5.js:491
quickview.html?screenid=Desktop_screen&formname=Base::tt.xfdl:1 Access to XMLHttpRequest at 'http://localhost:8080/nexup/simpleresponse.do' from origin 'http://127.0.0.1:4098' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

아래처럼 Invalid CORS request가 발생된다.

OPTIONS http://localhost:8080/nexup/simpleresponse.do HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://127.0.0.1:4098
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Access-Control-Request-Headers: cache-control,content-type,x-requested-with
Accept: */*
Referer: http://127.0.0.1:4098/quickview.html?screenid=Desktop_screen&formname=Base::tt.xfdl
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

HTTP/1.1 403 Forbidden
Server: Apache-Coyote/1.1
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Content-Length: 20
Date: Thu, 27 Jun 2019 06:24:08 GMT

Invalid CORS request

해결하기위해서는 CORS 위해 세팅해야한다.

<mvc:cors>

<mvc:mapping path="/**/>

</mvc:cors>

위의 PreFlightHandler 처리를 위해서 HttpHttpRequestHandlerAdapter가 필요하다.

해당 Controller에서 @CrossOrigin 설정

하지 않는경우 Status Code:403 Forbidden 으로 응답처리 된다.

설정하면

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: http://127.0.0.1:4098
Vary: Origin
Access-Control-Allow-Methods: GET,HEAD,POST
Access-Control-Allow-Headers: cache-control, content-type, x-requested-with
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1800
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Content-Length: 0
Date: Thu, 27 Jun 2019 06:19:08 GMT

POST http://localhost:8080/nexup/simpleresponse.do HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 0
Accept: application/xml, text/xml, */*
cache-control: no-cache
Origin: http://127.0.0.1:4098
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Content-Type: text/xml
Referer: http://127.0.0.1:4098/quickview.html?screenid=Desktop_screen&formname=Base::tt.xfdl
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: http://127.0.0.1:4098
Vary: Origin
Access-Control-Allow-Credentials: true
Content-Type: text/html;charset=UTF-8
Content-Language: ko-KR
Transfer-Encoding: chunked
Date: Thu, 27 Jun 2019 06:19:08 GMT

df
SSV:UTF-8 ErrorCode:int=0 Dataset:ds1 _RowType_ col2:string(32) col1:string(32) N

0

다시 문제점 발생 재요청시 다시 요청하지 않는다??

too many files opens 오류

yimoc — Wed, 19 Jun 2019 17:53:55 +0900

오류 메시지 : jar파일은 바뀜

java.io.FileNotFoundException : /usr~~~/ .jar (열린 파일이 너무 많음)

too many files opens

1. 오류 발생 원인
오류는 Too many open files로 제한된 file descriptor의 개수를 초과하여 발생

ulimit -a 로 현재 설정된 open file 한계치 확인

2. 발생 원인 분석
2-1) 일시적으로 과부하에 의한 것인지?

설정된 FD가 적고 일시적 과부인 경우는 FD 개수를 늘려서 해결

2-2) File descriptor가 누적되어 발생한 것인지 ?
통신(socket..), input/out stream , 파일 등에서 close가 제대로 되지 않아 발생합니다.
Close가 되지 않으므로 누적되어 제한된 FD개수를 초과한 것입니다.

선행적으로 FD의 정보를 확인하시기 바랍니다. 해지 되지 않고 지속적으로 증가되는지 파악이 필요합니다.

물론, 의심되는 서비스를 호출하여 FD가 증가되지는 확인하는 것이 빠릅니다.
지속적으로 fd 수가 증가할 경우는 코드에서 문제가 발생한 것입니다.

이 경우는 해당 원인이 되는 코드를 수정해야 합니다.

테스트 및 체크 방법

1. File not close 서비스 개발
- 일부러 파일을 close하지 않음

@RequestMapping("notclosefile")

public void doService() throws ServiceException {

String path = axb2ServiceManager.getServicePath();

System.out.println("path="+path);

File file = new File(path+"/h2_sample/merge.xml");

try { FileInputStream fileInputStream = new FileInputStream(file);

} catch (FileNotFoundException e) {

// TODO Auto-generated catch block e.printStackTrace();

}

2. centos에서 FD 체크

$ ls -l /proc/19586/fd

total 0

lr-x------ 1 tobesoft tobesoft 64 Jun 18 10:21 0 -> /dev/null ~~~

l-wx------ 1 tobesoft tobesoft 64 Jun 18 10:21 1 -> /home/tobesoft/apache-tomcat-7.0.33/logs/catalina.out lr-x------ 1 tobesoft tobesoft 64 Jun 18 10:22 118 -> /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml

lr-x------ 1 tobesoft tobesoft 64 Jun 18 10:23 119 -> /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml ~~

lr-x------ 1 tobesoft tobesoft 64 Jun 18 10:22 52 -> /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml

중복 체크 확인 함

3. File Leack Detector 로 체크

opensource로 제공됨 : http://file-leak-detector.kohsuke.org/
Usage :
java -javaagent:path/to/file-leak-detector.jar=http=19999
> 19999 port 로 로그가 나옴

Browser로 http://ip:19999로 연결시 열려 있는 file 정보를 알려준다.

아래 실제 정보 정리

#17 /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml by thread:http-bio-8081-exec-5 on Tue Jun 18 10:23:23 KST 2019 at java.io.FileInputStream.<init>(FileInputStream.java:139) at nexacro.sample.NotCloseFileController.doService(NotCloseFileController.java:31)

#29 /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml by thread:http-bio-8081-exec-10 on Tue Jun 18 10:22:17 KST 2019 at java.io.FileInputStream.<init>(FileInputStream.java:139) at nexacro.sample.NotCloseFileController.doService(NotCloseFileController.java:31)

#32 /home/tobesoft/apache-tomcat-7.0.33/webapps/nexup/WEB-INF/service/h2_sample/merge.xml by thread:http-bio-8081-exec-10 on Tue Jun 18 10:22:03 KST 2019 at java.io.FileInputStream.<init>(FileInputStream.java:139) at nexacro.sample.NotCloseFileController.doService(NotCloseFileController.java:31)

file-leak-detector option

File leak detector arguments (to specify multiple values, separate them by ',': help - show the help screen. trace - log every open/close operation to stderr. trace=FILE - log every open/close operation to the given file. error=FILE - if 'too many open files' error is detected, send the dump here. by default it goes to stderr. threshold=N - instead of waiting until 'too many open files', dump once we have N descriptors open. http=PORT - Run a mini HTTP server that you can access to get stats on demand Specify 0 to choose random available port, -1 to disable, which is default. strong - Don't let GC auto-close leaking file descriptors listener=S - Specify the fully qualified name of ActivityListener class to activate from beginning dumpatshutdown- Dump open file handles at shutdown excludes=FILE - Ignore files opened directly/indirectly in specific methods. File lists 'some.pkg.ClassName.methodName' patterns.

도서 대출 챗봇 2

yimoc — Wed, 16 Jan 2019 16:50:58 +0900

환경

Python 3.5

개발 환경 : MacOs + Pycharm

배포 환경 : CentOS release 6.10

1. 기본 Bot Server 개발

1) Bot 신청

2) BotServer 개발

설치 package :

library

zbar : 바코드 인식용

python package

python-telegram-bot : telegram bot 개발 패키지

pyzbar : 바코드 인식용

requests, urllib3 : api 서버 통신용

---------------------------------------------------------

TODO

KoNLPy : 현재 macOS에서 설치 오류가 남.. libc++이 오류 남 stdlibc++로 copy해서 대체해보았즈만 실패

tensorflow : KoNLPy 설치 후 진행 할 예정

>> 주요목적이 사용자가 입력한 메시지를 파싱 -> 문맥파악 -> 의도 파악 -> 처리 -> 결과문 생성 할랬는데 나중에 해야겠군..

2.테스트

테스트 환경 구성 필요

3.배포

서버설정(CentOS 3.5 )진행

Python 3.5 설치

package 가져오기

# curl -O https://www.python.org/ftp/python/3.5.6/Python-3.5.6.tgz

설치

#configure

#make

#make install

> Error need TLS/SSL 발생

#openssl-devel 설치

#yum install openssl-devel

Zbar설치

https://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

#yum repolist

#yum install zbar zbar-devel

Python package 설치

pip3 upgrade 한번 하고 진행한다.

#pip3 install --upgrade pip

Python 패키지는 개발환경과 동일하게 설치를 위해 아래로 진행한다.

# pip3 freeze pip-requriement.txt로 사용

# pip3 install -r pip-requriement.txt --user

code 배포

이번엔 그냥 sftp로 전송

> 각종 패키지 설치가 이원화 됨으로 문제가 발생한다.

도커를 사용하여 개발환경과 배포 환경을 일원화 하는것이 낫다고 판단된다.

하지만 PyCharm community는 지원하지 않는다..돈주고 사야할듯..

도서 대출 챗봇 1

yimoc — Wed, 9 Jan 2019 17:16:59 +0900

회사 사내 동우회인 북어회를 위해 대출시스템을 개인적으로 구축하고 있다.

해당 자료를 정리하기 위해 작성한다.

1. 구성

ASIS)

추가로 iPhone Native App을 개발 하려 했으나 게으름으로 스킵 중..

2019년을 한해는 챗봇이나 한번 해보려고 추가적인 작업을 계획하였다.

TOBE)

2. 상세

Bot Server 상세

모듈 구성 :

1) BotServer

기본 구성 : telegram chat bot 과 연동하는 기본 모듈

2) Command처리 모듈

v1) 현재는 기본 command를 기준으로 처리하기

Rule base 로 처리 : "내대출", "사용자등록"...

v2) 머신러닝으로 텍스트기반으로 처리하기

1) 자연어 처리

2) 분석

3) 의도

4) 결과말 생성

3) Barcode 처리

Image 처리 : 전송받은 이미지 저장

Barcode 읽기 : 전송 받은 이미지에서 Barcode값을 읽음

4) Backend API 서버 연동 모듈

Booker 서버에 접속하여 대출,반납등 기본 호출 하는 모듈

3. 기본 flow

*대출 / 반납

이미지 전송 -> 이미지저장 -> 바코드 인식 -> API server에서 대출요청 -> 대출 및 반납 처리 -> DB 저장 -> 결과 전송

ASM User Guide 번역 4

yimoc — Fri, 14 Sep 2018 16:44:15 +0900

2018/09/11 - [ASM] - ASM User Guide 번역 3

4. Metadata

이 장에서는 핵심 API를 사용하여 주석과 같은 컴파일 된 Java 클래스 메타 데이터를 생성하고 변환하는 방법에 대해 설명합니다. 각 섹션은 한 가지 유형의 메타 데이터의 프리젠 테이션으로 시작한 다음 몇 가지 예시적인 예와 함께 해당 메타 데이터를 생성하고 변환하는 해당 ASM 인터페이스, 구성 요소 및 도구를 제공합니다.

4.1. Generics

List <E>와 같은 일반 클래스와이를 사용하는 클래스에는 선언하거나 사용하는 제네릭 형식에 대한 정보가 들어 있습니다. 이 정보는 런타임시 바이트 코드 명령어에 의해 사용되지 않지만 리플렉션 API를 통해 액세스 할 수 있습니다. 또한 별도의 컴파일을 위해 컴파일러에서 사용됩니다.

4.1.1. Structure

이전 버전과의 호환성을 위해 제네릭 형식에 대한 정보는 형식 또는 메서드 설명자 (Java 5에서 제네릭 소개 이전에 정의 된)에 저장되지 않았지만 형식, 메서드 및 클래스 서명이라는 유사한 구문으로 저장되었습니다. 이러한 서명은 제네릭 형식이 관련된 경우 클래스, 필드 및 메서드 선언의 설명자와 함께 저장됩니다 (제네릭 형식은 메서드의 바이트 코드에 영향을주지 않습니다. 컴파일러는 정적 형식 검사를 수행하기 위해이를 사용하지만 메서드를 컴파일 한 것처럼 필요한 경우 유형 캐스트를 다시 도입하여 사용하지 않음).

형식 및 메서드 설명자와 달리 generic 형식의 재귀 적 특성 때문에 (generic 형식은 generic 형식으로 매개 변수화 될 수 있습니다. 예를 들어 List <List <E>?>를 고려하십시오.) 형식 시그니처의 문법은 상당히 복잡합니다. 이것은 다음 규칙에 따라 제공됩니다 (이 규칙에 대한 자세한 설명은 Java Virtual Machine Specification 참조).

TypeSignature: Z | C | B | S | I | F | J | D | FieldTypeSignature

FieldTypeSignature: ClassTypeSignature | [ TypeSignature | TypeVar

ClassTypeSignature: L Id ( / Id )* TypeArgs? ( . Id TypeArgs? )* ;

TypeArgs: < TypeArg+ >

TypeArg: * | ( + | - )? FieldTypeSignature

TypeVar: T Id ;

첫 번째 규칙은 형식 서명이 원시 형식 설명자 또는 필드 형식 서명 중 하나임을 나타냅니다. 두 번째 규칙은 클래스 형식 서명, 배열 형식 서명 또는 형식 변수로 필드 형식 서명을 정의합니다. 세 번째 규칙은 클래스 유형 시그니처를 정의합니다. 가능한 유형 인수를 갖는 클래스 유형 설명자, 꺾쇠 괄호 사이, 주 클래스 이름 뒤 또는 내부 클래스 이름 뒤 (점 앞에 접두사가 있음)입니다. 나머지 규칙은 유형 인수 및 유형 변수를 정의합니다. 타입 인자는 타입 인자가있는 완전한 필드 타입 시그니쳐가 될 수있다. 그러므로 타입 시그니쳐는 매우 복잡 할 수있다 (그림 4.1 참조).

Java type and corresponding type signature

List <E>

Ljava/util/List;

List <?>

Ljava/util/List<*>;

List<? extends Number>

Ljava/util/List<+Ljava/lang/Number;>;

List<? super Integer>

Ljava/util/List<-Ljava/lang/Integer;>;

List<List<String>[]>

Ljava/util/List<[Ljava/util/List<Ljava/lang/String;>;>;

HashMap<K, V>.HashIterator<K>

Ljava/util/HashMap<TK;TV;>.HashIterator<TK;>;

Figure 4.1.: Sample type signatures

메서드 서명은 형식 시그니처와 같은 메서드 설명자를 확장하여 형식 설명자를 확장합니다. 메소드 서명은 메소드 매개 변수의 유형 서명과 리턴 유형의 서명을 설명합니다. 메소드 서술자와는 달리 메소드 앞에 던져진 예외의 서명을 포함하며 꺽쇠 괄호 사이에 선택적 형식 매개 변수도 포함 할 수 있습니다.

MethodTypeSignature:

TypeParams? ( TypeSignature* ) ( TypeSignature | V ) Exception*

Exception: ^ClassTypeSignature | ^TypeVar

TypeParams: < TypeParam+ >

TypeParam: Id : FieldTypeSignature? ( : FieldTypeSignature )*

예를 들어 다음과 같은 제네릭 정적 메서드의 메서드 시그니처는 형식 변수 T로 매개 변수화됩니다.

static <T> Class<? extends T> m (int n)

is the following method signature:

<T:Ljava/lang/Object;>(I)Ljava/lang/Class<+TT;>;

마지막으로 클래스 서명과 혼동되어서는 안되는 클래스 서명은, 수퍼 클래스의 타입 시그니처, 구현 된 인터페이스의 타입 시그니처 및 선택적 형식 타입 매개 변수로 정의됩니다.

ClassSignature: TypeParams? ClassTypeSignature ClassTypeSignature*

For example the class signature of a class declared as C<E> extends List<E>

is <E:Ljava/lang/Object;>Ljava/util/List<TE;>;.

4.1.2. Interfaces and components

Descriptor디스크립터와 동일한 효율성을 이유로 (2.3.1 절 참조), ASM API는 컴파일 된 클래스에 저장된 서명을 노출합니다

(서명의 주된 발생은 선택적 클래스, 유형 또는 메소드 서명 인수로서 각각 ClassVisitor 클래스의 visitField 및 visitMethod 메소드에 있습니다). 바라건대 SignatureVisitor 추상 클래스 (그림 4.2 참조)를 기반으로 org.objectweb.asm.signature 패키지에서 서명을 생성하고 변환하는 도구를 제공하기를 바랍니다.

public abstract class SignatureVisitor {

public final static char EXTENDS = ’+’;

public final static char SUPER = ’-’;

public final static char INSTANCEOF = ’=’;

public SignatureVisitor(int api);

public void visitFormalTypeParameter(String name);

public SignatureVisitor visitClassBound();

public SignatureVisitor visitInterfaceBound();

public SignatureVisitor visitSuperclass();

public SignatureVisitor visitInterface();

public SignatureVisitor visitParameterType();

public SignatureVisitor visitReturnType();

public SignatureVisitor visitExceptionType();

public void visitBaseType(char descriptor);

public void visitTypeVariable(String name);

public SignatureVisitor visitArrayType();

public void visitClassType(String name);

public void visitInnerClassType(String name);

public void visitTypeArgument();

public SignatureVisitor visitTypeArgument(char wildcard);

public void visitEnd();

}

Figure 4.2.: The SignatureVisitor class

이 추상 클래스는 type 시그니처, 메소드 서명과 클래스 서명를 방문하는 데 사용됩니다. 형식 시그니처를 방문하는 데 사용되는 메서드는 굵게 표시되어 이전 문법 규칙을 반영하는 다음 순서로 호출해야합니다 (두 개는 SignatureVisitor를 반환 함 : 이는 형식 시그니처의 재귀 적 정의 때문 임).

visitBaseType | visitArrayType | visitTypeVariable |

( visitClassType visitTypeArgument*

( visitInnerClassType visitTypeArgument* )* visitEnd ) )

The methods used to visit method signatures are the following:

( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )*

visitParameterType* visitReturnType visitExceptionType*

Finally the methods used to visit class signatures are:

( visitFormalTypeParameter visitClassBound? visitInterfaceBound* )*

visitSuperClass visitInterface*

이러한 메서드의 대부분은 SignatureVisitor를 반환합니다. type 서명을 방문하기위한 것입니다. ClassVisitor에 의해 리턴 된 MethodVisitors와는 달리, SignatureVisitor에 의해 반환 된 SignatureVisitor는 null이 아니어야하며 순차적으로 사용해야합니다. 실제로 중첩 된 서명이 완전히 방문되기 전에 부모 방문자의 메서드를 호출해야합니다.

클래스와 마찬가지로 ASM API는이 API를 기반으로 두 가지 구성 요소를 제공합니다. SignatureReader 구성 요소는 서명을 파싱하고 주어진 서명 방문객에 대해 적절한 방문 메소드를 호출하며 SignatureWriter 구성 요소는 수신 한 메소드 호출을 기반으로 서명을 작성합니다. 이 두 클래스는 클래스 및 메서드와 동일한 원칙을 사용하여 시그니처를 생성하고 변환하는 데 사용할 수 있습니다. 예를 들어, 일부 서명에 나타나는 클래스 이름의 이름을 바꾸려고한다고 가정 해 보겠습니다. 이는 visitClassType 및 visitInnerClassType 메소드를 제외하고 변경되지 않은 모든 메소드 호출을 전달하는 다음 서명 어댑터로 수행 할 수 있습니다 (여기서 sv 메소드는 항상 SignatureWriter의 경우를 리턴한다고 가정합니다).

public class RenameSignatureAdapter extends SignatureVisitor {

private SignatureVisitor sv;

private Map<String, String> renaming;

private String oldName;

public RenameSignatureAdapter(SignatureVisitor sv, Map<String, String> renaming) {

super(ASM4);

this.sv = sv;

this.renaming = renaming;

}

public void visitFormalTypeParameter(String name) {

sv.visitFormalTypeParameter(name);

}

public SignatureVisitor visitClassBound() {

sv.visitClassBound();

return this;

}

public SignatureVisitor visitInterfaceBound() {

sv.visitInterfaceBound();

return this;

}

...

public void visitClassType(String name) {

oldName = name;

String newName = renaming.get(oldName);

sv.visitClassType(newName == null ? name : newName);

}

public void visitInnerClassType(String name) {

oldName = oldName + "." + name;

String newName = renaming.get(oldName);

sv.visitInnerClassType(newName == null ? name : newName);

}

public void visitTypeArgument() {

sv.visitTypeArgument();

}

public SignatureVisitor visitTypeArgument(char wildcard) {

sv.visitTypeArgument(wildcard);

return this;

}

public void visitEnd() {

sv.visitEnd();

}

Then the result of the following code is "LA.B;":

String s = "Ljava/util/HashMap<TK;TV;>.HashIterator<TK;>;";

Map<String, String> renaming = new HashMap<String, String>();

renaming.put("java/util/HashMap", "A");

renaming.put("java/util/HashMap.HashIterator", "B");

SignatureWriter sw = new SignatureWriter();

SignatureVisitor sa = new RenameSignatureAdapter(sw, renaming);

SignatureReader sr = new SignatureReader(s);

sr.acceptType(sa);

sw.toString();

4.1.3. Tools

2.3 절에 제시된 TraceClassVisitor와 ASMifier 클래스는 클래스 파일에 포함 된 서명을 내부 형식으로 인쇄합니다. 이 클래스는 특정 제네릭 형식에 해당하는 서명을 찾기 위해 사용할 수 있습니다. 일부 일반 형식으로 Java 클래스를 작성하고 컴파일 한 다음 해당 명령 줄 도구를 사용하여 해당 서명을 찾습니다.

4.2. Annotations

@Deprecated 또는 @Override와 같은 클래스, 필드, 메서드 및 메서드 매개 변수 주석은 보유 정책이 RetentionPolicy.SOURCE가 아닌 경우 컴파일 된 클래스에 저장됩니다. 이 정보는 런타임시 바이트 코드 명령어에 의해 사용되지 않지만 보존 정책이 RetentionPolicy.RUNTIME 인 경우 리플렉션 API를 통해 액세스 할 수 있습니다. 컴파일러에서 사용할 수도 있습니다.

4.2.1. Structure

소스 코드의 annotation은 다양한 형식을 가질 수 있지만,

@ Retention (RetentionPolicy.CLASS) 또는 @Task (desc = "refactor", id = 1)와 같은 속성을 사용합니다. 그러나 내부적으로 모든 주석은 동일한 형식을 가지며 주석 유형과 이름 값 쌍으로 지정됩니다. 여기서 값은 다음으로 제한됩니다.

• primitives, Strng 또는 Vlass 값

• enum 값,

• annotation 값,

• 위의 값의 배열.

주석은 다른 주석 또는 심지어 주석 배열을 포함 할 수 있습니다. 따라서 어노테이션은 매우 복잡 할 수 있습니다.

4.2.2. Interfaces and components

어노테이션 생성 및 변환을위한 ASM API는 AnnotationVisitor 추상 클래스를 기반으로합니다 (그림 4.3 참조).

public abstract class AnnotationVisitor {

public AnnotationVisitor(int api);

public AnnotationVisitor(int api, AnnotationVisitor av);

public void visit(String name, Object value);

public void visitEnum(String name, String desc, String value);

public AnnotationVisitor visitAnnotation(String name, String desc);

public AnnotationVisitor visitArray(String name);

public void visitEnd();

}

Figure 4.3.: The AnnotationVisitor class

이 클래스의 메소드는 annotation의 이름와 값 쌍을 방문하는 데 사용됩니다. (annnotation 형식은 이 형식을 반환하는 메서드, 즉 visitAnnotation 메서드에서 방문됩니다. 첫 번째 메서드는 primitive, String 및 Class 값 (나중에 Type 개체로 나타냄)에 사용되며 다른 메서드는 열거 형, annotation 및 배열 값에 사용됩니다. visitEnd를 제외한 모든 순서로 호출 할 수 있습니다.

( visit | visitEnum | visitAnnotation | visitArray )* visitEnd

두 가지 메소드가 AnnotationVisitor를 리턴한다는 점에 유의하십시오.

annotation은 다른 annotation을 포함 할 수 있기 때문입니다. 또한 ClassVisitor에서 반환 한 MethodVisitors와 달리 이 두 메서드에 의해 반환 된 AnnotationVisitors는 순차적으로 사용해야합니다. 실제로 중첩 된 주석을 완전히 방문하기 전에 상위 방문자에 대한 메서드를 호출해야합니다. visitArray 메서드는 AnnotationVisitor를 반환하여 배열의 요소를 방문합니다. 그러나 배열의 요소 이름이 지정되지 않았으므로 이름 인수는 visitArray가 반환 한 방문자의 메서드에 의해 무시되며 null로 설정할 수 있습니다.

Adding, removing and detecting annotations

필드 및 메소드와 마찬가지로 visitAnnotation 메소드에서 null을 반환하여 주석을 제거 할 수 있습니다.

public class RemoveAnnotationAdapter extends ClassVisitor {

private String annDesc;

public RemoveAnnotationAdapter(ClassVisitor cv, String annDesc) {

super(ASM4, cv);

this.annDesc = annDesc;

}

@Override

public AnnotationVisitor visitAnnotation(String desc, boolean vis) {

if (desc.equals(annDesc)) {

return null;

}

return cv.visitAnnotation(desc, vis);

}

ClassVisitor 클래스의 메서드를 호출해야하는 제약 때문에 클래스 주석을 추가하는 것이 더 어렵습니다. 실제로 visitAnnotation을 따르는 모든 메소드는 모든 annotation이 방문되었을 때를 감지하기 위해 무시되어야합니다 (메소드 주석은 visitCode 메소드로 인해 더 쉽게 추가 할 수 있습니다).

public class AddAnnotationAdapter extends ClassVisitor {

private String annotationDesc;

private boolean isAnnotationPresent;

public AddAnnotationAdapter(ClassVisitor cv, String annotationDesc) {

super(ASM4, cv);

this.annotationDesc = annotationDesc;

}

@Override

public void visit(int version, int access, String name,

String signature, String superName, String[] interfaces) {

int v = (version & 0xFF) < V1_5 ? V1_5 : version;

cv.visit(v, access, name, signature, superName, interfaces);

}

@Override

public AnnotationVisitor visitAnnotation(String desc,

boolean visible) {

if (visible && desc.equals(annotationDesc)) {

isAnnotationPresent = true;

}

return cv.visitAnnotation(desc, visible);

}

@Override

public void visitInnerClass(String name, String outerName,String innerName, int access) {

addAnnotation();

cv.visitInnerClass(name, outerName, innerName, access);

}

@Override

public FieldVisitor visitField(int access, String name, String desc,String signature, Object value) {

addAnnotation();

return cv.visitField(access, name, desc, signature, value);

}

@Override

public MethodVisitor visitMethod(int access, String name,String desc, String signature, String[] exceptions) {

addAnnotation();

return cv.visitMethod(access, name, desc, signature, exceptions);

}

@Override

public void visitEnd() {

addAnnotation();

cv.visitEnd();

}

private void addAnnotation() {

if (!isAnnotationPresent) {

AnnotationVisitor av = cv.visitAnnotation(annotationDesc, true);

if (av != null) {

av.visitEnd();

}

isAnnotationPresent = true;

}

이 어댑터는 클래스 버전이 1.5보다 작 으면 클래스 버전을 1.5로 업그레이드합니다. 이것은 JVM이 버전이 1.5보다 작은 클래스의 주석을 무시하기 때문에 필요합니다.

클래스 및 메소드 어댑터에서 annotation를 사용한 가장 자주 사용되는 사례는 annotation를 사용하여 변형을 매개 변수화하는 것입니다. 예를 들어 @Persistent 주석이있는 필드에 대해서만 필드 액세스를 변환하고 @Log 주석이있는 메소드에만 로깅 코드를 추가 할 수 있습니다. 주석을 먼저 방문해야하기 때문에 이러한 모든 사례를 쉽게 구현할 수 있습니다. 필드 및 메소드와 메소드 및 매개 변수 주석을 코드보다 먼저 방문해야 클래스 annotation을 먼저 방문해야합니다. 그러므로 isAnnotationPresent 플래그로 위의 예에서 수행 된 것처럼 원하는 annotation이 감지 될 때 플래그를 설정하고 변환에서 나중에 사용하는 것으로 충분합니다.

4.2.3. Tools

TraceClassVisitor, CheckClassAdapter 및 ASMifier 클래스는 2.3 절에서 주석을 지원합니다 (예 : 메서드의 경우 TraceAnnotationVisitor 또는 CheckAnnotationAdapter를 사용하여 클래스 수준이 아닌 개별 주석 수준에서 작업 할 수도 있음). 특정 주석을 생성하는 방법을 확인하는 데 사용할 수 있습니다. 예를 들면 :

java -classpath asm.jar:asm-util.jar \

org.objectweb.asm.util.ASMifier \

java.lang.Deprecated

prints code that, after minor refactoring, reads:

package asm.java.lang;

import org.objectweb.asm.*;

public class DeprecatedDump implements Opcodes {

public static byte[] dump() throws Exception {

ClassWriter cw = new ClassWriter(0);

AnnotationVisitor av;

cw.visit(V1_5, ACC_PUBLIC + ACC_ANNOTATION + ACC_ABSTRACT+ ACC_INTERFACE, "java/lang/Deprecated", null,

"java/lang/Object",

new String[] { "java/lang/annotation/Annotation" });

{

av = cw.visitAnnotation("Ljava/lang/annotation/Documented;", true);

av.visitEnd();

}

{

av = cw.visitAnnotation("Ljava/lang/annotation/Retention;", true);

av.visitEnum("value", "Ljava/lang/annotation/RetentionPolicy;","RUNTIME");

av.visitEnd();

}

cw.visitEnd();

return cw.toByteArray();

}

이 코드는 ACC_ANNOTATION 플래그를 사용하여 두 사람이 주석 클래스를 작성하는 방법과 값이 없는 클래스 주석과 enum 값이있는 클래스 annotation을 작성하는 방법을 보여줍니다. MethodVisitor 클래스에 정의 된 visitAnnotation 및 visitParameterAnnotation 메서드를 사용하여 메서드 및 매개 변수 annotation을 비슷한 방식으로 만들 수 있습니다.

4.3. Debug

javac -g로 컴파일 된 클래스는 소스 파일의 이름, 소스 행 번호와 바이트 코드 명령어 간의 매핑, 소스 코드의 로컬 변수 이름과 바이트 코드의 로컬 변수 슬롯 간의 매핑을 포함합니다. 이 선택적 정보는 디버거 및 예외 스택 추적이 사용 가능할 때 사용됩니다.

4.3.1. Structure

클래스의 소스 파일 이름은 전용 클래스 파일 구조 섹션에 저장됩니다 (그림 2.1 참조).

소스 행 번호와 바이트 코드 명령 간의 매핑은 메소드의 컴파일 된 코드 섹션에 (행 번호, 레이블) 쌍의 목록으로 저장됩니다. 예를 들어, l1, l2 및 l3이이 순서로 나타나는 세 개의 레이블이면 다음 쌍이됩니다.

(n1, l1)

(n2, l2)

(n3, l3)

l1과 l2 사이의 명령어가 n1 라인에서 나오고, l2와 l3 사이의 명령어는 n2 라인에서 나오고, l3 이후의 명령어는 n3 라인에서 옵니다. 주어진 줄 번호는 여러 쌍으로 나타날 수 있습니다. 단일 소스 행에 나타나는 표현식에 해당하는 명령어가 바이트 코드에서 연속적이지 않을 수 있기 때문입니다. 예를 들어 (init; cond; incr) 문; 일반적으로 다음 순서로 컴파일됩니다 : init statement incr cond.

소스 코드의 로컬 변수 이름과 바이트 코드의 로컬 변수 슬롯 간의 매핑은 메소드의 컴파일 된 코드 섹션에있는 (이름, type 설명자, type 서명, 시작, 끝, 색인) 튜플의 목록으로 저장됩니다. 이러한 튜플은 두 레이블 시작과 끝 사이에서 슬롯 인덱스의 로컬 변수가 소스 코드의 이름과 유형이 처음 세 튜플 요소에 의해 주어진 로컬 변수에 해당 함을 의미합니다. 컴파일러는 동일한 지역 변수 슬롯을 사용하여 서로 다른 범위의 고유 한 소스 로컬 변수를 저장할 수 있습니다. 반대로 고유 한 소스 로컬 변수는 인접하지 않은 범위가있는 로컬 변수 슬롯으로 컴파일 될 수 있습니다. 예를 들어 다음과 같은 상황이있을 수 있습니다.

l1:

... // here slot 1 contains local variable i

l2:

... // here slot 1 contains local variable j

l3:

... // here slot 1 contains local variable i again

end:

해당 튜플은 다음과 같습니다.

("i", "I", null, l1, l2, 1)

("j", "I", null, l2, l3, 1)

("i", "I", null, l3, end, 1)

4.3.2. Interfaces and components

디버그 정보는 ClassVisitor 및 MethodVisitor 클래스의 세 가지 메소드로 방문합니다.

• 소스 파일 이름은 ClassVisitor 클래스의 visitSource 메소드로 방문합니다.

• 소스 라인 번호와 바이트 코드 명령어 간의 매핑은 MethodVisitor 클래스의 visitLineNumber 메소드를 사용하여 한 번에 한 쌍씩 방문합니다.

• 소스 코드의 로컬 변수 이름과 바이트 코드의 로컬 변수 슬롯 간의 매핑은 MethodVisitor 클래스의 visitLocalVariable 메소드 (한 번에 하나의 튜플)를 통해 수행됩니다.

인수로 전달 된 레이블을 방문한 후에 visitLineNumber 메소드를 호출해야합니다. 실제로이 라벨 바로 다음에 호출되므로 메서드 호출자에서 현재 명령의 소스 행을 쉽게 알 수 있습니다

public class MyAdapter extends MethodVisitor {

int currentLine;

public MyAdapter(MethodVisitor mv) {

super(ASM4, mv);

}

@Override

public void visitLineNumber(int line, Label start) {

mv.visitLineNumber(line, start);

currentLine = line;

}

...

}

마찬가지로 인수로 전달 된 레이블을 방문한 후에 visitLocalVariable 메소드를 호출해야합니다. 이전 섹션에서 제시된 쌍 및 튜플에 해당하는 예제 메서드 호출은 다음과 같습니다.

visitLineNumber(n1, l1);

visitLineNumber(n2, l2);

visitLineNumber(n3, l3);

visitLocalVariable("i", "I", null, l1, l2, 1);

visitLocalVariable("j", "I", null, l2, l3, 1);

visitLocalVariable("i", "I", null, l3, end, 1);

Ignoring debug information

줄 번호와 지역 변수 이름을 방문하기 위해 ClassReader 클래스는 점프 지침에서는 필요하지 않지만 디버그 정보 만 나타낼 수 있다는 의미에서 "인공"Label 객체를 도입해야 할 수도 있습니다. 3.2.5 절에서 설명 된 것과 같이 명령 시퀀스 중간의 레이블이 점프 대상으로 간주되어이 시퀀스가 제거되지 않도록하는 상황에서 오탐 (false positive)이 발생할 수 있습니다.

이러한 잘못된 긍정을 피하기 위해 ClassReader.accept 메서드에서 SKIP_DEBUG 옵션을 사용할 수 있습니다. 이 옵션을 사용하면 클래스 판독기가 디버그 정보를 방문하지 않고 인공 지능 레이블을 생성하지 않습니다. 물론 디버그 정보는 클래스에서 제거되므로이 옵션은 응용 프로그램에 문제가되지 않는 경우에만 사용할 수 있습니다.

참고 : ClassReader 클래스는 컴파일 된 코드 (클래스 구조 만 있으면 유용 할 수 있음), 스택 맵 프레임을 건너 뛰는 SKIP_FRAMES 및 이러한 프레임의 압축을 해제하는 EXPAND_FRAMES의 방문을 건너 뛰는 SKIP_CODE와 같은 다른 옵션을 제공합니다.

4.3.3. Tools

제네릭 형식 및 annotation과 마찬가지로 TraceClassVisitor, CheckClassAdapter 및 ASMifier 클래스를 사용하여 디버그 정보로 작업하는 방법을 찾을 수 있습니다.

ASM User Guide 번역 3

yimoc — Tue, 11 Sep 2018 16:04:48 +0900

3. Methods

이 장에서는 core ASM API를 사용하여 컴파일 된 메소드를 생성하고 변환하는 방법을 설명합니다. 그것은 컴파일 된 메소드의 표현으로 시작하여 많은 예제를 사용하여 해당하는 ASM 인터페이스, 컴포넌트 및 툴을 생성하고 변환하는 도구를 제공합니다.

3.1. Structure

컴파일 된 클래스 내에서 메소드 코드는 바이트 코드 명령어의 시퀀스로 저장됩니다. 클래스를 생성하고 변환하기 위해 이들 지침을 알고 그들이 어떻게 작동하는지 이해하는 것이 필수적입니다. 이 섹션에서는 간단한 클래스 생성기 및 변환기의 코딩을 시작하기에 충분해야하는 지침의 개요를 제공합니다. 전체 정의를 보려면 Java Virtual Machine Specification을 읽어야합니다.

3.1.1. Execution model

바이트 코드 명령을 제시하기 전에 Java Virtual Machine 실행 모델을 제시합니다. 아시다시피 Java 코드는 스레드 내에서 실행됩니다.

각 스레드는 프레임으로 구성된 자체 실행 스택을 가지고 있습니다. 각 프레임은 메소드 호출을 나타냅니다. 메소드가 호출 될 때마다 현재 스레드의 실행 스택에 새로운 프레임이 푸시됩니다. 메서드가 정상적으로 또는 예외로 인해 반환되면이 프레임이 실행 스택에서 pop되고 호출 메서드에서 실행이 계속됩니다 (이제 프레임이 스택 맨 위에 있음).

각 프레임은 로컬 변수 부분과 피연산자(Operand) 스택 부분의 두 부분으로 구성됩니다. 지역 변수 부분에는 인덱스로 임의의 순서로 액세스 할 수있는 변수가 들어 있습니다. 피연산자 스택 부분은 이름에서 알 수 있듯이 바이트 코드 명령어에 의해 피연산자로 사용되는 값들의 스택입니다. 즉,이 스택의 값은 선입 선출 (Last In First Out) 순서로만 액세스 할 수 있습니다. 피연산자 스택과 스레드의 실행 스택을 혼동하지 마십시오. 실행 스택의 각 프레임에는 자체 피연산자 스택이 있습니다.

로컬 변수와 피연산자 스택 부분의 크기는 메서드의 코드에 따라 다릅니다. 컴파일시에 계산되어 컴파일 된 클래스의 바이트 코드 명령어와 함께 저장됩니다. 결과적으로, 주어진 메소드의 호출에 대응하는 모든 프레임은 같은 크기를 갖지만, 다른 메소드에 대응하는 프레임은 로컬 변수와 피연산자 스택 부분에 대해 다른 크기를 가질 수 있습니다.

Figure 2.1 : An execution stack with 3 frames

그림 3.1은 3 프레임을 가진 샘플 실행 스택을 보여줍니다. 첫 번째 프레임은 3 개의 로컬 변수를 포함하고, 피연산자 스택의 최대 크기는 4이며 두 개의 값을 포함합니다. 두 번째 프레임은 2 개의 로컬 변수와 피연산자 스택에 두 개의 값을 포함합니다. 마지막으로 실행 스택 맨 위에있는 세 번째 프레임에는 4 개의 로컬 변수와 두 개의 피연산자가 들어 있습니다.

프레임이 생성되면 프레임은 빈 스택으로 초기화되고 해당 로컬 변수는 대상 객체로 this (비 정적 메서드의 경우) 및 메서드의 인수로 초기화됩니다. 예를 들어, a.equals (b) 메서드를 호출하면 스택이 비어 있고 처음 두 개의 로컬 변수가 a 및 b (다른 로컬 변수는 초기화되지 않음)로 초기화 된 프레임이 만들어집니다.

로컬 변수와 피연산자 스택 부분의 각 슬롯은 long 값과 double 값을 제외한 모든 Java 값을 포함 할 수 있습니다. 이 값에는 두 개의 슬롯이 필요합니다. 이것은 로컬 변수의 관리를 복잡하게합니다. 예를 들어 i 번째 메소드 인수가 반드시 로컬 변수 i에 저장되는 것은 아닙니다. 예를 들어, Math.max (1L, 2L)를 호출하면 첫 번째 두 개의 로컬 변수 슬롯에 1L 값을 가진 프레임이 만들어지고 세 번째와 네 번째 슬롯에 2L 값이있는 프레임이 만들어집니다

3.1.2. Bytecode instructions

바이트 코드 명령어는이 명령어를 식별하는 opcode와 고정 된 수의 argument로 구성됩니다.

• opcode는 부호없는 바이트 값이며 따라서 바이트 코드 이름이며 니모닉(기억하기 쉬운) 기호로 식별됩니다. 예를 들어 opcode 값 0은 니모닉 기호 NOP에 의해 설계되며 아무 것도 수행하지 않는 명령에 해당합니다.

• 인수는 정확한 명령어 동작을 정의하는 정적 값입니다.

그들은 opcode 바로 다음에 주어집니다. 예를 들어 opcode 값이 167 인 GOTO 레이블 명령어는 실행될 다음 명령어를 지정하는 레이블 인 인수 레이블을 취합니다. 명령어 인수는 명령어 피연산자와 혼동되어서는 안됩니다. 인수 값은 정적으로 알려져 컴파일 된 코드에 저장되는 반면, 피연산자 값은 피연산자 스택에서 가져온 것이며 런타임에만 인식됩니다.

바이트 코드 명령어는 두 가지 카테고리로 나누어 질 수 있습니다 : 로컬 변수에서 피연산자 스택으로 값을 전송하도록 작은 명령어 세트가 설계되었습니다. 다른 명령어는 피연산자 스택에서만 작동합니다. 즉, 스택에서 일부 값을 팝핑하고 이러한 값을 기반으로 결과를 계산 한 다음 다시 스택에 푸시합니다.

ILOAD, LLOAD, FLOAD, DLOAD 및 ALOAD 명령어는 로컬 변수를 읽고 해당 값을 피연산자 스택에 푸시합니다. 그들은 읽어야 만하는 로컬 변수의 인덱스 i를 인수로 취합니다. ILOAD는 boolean, byte, char, short 또는 int 로컬 변수를 로드하는 데 사용됩니다. LLOAD, FLOAD 및 DLOAD는 각각 long, float 또는 double 값을 로드하는 데 사용됩니다 (LLOAD 및 DLOAD는 실제로 두 개의 슬롯 i 및 i + 1을 로드합니다). 마지막으로 ALOAD는 non primitive 값, 즉 객체 및 배열 참조를 로드하는 데 사용됩니다. 대칭적으로 ISTORE, LSTORE, FSTORE, DSTORE 및 ASTORE 명령어는 피연산자 스택에서 값을 pop하고 해당 인덱스 i로 지정된 로컬 변수에 저장합니다.

보시다시피 xLOAD 및 xSTORE 명령어가 입력됩니다 (실제로는 아래에서 볼 수 있듯이 거의 모든 명령어가 입력됩니다). 이것은 불법적인 변환이 수행되지 않도록하기 위해 사용됩니다. 실제로 지역 변수에 값을 저장 한 다음 다른 type으로 값을 로드하는 것은 불법입니다. 예를 들어, ISTORE 1 ALOAD 1 시퀀스는 불법입니다 - 이것은 임의의 메모리 주소를 로컬 변수 1에 저장하고이 주소를 객체 참조로 변환하는 것을 허용합니다! 그러나, 이 로컬 변수에 저장된 현재 값의 type과 다른 type의 값을 로컬 변수에 저장하는 것이 가장 합당합니다. 이것은 로컬 변수의 type, 즉 이 로컬 변수에 저장된 값의 type이 메소드의 실행 중에 변경 될 수 있음을 의미합니다.

위에서 말한 것처럼 다른 모든 바이트 코드 명령어는 피연산자 스택에서만 작동합니다.

다음 범주로 그룹화 할 수 있습니다 (부록 A.1 참조).

Stack

이 명령어는 스택에서 값을 조작하는 데 사용됩니다.

POP는 스택 맨 위에 pop을 팝하고, DUP는 맨 위 스택 값의 복사본을 push하고, SWAP는 두 값을 pop하고 역순으로 push합니다.

Constants

이 명령어는 피연산자 스택에 상수 값을 푸시합니다.

ACONST_NULL은 null을 푸시합니다. ICONST_0은 int 값 0을, FCONST_0은 0f를, DCONST_0은 0d를, BIPUSH는 b를, SIPUSH는 short 값을, LDC cst는 임의의 int, float, long, double, String 또는 class constant cst, 등등을 push한다.

Arithmetic and logic

이 명령어는 피연산자 스택에서 숫자 값을 가져 와서 결합하여 결과를 스택에 푸시합니다. 그들에게는 어떤 arguemnt도 없다. xADD, xSUB, xMUL, xDIV 및 xREM은 +, -, * 및 / 또는 % 연산에 해당하며 여기서 x는 I, L, F 또는 D입니다. 마찬가지로 int 및 long 값에 대해 << <,>>>,>>>, |, & 및 ^에 해당하는 다른 명령어가 있습니다.

Casts

이 명령어는 스택에서 값을 팝하고 다른 유형으로 변환 한 다음 결과를 다시 푸시합니다. 그것들은 Java의 캐스트 표현식에 해당합니다. I2F, F2D, L2D 등은 하나의 숫자 유형에서 다른 숫자 유형으로 숫자 값을 변환합니다. CHECKCAST t는 참조 값을 type t로 변환합니다.

Objects

이 명령어는 객체를 생성하고, 잠그고, type을 테스트하는 등의 작업에 사용됩니다. 예를 들어 NEW 유형의 명령어는 스택에 새로운 유형의 객체를 푸시합니다 (유형은 내부 이름 임).

Fields

이 명령어는 필드의 값을 읽거나 씁니다. GETFIELD owner name desc는 객체 참조를 팝하고 이름 필드의 값을 푸시합니다. PUTFIELD owner name desc는 값과 객체 참조를 팝하고이 값을 이름 필드에 저장합니다. 두 경우 모두 객체는 owner 유형이어야하며 필드의 형식은 desc 여야합니다. GETSTATIC 및 PUTSTATIC은 유사한 명령어이지만 정적 필드의 경우에 사용됩니다.

Methods

이 명령어는 메소드 또는 생성자를 호출합니다. 메서드 인수만큼의 값들과 대상 객체에 대한 값을 추가하여 pop하고, 메서드 호출의 결과를 푸시합니다. INVOKEVIRTUAL owner name desc는 owner 클래스에 정의 된 name 메소드를 호출하고 method descriptor가 desc 인 메소드를 호출합니다. INVOKESTATIC은 static메서드에 사용되며, INVOKESPECIAL에는 private 메서드와 생성자가 사용되고 INVOKEINTERFACE에는 인터페이스에 정의 된 메서드가 사용됩니다. 마지막으로 Java 7 클래스의 경우 INVOKEDYNAMIC이 새로운 동적 메서드 호출 메커니즘에 사용됩니다.

Arrays

이 명령어는 배열에서 값을 읽고 쓰는 데 사용됩니다. xALOAD 명령은 인덱스 및 배열을 팝하고 이 인덱스에서 배열 요소의 값을 푸시합니다. xASTORE 명령어는 값, 인덱스 및 배열을 pop하고이 값을 배열의 해당 인덱스에 저장합니다. 여기서 x는 I, L, F, D 또는 A뿐만 아니라 B, C 또는 S가 될 수 있습니다.

Jumps

이 명령어는 어떤 조건이 참이거나 무조건 조건이면 임의의 명령어로 점프합니다. 그것들은 if, for, do, while, break , continue명렴어를 컴파일하기 위해 사용된다. 예를 들어 IFEQ label 은 스택의 int 값을 팝하며 이 값이 0이면 label에 의해 설계된 명령으로 점프합니다 (그렇지 않으면 실행이 다음 명령으로 정상적으로 계속됩니다). IFNE 나 IFGE와 같은 다른 많은 점프 명령어가 존재합니다. 마지막으로 TABLESWITCH 및 LOOKUPSWITCH는 switch Java 명령어에 해당합니다.

Return

마지막으로 xRETURN 및 RETURN 명령어는 메소드의 실행을 종료하고 그 결과를 호출자에게 리턴하는 데 사용됩니다. RETURN은 void를 반환하는 메서드에 사용되고 xRETURN은 다른 메서드에 사용됩니다.

3.1.3. Examples Lets look at some basic examples to get a more concrete sense of how bytecode instructions work. Consider the following bean class:

package pkg;

public class Bean {

private int f;

public int getF() {

return this.f;

}

public void setF(int f) {

this.f = f;

}

The bytecode of the getter method is:

ALOAD 0

GETFIELD pkg/Bean f I

IRETURN

첫 번째 명령은 로컬변수 0를 읽습니다. 이 변수는 메서드 호출에 대한 프레임을 만드는 동안이 변수에 초기화되고 이 값을 피연산자 스택에 푸시합니다. 두 번째 명령은 스택에서 이 값을 팝합니다. 즉,이 객체의 f 필드 즉 this.f를 푸시합니다. 마지막 명령은 스택에서이 값을 팝하고 호출자에게 반환합니다. 이 방법에 대한 실행 프레임의 연속 상태가 그림 3.2에 나와 있습니다.

Figure 3.2.: Successive frame states for the getF method: a) initial state, b) after ALOAD 0 and c) after GETFIELD

The bytecode of the setter method is:

ALOAD 0

ILOAD 1

PUTFIELD pkg/Bean f I

RETURN

첫 번째 명령어는 이전과 마찬가지로 피연산자 스택에서 이를 푸시합니다.

두 번째 명령은이 메서드 호출을위한 프레임을 만드는 동안 f 인수 값으로 초기화 된 로컬 변수 1을 푸시합니다.

세 번째 명령은이 두 값을 팝하고 참조 된 객체의 f 필드에 int 값을 this.f로 저장합니다. 소스 코드에 내포되어 있지만 컴파일 된 코드에서 필수적인 마지막 명령은 현재 실행 프레임을 파괴하고 호출자에게 반환됩니다. 이 방법에 대한 실행 프레임의 연속 상태가 그림 3.3에 나와 있습니다.

Figure 3.3.: Successive frame states for the setF method: a) initial state, b) after ALOAD 0, c) after ILOAD 1 and d) after PUTFIELD

Bean 클래스에는 프로그래머가 명시 적 생성자를 정의하지 않았기 때문에 컴파일러에 의해 생성되는 기본 public 생성자가 있습니다. 이 기본 공용 생성자는 Bean () {super (); }. 이 생성자의 바이트 코드는 다음과 같습니다.

INVOKESPECIAL java/lang/Object <init> ()V

RETURN

첫 번째 명령어는 이것을 피연산자 스택에 푸시합니다. 두 번째 명령은 스택에서 이 값을 팝하고 Object 클래스에 정의 된 <init> 메서드를 호출합니다. super () 호출, 즉 수퍼 클래스 인 Object의 생성자에 대한 호출에 해당합니다. 생성자는 컴파일 된 클래스와 소스 클래스에서 이름이 다르게 표시됩니다. 컴파일 된 클래스에서는 항상 <init>으로 명명되지만 소스 클래스에서는 정의 된 클래스의 이름을 갖습니다. 마지막으로 마지막 명령이 호출자에게 반환됩니다.

이제 좀 더 복잡한 setter 메서드를 살펴 보겠습니다.

public void checkAndSetF(int f) {

if (f >= 0) {

this.f = f;

} else {

throw new IllegalArgumentException();

}

The bytecode for this new setter method is the following:

ILOAD 1

IFLT label

ALOAD 0

ILOAD 1

PUTFIELD pkg/Bean f I

GOTO end

label:

NEW java/lang/IllegalArgumentException

DUP

INVOKESPECIAL java/lang/IllegalArgumentException <init> ()V

ATHROW

end:

RETURN

첫 번째 명령은 피연산자 스택에서 f로 초기화 된 로컬 변수 1을 푸시합니다. IFLT 명령어는 스택에서 이 값을 가져와 0과 비교합니다. LT (Less Than) 0이면 레이블 레이블에 지정된 명령어로 점프합니다. 그렇지 않으면 아무 것도 수행하지 않고 실행이 다음 명령어로 계속 진행됩니다. 다음 세 명령어는 setF 메소드에서와 같은 명령어이다. GOTO 명령어는 RETURN 명령어 인 끝 레이블로 지정된 명령어로 무조건 점프합니다. 레이블과 끝 레이블 사이의 명령어는 예외를 만들고 생성합니다. NEW 명령어는 예외 객체를 만들고이를 피연산자 스택에 푸시합니다. DUP 명령은이 값을 스택에 복제합니다. INVOKESPECIAL 명령어는이 두 복사본 중 하나를 팝하고 예외 생성자를 호출합니다. 마지막으로 ATHROW 명령은 나머지 복사본을 팝하고 예외로 throw합니다 (실행이 다음 명령으로 이어지지 않도록).

3.1.4. Exception handlers

예외를 잡는 바이트 코드 명령어가 없습니다. 대신 메소드의 바이트 코드는 메소드의 주어진 부분에서 예외가 발생할 때 실행되어야 하는 코드를 지정하는 예외 핸들러 목록과 연관됩니다. 예외 핸들러는 try catch 블록과 유사합니다. 범위에는 try 블록의 내용에 해당하는 명령어 시퀀스와 catch 블록의 내용에 해당하는 핸들러가 있습니다. 범위는 시작 및 끝 레이블로 지정되고 처리기는 시작 레이블로 지정됩니다. 아래 소스 코드 예를 들면 :

public static void sleep(long d) {

try {

Thread.sleep(d);

} catch (InterruptedException e) {

e.printStackTrace();

}

can be compiled into:

TRYCATCHBLOCK try catch catch java/lang/InterruptedException

try:

LLOAD 0

INVOKESTATIC java/lang/Thread sleep (J)V

RETURN

catch:

INVOKEVIRTUAL java/lang/InterruptedException printStackTrace ()V

RETURN

try 및 catch 레이블 사이의 코드는 try 블록에 해당하고 catch 레이블 뒤의 코드는 catch 블록에 해당합니다. TRYCATCHBLOCK 행은 try 와 catch 레이블 사이의 범위를 처리하는 예외 핸들러를 지정하며, catch 레이블에서 시작하는 핸들러는 InterruptedException의 서브 클래스 인 예외에 대해 지정합니다. 즉, try와 catch 사이에 이러한 예외가 발생하면 스택이 지워지고 예외가이 빈 스택에 푸시되고 catch에서 실행이 계속됨을 의미합니다.

3.1.5. Frames

Java 6 이상으로 컴파일 된 클래스에는 바이트 코드 명령어 외에도 Java Virtual Machine 내부의 클래스 검증 프로세스를 가속화하는 데 사용되는 stack map frames의 set가 포함되어 있습니다. stack map frame은 실행 중 어느 시점에서 메소드의 실행 프레임 상태를 제공합니다. 좀 더 정확히 말하면, 특정 바이트 코드 명령어가 실행되기 직전에 특정 로컬 변수 슬롯과 각 피연산자 스택 슬롯에 포함 된 값의 type을 제공합니다.

예를 들어, 이전 섹션의 getF 메소드를 살펴보면 실행 프레임의 상태를 ALOAD 직전, GETFIELD 직전, IRETURN 직전에 제공하는 세 개의 stack map frame을 정의 할 수 있습니다. 이 세 개의 stack map frames은 Figure 3.2의 세 가지 경우에 해당하며 첫 번째 대괄호 사이의 유형이 로컬 변수에 해당하고 다른 유형은 피연산자 스택에 해당하는 경우 다음과 같이 설명 할 수 있습니다.

State of the execution frame before	Instruction
[pkg/Bean] []	ALOAD 0
[pkg/Bean] [pkg/Bean]	GETFIELD
[pkg/Bean] [I]	IRETURN

checkAndSetF 메소드에 대해서도 동일한 작업을 수행 할 수 있습니다.

State of the execution frame before	Instruction
[pkg/Bean I] []	ILOAD 1
[pkg/Bean I] [I]	IFLT label
[pkg/Bean I] []	ALOAD 0
[pkg/Bean I] [pkg/Bean]	ILOAD 1
[pkg/Bean I] [pkg/Bean I]	PUTFIELD
[pkg/Bean I] []	GOTO end
[pkg/Bean I] []	label :
[pkg/Bean I] []	NEW
[pkg/Bean I] [Uninitialized(label)]	DUP
[pkg/Bean I] [Uninitialized(label) Uninitialized(label)]	INVOKESPECIAL
[pkg/Bean I] [java/lang/IllegalArgumentException]	ATHROW
[pkg/Bean I] []	end :
[pkg/Bean I] []	RETURN

이는 초기화되지 않은 (레이블) 유형을 제외하고 이전 메서드과 유사합니다. 이것은 stack map frame에서만 사용되며 메모리가 할당되었지만 아직 생성자가 호출되지 않은 객체를 지정하는 특수 유형입니다. 인수는 이 객체를 생성 한 명령어를 지정합니다. 이 유형의 값에서 호출 할 수있는 유일한 방법은 생성자입니다. 호출 될 때 프레임의이 유형이 모두 실제 유형 여기서는 IllegalArgumentException)으로 바뀝니다. 스택 맵 프레임은 다음과 같은 세 가지 특수 유형을 사용할 수 있습니다. UNINITIALIZED_THIS는 생성자의 로컬 변수 0의 초기 유형이고 TOP은 정의되지 않은 값에 해당하며 NULL은 null에 해당합니다.

위에서 말했듯이, Java 6부터 컴파일 된 클래스에는 bytecode, stack map frames의 set를 포함하고 있다. 저장공간을 절약하기 위해 컴파일 된 메소드에는 명령어 당 하나의 프레임이 포함되지는 않습니다. 실제로는 jump 대상이나 예외 핸들러에 해당하거나 무조건 점프 명령어를 따르는 명령어 프레임 만 포함합니다. 실제로 다른 프레임은 이 프레임에서 쉽고 빠르게 추론 할 수 있습니다. checkAndSetF 메소드의 경우 이는 두 개의 프레임 만 저장된다는 것을 의미합니다. 하나는 NEW 명령, IFLT 명령의 대상이며 또한 무조건 점프 GOTO 명령을 따르기 때문이며, 하나는 RETURN 명령인데 이는 GOTO 명령의 대상며 또한 "무조건 점프"ATHROW 명령을 따르기 때문입니다.

더 많은 공간을 절약하기 위해, 각 프레임은 이전 프레임과 비교 된 그 차이만을 저장함으로써 압축되고,초기 프레임은 메소드 매개 변수 유형에서 쉽게 추론 할 수 있기 때문에 전혀 저장되지 않습니다. checkAndSetF 메소드의 경우, 저장되어야하는 두 개의 프레임은 동일하고 초기 프레임과 동일하므로 F_SAME 니모닉에 의해 지정된 단일 바이트 값으로 저장됩니다. 이러한 프레임은 관련 바이트 코드 명령어 바로 직전에 나타낼 수 있습니다. checkAndSetF 메소드에 대한 최종 바이트 코드를 제공합니다.:

ILOAD 1

IFLT label

ALOAD 0

ILOAD 1

PUTFIELD pkg/Bean f I

GOTO end

label:

F_SAME

NEW java/lang/IllegalArgumentException

DUP

INVOKESPECIAL java/lang/IllegalArgumentException <init> ()V

ATHROW

end:

F_SAME

RETURN

※참고할 내용

https://stackoverflow.com/questions/25109942/is-there-a-better-explanation-of-stack-map-frames

3.2. Interfaces and components

3.2.1. Presentation

컴파일 된 메소드를 생성하고 변환하는 ASM API는 MethodVisitor 추상 클래스 (그림 3.4 참조)에 기반한다. 이것은 ClassVisitor의 visitMethod 메소드에 의해 리턴됩니다. 어노테이션 및 디버그 정보와 관련된 일부 메소드 외에도,

다음 장에서 설명 할 이 클래스는 바이트 코드 명령어 카테고리 당 하나의 메소드를 정의하며, 그 명령어들의 인자의 수와 유형를 기준으로 합니다. (이러한 카테고리는 섹션 3.1.2에 제시된 클래스와 일치하지 않습니다) .이러한 메서드는 다음 순서로 호출해야합니다.

(MethodVisitor 인터페이스의 Javadoc에 지정된 몇 가지 추가 제약 조건이 있음).

visitAnnotationDefault?

( visitAnnotation | visitParameterAnnotation | visitAttribute )*

( visitCode

visitMaxs )?

visitEnd

즉, annotaion과 attribute가 있는 경우 먼저 visit해야 하며, 이어서 non abstract method메소드의 바이트 코드가 와야합니다.

이들 메소드의 코드는 정확하게 한번만 visitCode 호출하고 visitMaxs를 한번만 호출하는 순차적인 순서로 visit해야한다.

abstract class MethodVisitor { // public accessors ommited

MethodVisitor(int api);

MethodVisitor(int api, MethodVisitor mv);

AnnotationVisitor visitAnnotationDefault();

AnnotationVisitor visitAnnotation(String desc, boolean visible);

AnnotationVisitor visitParameterAnnotation(int parameter, String desc, boolean visible);

void visitAttribute(Attribute attr);

void visitCode();

void visitFrame(int type, int nLocal, Object[] local, int nStack, Object[] stack);

void visitInsn(int opcode);

void visitIntInsn(int opcode, int operand);

void visitVarInsn(int opcode, int var);

void visitTypeInsn(int opcode, String desc);

void visitFieldInsn(int opc, String owner, String name, String desc);

void visitMethodInsn(int opc, String owner, String name, String desc);

void visitInvokeDynamicInsn(String name, String desc, Handle bsm, Object... bsmArgs);

void visitJumpInsn(int opcode, Label label);

void visitLabel(Label label);

void visitLdcInsn(Object cst);

void visitIincInsn(int var, int increment);

void visitTableSwitchInsn(int min, int max, Label dflt, Label[] labels);

void visitLookupSwitchInsn(Label dflt, int[] keys, Label[] labels);

void visitMultiANewArrayInsn(String desc, int dims);

void visitTryCatchBlock(Label start, Label end, Label handler, String type);

void visitLocalVariable(String name, String desc, String signature, Label start, Label end, int index);

void visitLineNumber(int line, Label start);

void visitMaxs(int maxStack, int maxLocals);

void visitEnd();

}

Figure 3.4.: The MethodVisitor class

따라서 visitCode 및 visitMaxs 메서드를 사용하여 이벤트 시퀀스에서 메서드의 바이트 코드 시작 및 끝을 검색 할 수 있습니다.

클래스와 마찬가지로 visitEnd 메서드는 마지막에 호출되어야하며 이벤트 시퀀스에서 메서드의 끝을 감지하는 데 사용됩니다.

완전한 클래스를 생성하기 위해서, ClassVisitor 클래스와 MethodVisitor 클래스를 조합 할 수 있습니다.

ClassVisitor cv = ...;

cv.visit(...);

MethodVisitor mv1 = cv.visitMethod(..., "m1", ...);

mv1.visitCode();

mv1.visitInsn(...);

...

mv1.visitMaxs(...);

mv1.visitEnd();

MethodVisitor mv2 = cv.visitMethod(..., "m2", ...);

mv2.visitCode();

mv2.visitInsn(...);

...

mv2.visitMaxs(...);

mv2.visitEnd();

cv.visitEnd();

또 다른 visit하기 시작하기 위해 꼭 메소드를 마칠 필요는 없습니다. 사실 MethodVisitor 인스턴스는 완전히 독립적이며 어떤 순서로든 사용할 수 있습니다 (cv.visitEnd ()가 호출되지 않은 한).

ClassVisitor cv = ...;

cv.visit(...);

MethodVisitor mv1 = cv.visitMethod(..., "m1", ...);

mv1.visitCode();

mv1.visitInsn(...);

...

MethodVisitor mv2 = cv.visitMethod(..., "m2", ...);

mv2.visitCode();

mv2.visitInsn(...);

...

mv1.visitMaxs(...);

mv1.visitEnd();

...

mv2.visitMaxs(...);

mv2.visitEnd();

cv.visitEnd();

ASM은 메소드를 생성하고 변환하는 MethodVisitor API를 기반으로 세 가지 핵심 컴포넌트를 제공합니다.

• ClassReader 클래스는 컴파일 된 메서드의 내용을 구문 분석하고 인수로 전달 된 ClassVisitor에 의해 반환 된 MethodVisitor 객체의 해당 메서드를 accept 메서드에 호출합니다.

• ClassWriter의 visitMethod 메소드는 컴파일 된 메소드를 직접 바이너리 형식으로 빌드하는 MethodVisitor 인터페이스의 구현을 반환합니다.

• MethodVisitor 클래스는 수신 한 모든 메소드 호출을 다른 MethodVisitor 인스턴스에 위임합니다. 이벤트 필터로 볼 수 있습니다.

ClassWriter options

3.1.5 절에서 보았 듯이, 메서드에 대한 스택 맵 프레임을 계산하는 것은 그리 쉽지 않습니다.

당신은 모든 프레임을 계산해야합니다 . 점프 대상에 해당하거나 무조건 점프를 따르는 프레임을 찾은 다음 마지막으로 나머지 프레임을 압축합니다. 마찬가지로 메소드의 로컬 변수와 피연산자 스택 부분의 크기를 계산하는 것이 더 쉽지만, 그 역시 그리 쉽지는 않습니다.

다행히도 ASM이이를 계산할 수 있습니다. ClassWriter를 만들 때 자동으로 계산해야하는 것을 지정할 수 있습니다.

• new ClassWriter (0)에서는 아무 것도 계산되지 않습니다. 프레임과 로컬 변수 및 피연산자 스택 크기를 직접 계산해야합니다.

• new ClassWriter (ClassWriter.COMPUTE_MAXS)를 사용하면 로컬 변수와 피연산자 스택 부분의 크기가 계산됩니다. 여전히 visitMaxs를 호출해야하지만 argument를 사용할 수 있습니다.이 인수는 무시되고 다시 계산됩니다. 이 옵션을 사용하면 여전히 프레임을 스스로 계산해야합니다.

• new ClassWriter (ClassWriter.COMPUTE_FRAMES)를 사용하면 모든 것이 자동으로 계산됩니다. visitFrame을 호출 할 필요는 없지만 visitMaxs를 호출해야합니다 (argument는 무시되고 다시 계산됩니다).

이러한 옵션을 사용하는 것이 편리하지만 비용이 많이 듭니다. COMPUTE_MAXS 옵션을 사용하면 ClassWriter가 10 % 더 늦어지며, COMPUTE_FRAMES 옵션을 사용하면 속도가 두 배 느려집니다. 이것은 자신이 계산하는데 걸리는 시간과 비교되어야합니다. 모든 경우를 처리해야하는 ASM에서 사용되는 알고리즘에 비해 특정 상황에서 종종 더 쉽고 빠르게 알고리즘으로 계산할 수 있습니다.

프레임을 직접 계산하도록 선택한 경우, ClassWriter 클래스가 압축 단계를 수행하도록 할 수 있습니다. 이를 위해서는 visitFrame (F_NEW, nLocals, locals, nStack, stack)을 사용하여 압축되지 않은 프레임을 visit하기 만하면 됩니다. 여기서 nLocals 및 nStack은 local 과 피연산자 스택 크기이며, local 및 stack은 해당 type이 들어있는 배열입니다 (자세한 내용은 Javadoc을 참조하십시오).

또한 프레임을 자동으로 계산하기 위해, 때때로 주어진 두 클래스의 공통 수퍼 클래스를 계산하는 데 필요합니다. 기본적으로 ClassWriter 클래스는 getCommonSuperClass 메소드에서 이를 계산하고, 두 클래스를 JVM에 로드하고 리플렉션 API를 사용합니다. 서로를 참조하는 여러 클래스를 참조 된 클래스가 아직 없기 때문에 생성하는 경우 문제가 될 수 있습니다. 이 경우 getCommonSuperClass 메소드를 override하여이 문제점을 해결할 수 있습니다.

3.2.2. Generating methods

3.1.3 절에 정의 된 getF 메소드의 바이트 코드는 mv가 MethodVisitor 인 경우 다음 메소드 호출을 사용하여 생성 할 수 있습니다.

mv.visitCode();

mv.visitVarInsn(ALOAD, 0);

mv.visitFieldInsn(GETFIELD, "pkg/Bean", "f", "I");

mv.visitInsn(IRETURN);

mv.visitMaxs(1, 1);

mv.visitEnd();

첫 번째 호출은 bytecode 생성을 시작합니다. 그 다음에는 이 메소드의 세 가지 명령어를 생성하는 세 번의 호출이 이어집니다 (bytecode와 ASM API 간의 매핑은 매우 간단합니다). visitMaxs는 모든 visit가 완료된 명령어가 수행되고 나서 호출해야 합니다. 이것은 메소드의 실행 프레임에 대한 로컬 변수 및 피연산자 스택 부분의 크기를 정의하는 데 사용됩니다. 3.1.3 절에서 보았 듯이 이 크기는 각 부분에 대해 1 슬롯입니다. 마지막으로 메소드의 생성을 끝내기 위해 마지막 호출이 사용됩니다.

setF 메소드와 생성자의 바이트 코드는 비슷한 방법으로 생성 될 수있다. 보다 흥미로운 예제는 checkAndSetF 메소드입니다.

mv.visitCode();

mv.visitVarInsn(ILOAD, 1);

Label label = new Label();

mv.visitJumpInsn(IFLT, label);

mv.visitVarInsn(ALOAD, 0);

mv.visitVarInsn(ILOAD, 1);

mv.visitFieldInsn(PUTFIELD, "pkg/Bean", "f", "I");

Label end = new Label();

mv.visitJumpInsn(GOTO, end);

mv.visitLabel(label);

mv.visitFrame(F_SAME, 0, null, 0, null);

mv.visitTypeInsn(NEW, "java/lang/IllegalArgumentException");

mv.visitInsn(DUP);

mv.visitMethodInsn(INVOKESPECIAL,

"java/lang/IllegalArgumentException", "<init>", "()V");

mv.visitInsn(ATHROW);

mv.visitLabel(end);

mv.visitFrame(F_SAME, 0, null, 0, null);

mv.visitInsn(RETURN);

mv.visitMaxs(2, 2);

mv.visitEnd();

visitCode 호출과 visitEnd 호출 사이에서 섹션 3.1.5의 끝에 표시된 바이트 코드와 정확하게 매핑되는 메서드 호출을 볼 수 있습니다.

명령, 레이블 또는 프레임 당 하나의 호출 (유일한 예외는 레이블 및 종료 레이블 객체의 선언 및 구성입니다).

참고 : Label 객체는이 레이블에 대한 visitLabel 호출 뒤에 오는 명령어를 지정합니다. 예를 들어, end는 지시가 아니기 때문에 RETURN 명령어를 지정하고 직후에 방문한 프레임은 지정하지 않습니다. 동일한 명령어를 지정하는 레이블이 여러 개있는 것은 당연한 일이지만 레이블은 정확히 하나의 명령어 만 지정해야합니다. 즉, 서로 다른 레이블로 visitLabel을 연속적으로 호출 할 수는 있지만 명령에 사용 된 레이블은 visitLabel을 사용하여 정확히 한 번만 방문해야합니다. 마지막 제약 조건은 라벨을 공유 할 수 없다는 것입니다. 각 메소드는 자체 라벨을 가져야합니다.

3.2.3. Transforming methods

이제 메서드도 클래스처럼 변형 될 수 있다고 추측 했어야합니다. 즉, 메서드 호출을 전달하는 메서드 어댑터를 사용하여 일부 수정을 통해 메서드 호출을 전달할 수 있습니다. 변경 인수는 개별 명령어를 변경하는 데 사용할 수 있으며 수신 된 호출을 전달하지 않고 명령어를 제거하고 수신 된 호출간에 호출을 삽입하면 새로운 명령어가 추가됩니다. MethodVisitor 클래스는 그러한 메소드 어댑터의 기본 구현을 제공합니다.이 어댑터는 수신 한 모든 메소드 호출을 전달하는 것 외에는 아무것도 수행하지 않습니다.

메소드 어댑터가 사용되는 방법을 이해하기 위해 메소드 내부에서 NOP 명령어를 제거하는 매우 간단한 어댑터를 고려해 봅시다. 아무 것도하지 않기 때문에 문제없이 제거 할 수 있습니다.

public class RemoveNopAdapter extends MethodVisitor {

public RemoveNopAdapter(MethodVisitor mv) {

super(ASM4, mv);

}

@Override

public void visitInsn(int opcode) {

if (opcode != NOP) {

mv.visitInsn(opcode);

}

This adapter can be used inside a class adapter as follows:

public class RemoveNopClassAdapter extends ClassVisitor {

public RemoveNopClassAdapter(ClassVisitor cv) {

super(ASM4, cv);

}

@Override

public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {

MethodVisitor mv;

mv = cv.visitMethod(access, name, desc, signature, exceptions);

if (mv != null) {

mv = new RemoveNopAdapter(mv);

}

return mv;

}

즉, 클래스 어댑터는 체인의 다음 class visitor가 반환 한 메서드 어댑터(method visitor를 캡슐화한)를 빌드하고 이 어댑터를 반환합니다. 그 효과는 클래스 어댑터 체인과 유사한 메소드 어댑터 체인의 생성입니다 (그림 3.5 참조).

Figure 3.5 : Sequence diagram for the RemoveNoAdapter

그러나 필수 사항은 아닙니다: 클래스 어댑터 체인과 유사하지 않은 메소드 어댑터 체인을 빌드하는 것이 완벽하게 가능합니다. 각 메소드는 다른 메소드 어댑터 체인을 가질 수 있습니다. 예를 들어, 클래스 어댑터는 생성자가 아닌 메소드에서만 NOP를 제거하도록 선택할 수 있습니다.

이 작업은 다음과 같이 수행 할 수 있습니다.

...

mv = cv.visitMethod(access, name, desc, signature, exceptions);

if (mv != null && !name.equals("<init>")) {

mv = new RemoveNopAdapter(mv);

}

...

이 경우 어댑터 체인은 생성자에 대해 더 짧습니다. 반대로, 생성자 용 어댑터 체인은 visitMethod 내부에 함께 연결된 여러 메소드 어댑터와 함께 더 길 수있었습니다. 메소드 어댑터 체인은 클래스 어댑터 체인과 다른 토폴로지를 가질 수도 있습니다. 예를 들어, 클래스 어댑터 체인은 선형 일 수 있지만, 메소드 어댑터 체인에 branch를 가집니다.

public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {

MethodVisitor mv1, mv2;

mv1 = cv.visitMethod(access, name, desc, signature, exceptions);

mv2 = cv.visitMethod(access, "_" + name, desc, signature, exceptions);

return new MultiMethodAdapter(mv1, mv2);

}

이제 메소드 어댑터의 사용과 클래스 어댑터내부에서 결합하는 방법을 살펴 보았습니다. 이제 RemoveNopAdapter보다 더 흥미로운 어댑터를 구현하는 방법을 살펴 보겠습니다.

3.2.4. Stateless transformations

프로그램의 각 클래스에서 소비 한 시간을 측정한다고 가정 해 봅시다.

각 클래스에 정적 타이머 필드를 추가해야하며 이 클래스의 각 메서드 실행 시간을이 타이머 필드에 추가해야합니다.

다시 말하면 우리는 C를 변환하려합니다.

public class C {

public void m() throws Exception {

Thread.sleep(100);

}

이걸로

public class C {

public static long timer;

public void m() throws Exception {

timer -= System.currentTimeMillis();

Thread.sleep(100);

timer += System.currentTimeMillis();

}

이것이 ASM에서 어떻게 구현 될 수 있는지에 대한 아이디어를 얻기 위해, 이 두 클래스를 컴파일하고이 두 버전 (기본 Textifier 백엔드 또는 ASMifier 백엔드)에서 TraceClassVisitor의 출력을 비교할 수 있습니다. 기본 백엔드에서는 다음과 같은 차이점이 있습니다 (굵게 표시).

GETSTATIC C.timer : J

INVOKESTATIC java/lang/System.currentTimeMillis()J

LSUB

PUTSTATIC C.timer : J

LDC 100

INVOKESTATIC java/lang/Thread.sleep(J)V

GETSTATIC C.timer : J

INVOKESTATIC java/lang/System.currentTimeMillis()J

LADD

PUTSTATIC C.timer : J

RETURN

MAXSTACK = 4

MAXLOCALS = 1

우리는 메서드의 시작 부분에 4 개의 명령와 리턴되는 명령어 앞에 4 개의 다른 명령어를 추가해야한다는 것을 알 수 있습니다. 또한 최대 operan stack 크기를 업데이트해야 합니다. 메소드 코드의 시작 부분은 visitCode 메소드를 사용하여 visit합니다. 따라서 메소드 어댑터에서 이 메소드를 대체하여 처음 네 명령어를 추가 할 수 있습니다.

public void visitCode() {

mv.visitCode();

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System", "currentTimeMillis", "()J");

mv.visitInsn(LSUB);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

여기서 소유자는 변형 될 클래스의 이름으로 설정되어야합니다.

이제 RETURN 이전에 네 가지 다른 명령어를 추가해야합니다. xRETURN 이전 또는 ATHROW 앞에는 메소드 실행을 종료하는 모든 명령어가 추가되어야합니다. 이 명령어에는 인수가 없으므로 visitInsn 메서드에서 방문합니다. 그런 다음 명령어을 추가하기 위해이 메소드를 override 할 수 있습니다.

public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System", "currentTimeMillis", "()J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

mv.visitInsn(opcode);

}

마지막으로 최대 피연산자 스택 크기를 업데이트해야합니다. 추가하는 명령어는 두 개의 long 값을 푸시하므로 피연산자 스택에 네 개의 슬롯이 필요합니다. 메소드의 시작 부분에서 피연산자 스택은 처음에 비어 있으므로 처음에 추가 된 4 개의 명령어에는 크기 4의 스택이 필요합니다. 또한 삽입 된 코드는 스택 상태를 변경되지 않은 상태로 유지한다는 것을 알고 있습니다 (밀어 넣을만큼 많은 값을 표시하기 때문에).

결과적으로, 원래 코드가 크기 s의 스택을 필요로한다면, 변환 된 메소드에 필요한 최대 스택 크기는 max (4, s)입니다.

불행하게도 우리는 return 명령어 앞에 네 개의 명령어를 추가합니다. 여기서는 이러한 명령어 바로 앞에있는 피연산자 스택의 크기를 알지 못합니다. 우리는 그것이 s보다 작거나 같다는 것을 압니다. 결과적으로 리턴 명령어 전에 추가 된 코드에는 s + 4까지의 크기의 피연산자 스택이 필요할 수 있다고 말할 수 있습니다.

이 최악의 시나리오는 실제로는 거의 발생하지 않습니다. 일반적인 컴파일러에서는 RETURN 앞에 피연산자 스택이 반환 값, 즉 최대 0, 1 또는 2의 크기를 포함합니다.그러나 가능한 모든 경우를 처리하기를 원한다면 최악의 시나리오 2를 사용해야합니다.visitMaxs 메서드를 다음과 같이 재정의해야합니다.

public void visitMaxs(int maxStack, int maxLocals) {

mv.visitMaxs(maxStack + 4, maxLocals);

}

물론 최대 스택 크기에 신경 쓰지 않고 COMPUTE_MAXS 옵션을 사용하여 최적의 값을 계산하고 최악의 값을 계산하지 않을 수도 있습니다.

그러나 이러한 단순한 변환의 경우 maxStack을 수동으로 업데이트하는 데 많은 비용이 들지 않습니다.

이제 흥미로운 질문은 :

스택 맵 프레임은? 원래의 코드는 프레임을 포함하지 않았으며, 변형 된 것도 포함하지 않았습니다. 그러나 이것은 우리가 예제로 사용한 특정 코드로 인한 것입니까? 프레임을 업데이트해야하는 경우가 있습니까?

대답은 '아니오'입니다.

1) 삽입 된 코드는 피연산자 스택을 변경하지 않고 남겨 둡니다.

2) 삽입 된 코드는 점프 명령을 포함하지 않으며

3) 원래 코드의 점프 명령 또는 더 형식적으로는 제어 흐름 그래프가 수정되지 않습니다.

이는 원래 프레임이 변경되지 않으며 삽입 된 코드에 대해 새 프레임을 저장해야하므로 압축 된 원래 프레임도 변경되지 않음을 의미합니다.

이제 모든 요소를 연관된 ClassVisitor 및 MethodVisitor 하위 클래스에 함께 넣을 수 있습니다.

public class AddTimerAdapter extends ClassVisitor {

private String owner;

private boolean isInterface;

public AddTimerAdapter(ClassVisitor cv) {

super(ASM4, cv);

}

@Override public void visit(int version, int access, String name,

String signature, String superName, String[] interfaces) {

cv.visit(version, access, name, signature, superName, interfaces);

owner = name;

isInterface = (access & ACC_INTERFACE) != 0;

}

@Override public MethodVisitor visitMethod(int access, String name,

String desc, String signature, String[] exceptions) {

MethodVisitor mv = cv.visitMethod(access, name, desc, signature,

exceptions);

if (!isInterface && mv != null && !name.equals("<init>")) {

mv = new AddTimerMethodAdapter(mv);

}

return mv;

}

@Override public void visitEnd() {

if (!isInterface) {

FieldVisitor fv = cv.visitField(ACC_PUBLIC + ACC_STATIC, "timer",

"J", null, null);

if (fv != null) {

fv.visitEnd();

}

cv.visitEnd();

}

class AddTimerMethodAdapter extends MethodVisitor {

public AddTimerMethodAdapter(MethodVisitor mv) {

super(ASM4, mv);

}

@Override public void visitCode() {

mv.visitCode();

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LSUB);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

@Override public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

mv.visitInsn(opcode);

}

@Override public void visitMaxs(int maxStack, int maxLocals) {

mv.visitMaxs(maxStack + 4, maxLocals);

}

클래스 어댑터는 메소드 어댑터 (생성자 제외)를 인스턴스화하는 데 사용되고, 타이머 필드를 추가하고 .메소드 어댑터에서 액세스 할 수있는 필드를 변환하여 이름을 저장합니다.

3.2.5. Statefull transformations

이전 섹션에서 보았던 변환은 지역적이며 현재 명령어 이전에 방문한 명령어에 의존하지 않습니다.

처음에 추가 된 코드는 항상 동일하며 항상 추가되며, 각 RETURN 명령 앞에 삽입 된 코드에 대해서도 마찬가지입니다.

이러한 변환을 상태 비 저장 변환이라고합니다. 구현하기는 간단하지만 가장 간단한 변환 만이 속성을 확인합니다.

보다 복잡한 변환을 위해서는 현재 상태 이전에 visit한 명령어에 대한 일부 상태를 기억해야합니다. 예를 들어 ICONST_0 IADD 시퀀스의 모든 발생을 제거하는 변환은 그의 빈 효과는 0을 더하는 것입니다.

IADD 명령을 방문하면 마지막으로 방문한 명령이 ICONST_0 인 경우에만 명령을 제거해야합니다.

이를 위해서는 메소드 어댑터 내부에 상태를 저장해야합니다. 이러한 이유로 이러한 변환을 상태 기반 변환이라고합니다.

이 예제에서 더 자세히 살펴 보겠습니다. ICONST_0을 방문하면 다음 명령어가 IADD 인 경우에만 ICONST_0을 제거해야합니다. 문제는 다음 명령어가 아직 알려지지 않았다는 것입니다. 해결 방법은이 결정을 다음 명령으로 연기하는 것입니다. IADD 인 경우 두 명령을 모두 제거하고 그렇지 않으면 ICONST_0 및 현재 명령을 내 보냅니다. 일부 명령 시퀀스를 제거하거나 대체하는 변환을 구현하려면, visitXxx Insn 메소드가 일반적인 visitInsn () 메소드를 호출하는 MethodVisitor 서브 클래스를 도입하는 것이 편리합니다.

public abstract class PatternMethodAdapter extends MethodVisitor {

protected final static int SEEN_NOTHING = 0;

protected int state;

public PatternMethodAdapter(int api, MethodVisitor mv) {

super(api, mv);

}

@Overrid public void visitInsn(int opcode) {

visitInsn();

mv.visitInsn(opcode);

}

@Override public void visitIntInsn(int opcode, int operand) {

visitInsn();

mv.visitIntInsn(opcode, operand);

}

...

protected abstract void visitInsn();

}

Then the above transformation can be implemented like this:

public class RemoveAddZeroAdapter extends PatternMethodAdapter {

private static int SEEN_ICONST_0 = 1;

public RemoveAddZeroAdapter(MethodVisitor mv) {

super(ASM4, mv);

}

@Override public void visitInsn(int opcode) {

if (state == SEEN_ICONST_0) {

if (opcode == IADD) {

state = SEEN_NOTHING;

return;

}

visitInsn();

if (opcode == ICONST_0) {

state = SEEN_ICONST_0;

return;

}

mv.visitInsn(opcode);

}

@Override protected void visitInsn() {

if (state == SEEN_ICONST_0) {

mv.visitInsn(ICONST_0);

}

state = SEEN_NOTHING;

}

visitInsn (int) 메서드는 먼저 시퀀스가 검색되었는지 테스트합니다.

이 경우 상태를 다시 초기화하고 즉시 반환하므로 시퀀스를 제거하는 효과가 있습니다.

다른 경우에는 일반적인 visitInsn 메소드를 호출합니다.이 메소드는 마지막으로 방문한 명령어 인 경우 ICONST_0을 내 보냅니다.

그리고, 현재의 명령이 ICONST_0이면, 이 명령에 대한 결정을 연기하기 위해 이 사실을 기억하고 반환합니다. 다른 모든 경우에는 현재 명령어가 다음 방문객에게 전달됩니다.

Labels and frames

이전 섹션에서 보았 듯이 레이블과 프레임은 연관된 지시문 바로 전에 방문합니다.

다른 말로하면 지시 사항과 동일한 시간에 방문하지만 지침 자체는 아닙니다. 이것은 명령 시퀀스를 감지하는 변환에 영향을 미치지 만 실제로이 영향은 장점입니다. 실제로 우리가 제거한 지침 중 하나가 점프 지침의 대상이라면 어떻게됩니까? 어떤 명령어가 ICONST_0으로 점프 할 수 있다면, 이는이 명령어를 지정하는 라벨이 있음을 의미합니다.

두 명령어를 제거한 후에이 레이블은 제거 된 IADD 다음에 오는 명령어를 지정합니다.

그것은 우리가 원하는 것입니다. 그러나 어떤 지시가 IADD로 점프 할 수 있다면,

우리는 명령 순서를 제거 할 수 없습니다 (이 점프 전에 0이 스택에 푸시되었음을 확신 할 수 없습니다). ICONST_0과 IADD 사이에는 쉽게 감지 할 수있는 레이블이 있어야합니다. 추론은 스택 맵 프레임에서도 동일합니다. 스택 맵 프레임이 두 명령어 사이에서 방문되면이를 제거 할 수 없습니다. 두 경우 모두 레이블 및 프레임을 패턴 일치 알고리즘의 지침으로 간주하여 처리 할 수 있습니다. PatternMethodAdapter에서이 작업을 수행 할 수 있습니다 (visitMaxs는 일반적인 visitInsn 메서드도 호출하므로 메서드의 끝 부분을 검색해야하는 시퀀스의 접두사로 처리하는 데 사용됩니다).

public abstract class PatternMethodAdapter extends MethodVisitor {

...

@Override public void visitFrame(int type, int nLocal, Object[] local,

int nStack, Object[] stack) {

visitInsn();

mv.visitFrame(type, nLocal, local, nStack, stack);

}

@Override public void visitLabel(Label label) {

visitInsn();

mv.visitLabel(label);

}

@Override public void visitMaxs(int maxStack, int maxLocals) {

visitInsn();

mv.visitMaxs(maxStack, maxLocals);

}

다음 장에서 보게 될 것처럼, 컴파일 된 메소드는 예를 들어 예외 스택 추적에 사용되는 소스 파일 행 번호에 대한 정보를 포함 할 수 있습니다. 이 정보는 visitLineNumber 메소드로 방문하며 지침과 동시에 호출됩니다. 그러나 명령 시퀀스의 중간에있는 행 번호의 존재는 이를 변환하거나 제거 할 가능성에 아무런 영향을 미치지 않습니다. 해결책은 패턴 일치 알고리즘에서 완전히 무시하는 것입니다

A more complex example

이전 예제는보다 복잡한 명령 시퀀스로 쉽게 일반화 할 수 있습니다.

예를 들어, 일반적으로 f = f와 같은 오타로 인해 자체 필드 할당을 제거하는 변환을 고려하십시오. 또는 바이트 코드에서 ALOAD 0 ALOAD 0 GETFIELD f PUTFIELD f.

이 변환을 구현하기 전에 상태 시스템이이 시퀀스를 인식하도록 설계하는 것이 바람직합니다 (그림 3.6 참조).

각 변환에는 조건 (현재 명령어의 값)과 작업 (굵게 표시된 명령어 시퀀스)이 표시됩니다. 예를 들어 현재 명령이 ALOAD 0이 아닌 경우 S1에서 S0 로의 전환이 발생합니다. 이 경우, 이 상태에 도달하기 위해 방문한 ALOAD 0이 방출됩니다. S2에서 자체로의 전이에 주의하십시오. 이것은 3 개 이상의 연속적인 ALOAD 0이 발견 될 때 발생합니다. 이 경우 두 개의 ALOAD 0을 방문한 상태에서 머물며 세 번째를 내 보냅니다. state machine이 발견되면 해당 메소드 어댑터 작성은 간단합니다 ((8 스위치 케이스는 다이어그램의 8 전환에 해당합니다).

Figure 3.6.: State machine for ALOAD 0 ALOAD 0 GETFIELD f PUTFIELD f

class RemoveGetFieldPutFieldAdapter extends PatternMethodAdapter {

private final static int SEEN_ALOAD_0 = 1;

private final static int SEEN_ALOAD_0ALOAD_0 = 2;

private final static int SEEN_ALOAD_0ALOAD_0GETFIELD = 3;

private String fieldOwner;

private String fieldName;

private String fieldDesc;

public RemoveGetFieldPutFieldAdapter(MethodVisitor mv) {

super(mv);

}

@Override

public void visitVarInsn(int opcode, int var) {

switch (state) {

case SEEN_NOTHING: // S0 -> S1

if (opcode == ALOAD && var == 0) {

state = SEEN_ALOAD_0;

return;

}

break;

case SEEN_ALOAD_0: // S1 -> S2

if (opcode == ALOAD && var == 0) {

state = SEEN_ALOAD_0ALOAD_0;

return;

}

break;

case SEEN_ALOAD_0ALOAD_0: // S2 -> S2

if (opcode == ALOAD && var == 0) {

mv.visitVarInsn(ALOAD, 0);

return;

}

break;

}

visitInsn();

mv.visitVarInsn(opcode, var);

}

@Override

public void visitFieldInsn(int opcode, String owner, String name, String desc) {

switch (state) {

case SEEN_ALOAD_0ALOAD_0: // S2 -> S3

if (opcode == GETFIELD) {

state = SEEN_ALOAD_0ALOAD_0GETFIELD;

fieldOwner = owner;

fieldName = name;

fieldDesc = desc;

return;

}

break;

case SEEN_ALOAD_0ALOAD_0GETFIELD: // S3 -> S0

if (opcode == PUTFIELD && name.equals(fieldName)) {

state = SEEN_NOTHING;

return;

}

break;

}

visitInsn();

mv.visitFieldInsn(opcode, owner, name, desc);

}

@Override protected void visitInsn() {

switch (state) {

case SEEN_ALOAD_0: // S1 -> S0

mv.visitVarInsn(ALOAD, 0);

break;

case SEEN_ALOAD_0ALOAD_0: // S2 -> S0

mv.visitVarInsn(ALOAD, 0);

break;

case SEEN_ALOAD_0ALOAD_0GETFIELD: // S3 -> S0

mv.visitVarInsn(ALOAD, 0);

mv.visitFieldInsn(GETFIELD, fieldOwner, fieldName, fieldDesc);

break;

}

state = SEEN_NOTHING;

}

섹션 3.2.4의 AddTimerAdapter 케이스와 같은 이유로, 이 섹션에 제시된 상태 기반 변환은 스택 맵 프레임을 변환 할 필요가 없습니다. 원래 프레임은 변환 후에도 유효합니다. 로컬 변수와 피연산자 스택 크기를 변환 할 필요조차 없습니다. 마지막으로 statefull 변환은 명령 시퀀스를 탐지하고 변환하는 변환에 국한되지 않음에 유의해야합니다. 다른 유형의 변형도 statefull입니다.

예를 들어, 다음 섹션에 제시된 메소드 어댑터의 경우입니다.

3.3. Tools

org.objectweb.asm.commons 패키지에는 사용자 정의 어댑터를 정의하는 데 유용한 미리 정의 된 메소드 어댑터가 포함되어 있습니다. 이 섹션에서는 세 가지를 제시하고 섹션 3.2.4의 AddTimerAdapter 예제와 함께 어떻게 사용할 수 있는지 보여줍니다. 또한 이전 장에서 본 도구를 사용하여 메서드 생성 또는 변형을 쉽게 수행 할 수있는 방법을 보여줍니다.

3.3.1. Basic tools

섹션 2.3에 제시된 도구는 메소드에도 사용할 수 있습니다.

Type

xLOAD, xADD 또는 xRETURN과 같은 많은 바이트 코드 명령어는 적용되는 type에 따라 다릅니다. Type 클래스는 getOpcode 메소드를 제공합니다.이 메소드는이 명령어에 대해 주어진 유형에 해당하는 opcode를 가져 오는 데 사용할 수 있습니다. 이 메서드는 int 형식의 opcode를 매개 변수로 사용하고 해당 형식의 opcode를 반환합니다. 예를 들어, t.getOpcode (IMUL)는 t가 Type.FLOAT_TYPE과 같으면 FMUL을 반환합니다.

TraceClassVisitor

이전 장에서 이미 제시한 이 클래스는 visit하는 클래스의 텍스트 표현을 인쇄하고, 그들의 방법의 텍스트 표현을 포함하여,이 장에서 사용 된 것과 매우 유사한 형태로 나타납니다. 따라서 변환 체인의 어느 지점에서 생성되거나 변환 된 메서드의 내용을 추적하는 데 사용할 수 있습니다.

예 :

java -classpath asm.jar:asm-util.jar \

org.objectweb.asm.util.TraceClassVisitor \

java.lang.Void

prints:

// class version 49.0 (49)

// access flags 49

public final class java/lang/Void {

// access flags 25

// signature Ljava/lang/Class<Ljava/lang/Void;>;

// declaration: java.lang.Class<java.lang.Void>

public final static Ljava/lang/Class; TYPE

// access flags 2

private <init>()V

ALOAD 0

INVOKESPECIAL java/lang/Object.<init> ()V

RETURN

MAXSTACK = 1

MAXLOCALS = 1

// access flags 8

static <clinit>()V

LDC "void"

INVOKESTATIC java/lang/Class.getPrimitiveClass (...)...

PUTSTATIC java/lang/Void.TYPE : Ljava/lang/Class;

RETURN

MAXSTACK = 1

MAXLOCALS = 0

}

이것은 정적 블록 static {...}을 생성하는 방법, 즉 <clinit> 메소드 (CLass INITializer의 경우)를 생성하는 방법을 보여줍니다.

체인의 모든 부분을 추적하는 대신 체인의 특정 지점에서 단일 메서드의 내용을 추적하려는 경우 TraceClassVisitor 대신 TraceMethodVisitor를 사용할 수 있습니다. (이 경우에는 백엔드를 명시 적으로 지정해야하며 여기서 Textifier를 사용합니다.)

public MethodVisitor visitMethod(int access, String name,String desc, String signature, String[] exceptions) {

MethodVisitor mv = cv.visitMethod(access, name, desc, signature,exceptions);

if (debug && mv != null && ...) { // if this method must be traced

Printer p = new Textifier(ASM4) {

@Override public void visitMethodEnd() {

print(aPrintWriter); // print it after it has been visited

}

};

mv = new TraceMethodVisitor(mv, p);

}

return new MyMethodAdapter(mv);

}

이 코드는 MyMethodAdapter로 변환 한 후 메서드를 인쇄합니다.

CheckClassAdapter

이 장은 이전 장에서 이미 제시되었지만,

ClassVisitor 메소드가 적절한 순서로 호출되고 유효한 인수로 호출되는지 확인하며 MethodVisitor 메소드에 대해서도 동일하게 수행합니다.

따라서 변환 체인의 어느 지점에서나 MethodVisitor API가 올바르게 사용되었는지 확인할 수 있습니다.

TraceMethodVisitor와 마찬가지로 CheckMethodAdapter 클래스를 사용하여 모든 클래스를 검사하는 대신 단일 메서드를 검사 할 수 있습니다.

public MethodVisitor visitMethod(int access, String name,String desc, String signature, String[] exceptions) {

MethodVisitor mv = cv.visitMethod(access, name, desc, signature, exceptions);

if (debug && mv != null && ...) { // if this method must be checked

mv = new CheckMethodAdapter(mv);

}

return new MyMethodAdapter(mv);

}

이 코드는 MyMethodAdapter가 MethodVisitor API를 올바르게 사용하는지 확인합니다. 그러나, 이 어댑터는 바이트 코드가 올바른지 확인하지 않습니다. 예를 들어 ISTORE 1 ALOAD 1이 유효하지 않음을 감지하지 못합니다. 실제로 CheckMethodAdapter (Javadoc 참조)의 다른 생성자를 사용하고 visitMaxs에 유효한 maxStack 및 maxLocals 인수를 제공하면 이러한 종류의 오류가 감지 될 수 있습니다.

ASMifier

이전 장에서 이미 설명한이 클래스는 메서드 내용과 함께 작동합니다. 이것은 ASM을 사용하여 컴파일 된 코드를 생성하는 방법을 알기 위해 사용할 수 있습니다. Java에서 해당 소스 코드를 작성하고 javac로 컴파일 한 다음 ASMifier를 사용하여이 클래스를 방문하십시오. 소스 코드에 해당하는 바이트 코드를 생성하는 ASM 코드가 생성됩니다.

3.3.2. AnalyzerAdapter

이 메소드 어댑터는 visitFrame에서 방문한 프레임을 기반으로 각 명령어 앞에 스택 맵 프레임을 계산합니다. 사실, 3.1.5 절에서 설명한 것처럼 visitFrame은 공간을 절약하기 위해 메소드의 일부 특정 지침보다 먼저 호출되기 때문에 "다른 프레임은이 프레임에서 쉽고 빠르게 추정 할 수 있습니다". 이것은 이 어댑터가하는 것입니다. 물론 사전 계산 된 스택 맵 프레임을 포함하는 클래스, 즉 Java 6 이상으로 컴파일 된 (또는 이전에 COMPUTE_FRAMES 옵션을 사용하여 ASM 어댑터가있는 Java 6으로 업그레이드 된) 경우에만 작동합니다.

AddTimerAdapter 예제의 경우이 어댑터를 사용하여 RETURN 명령어 바로 앞에있는 피연산자 스택의 크기를 가져올 수 있으므로 visitMax에서 maxStack에 대한 최적의 변환 값을 계산할 수 있습니다 (실제로이 방법은 실제로 권장되지 않습니다. 왜냐하면 COMPUTE_MAXS를 사용하는 것보다 훨씬 효율적이지 않기 때문입니다.)

class AddTimerMethodAdapter2 extends AnalyzerAdapter {

private int maxStack;

public AddTimerMethodAdapter2(String owner, int access, String name, String desc, MethodVisitor mv) {

super(ASM4, owner, access, name, desc, mv);

}

@Override

public void visitCode() {

super.visitCode();

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LSUB);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

maxStack = 4;

}

@Override

public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

maxStack = Math.max(maxStack, stack.size() + 4);

}

super.visitInsn(opcode);

}

@Override

public void visitMaxs(int maxStack, int maxLocals) {

super.visitMaxs(Math.max(this.maxStack, maxStack), maxLocals);

}

스택 필드는 AnalyzerAdapter 클래스에 정의되며,

피연산자 스택에 유형을 포함합니다. 보다 정확하게는 visitXxx Insn에서 오버라이드 된 메소드가 호출되기 전에,

이 목록에는이 명령어 바로 앞에있는 피연산자 스택의 상태가 포함됩니다. 스택 필드가 올바르게 업데이트되도록 오버라이드 된 메서드를 호출해야합니다 (따라서 원본 코드에서 mv 대신 super를 사용).

슈퍼 클래스의 메소드를 호출하여 새 명령어를 삽입 할 수도 있습니다.이 명령어의 프레임은 AnalyzerAdapter에 의해 계산됩니다. 또한이 어댑터는 계산 된 프레임을 기반으로 visitMaxs의 인수를 업데이트하므로 직접 업데이트하지 않아도됩니다.

class AddTimerMethodAdapter3 extends AnalyzerAdapter {

public AddTimerMethodAdapter3(String owner, int access, String name, String desc, MethodVisitor mv) {

super(ASM4, owner, access, name, desc, mv);

}

@Override

public void visitCode() {

super.visitCode();

super.visitFieldInsn(GETSTATIC, owner, "timer", "J");

super.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

super.visitInsn(LSUB);

super.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

@Override

public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

super.visitFieldInsn(GETSTATIC, owner, "timer", "J");

super.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

super.visitInsn(LADD);

super.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

super.visitInsn(opcode);

}

3.3.3. LocalVariablesSorter

이 메소드 어댑터는 메소드에서 사용 된 로컬 변수를이 메소드에 나타나는 순서대로 번호를 재 지정합니다.

예를 들어 두 개의 매개 변수가있는 메소드에서 인덱스가 3보다 크거나 같은 첫 번째 로컬 변수는 처음 세 개의 로컬 변수가 this와 두 개의 메소드 매개 변수에 해당하므로 변경할 수 없습니다 - 할당됩니다. 인덱스 3, 두 번째 인덱스 4 등이 할당됩니다.

이 어댑터는 메소드에 새 로컬 변수를 삽입 할 때 유용합니다. 이 어댑터가 없으면 기존의 모든 지역 변수 뒤에 새로운 지역 변수를 추가해야하지만, 아쉽게도 숫자가 visitMaxs의 메소드 끝까지 알려지지 않습니다.

이 어댑터를 사용하는 방법을 보여주기 위해 로컬 변수를 사용하여 AddTimerAdapter를 구현한다고 가정 해 봅니다.

public class C {

public static long timer;

public void m() throws Exception {

long t = System.currentTimeMillis();

Thread.sleep(100);

timer += System.currentTimeMillis() - t;

}

LocalVariablesSorter를 확장하고이 클래스에 정의 된 newLocal 메서드를 사용하면 쉽게 수행 할 수 있습니다.

class AddTimerMethodAdapter4 extends LocalVariablesSorter {

private int time;

public AddTimerMethodAdapter4(int access, String desc, MethodVisitor mv) {

super(ASM4, access, desc, mv);

}

@Override

public void visitCode() {

super.visitCode();

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

time = newLocal(Type.LONG_TYPE);

mv.visitVarInsn(LSTORE, time);

}

@Override

public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitVarInsn(LLOAD, time);

mv.visitInsn(LSUB);

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

super.visitInsn(opcode);

}

@Override

public void visitMaxs(int maxStack, int maxLocals) {

super.visitMaxs(maxStack + 4, maxLocals);

}

로컬 변수가 번호가 매겨지면 메소드에 연결된 원본 프레임이 유효하지 않게되고 새로운 로컬 변수가 삽입되면 fortiori가됩니다. 다행히도이 프레임을 처음부터 다시 계산하는 것을 피할 수 있습니다. 실제로 프레임을 추가하거나 제거해야하며 변형 된 메서드의 프레임을 가져 오려면 원래 프레임의 로컬 변수 내용을 재정렬하는 것으로 충분합니다. LocalVariablesSorter는 자동으로 처리합니다. 메소드 어댑터 중 하나에 대해 점진적 스택 맵 프레임 업데이트를 수행해야하는 경우이 클래스의 소스에서 영감을 얻을 수 있습니다.

위에서 볼 수 있듯이 로컬 변수를 사용한다고해서 maxStack에 대한 최악의 경우에 대한이 클래스의 원래 버전에서의 문제는 해결되지 않습니다. AnalyzerAdapter를 사용하여이를 해결하려면 LocalVariablesSorter 외에도 상속을 통해 위임하지 않고 위임을 통해 이러한 어댑터를 사용해야합니다. (다중 상속이 불가능하기 때문에) :

class AddTimerMethodAdapter5 extends MethodVisitor {

public LocalVariablesSorter lvs;

public AnalyzerAdapter aa;

private int time;

private int maxStack;

public AddTimerMethodAdapter5(MethodVisitor mv) {

super(ASM4, mv);

}

@Override

public void visitCode() {

mv.visitCode();

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

time = lvs.newLocal(Type.LONG_TYPE);

mv.visitVarInsn(LSTORE, time);

maxStack = 4;

}

@Override

public void visitInsn(int opcode) {

if ((opcode >= IRETURN && opcode <= RETURN) || opcode == ATHROW) {

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitVarInsn(LLOAD, time);

mv.visitInsn(LSUB);

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

maxStack = Math.max(aa.stack.size() + 4, maxStack);

}

mv.visitInsn(opcode);

}

@Override

public void visitMaxs(int maxStack, int maxLocals) {

mv.visitMaxs(Math.max(this.maxStack, maxStack), maxLocals);

}

이 어댑터를 사용하려면 LocalVariablesSorter를 어댑터에 연결해야하는 AnalyzerAdapter에 연결해야합니다. 첫 번째 어댑터는 로컬 변수를 정렬하고 이에 따라 프레임을 업데이트하며, 분석기 어댑터는 이전 어댑터에서 수행 된 번호 매김을 고려하여 중간 프레임을 계산합니다 어댑터는 이러한 번호가 다시 매겨진 중간 프레임에 액세스 할 수 있습니다. 이 체인은 visitMethod에서 다음과 같이 구성 할 수 있습니다.

mv = cv.visitMethod(access, name, desc, signature, exceptions);

if (!isInterface && mv != null && !name.equals("<init>")) {

AddTimerMethodAdapter5 at = new AddTimerMethodAdapter5(mv);

at.aa = new AnalyzerAdapter(owner, access, name, desc, at);

at.lvs = new LocalVariablesSorter(access, desc, at.aa);

return at.lvs;

}

3.3.4. AdviceAdapter

이 메소드 어댑터는 메소드 시작과 모든 RETURN 또는 ATHROW 명령어 바로 앞에 코드를 삽입하는 데 사용할 수있는 추상 클래스입니다.

주된 장점은 생성자의 처음에 코드를 삽입하지 말고 상위 생성자를 호출 한 후 생성자에 대해서도 작동한다는 것입니다. 사실이 어댑터의 대부분의 코드는이 수퍼 생성자 호출을 탐지하는 데 사용됩니다.

3.2.4 절의 AddTimerAdapter 클래스를 자세히 살펴보면,

이 문제 때문에 AddTimerMethodAdapter가 생성자에 사용되지 않는다는 것을 알 수 있습니다. AdviceAdapter를 상속하면이 메소드 어댑터가 생성자에서도 작동하도록 향상 될 수 있습니다 (AdviceAdapter는 LocalVariablesSorter에서 상속되므로 로컬 변수도 쉽게 사용할 수 있습니다).

class AddTimerMethodAdapter6 extends AdviceAdapter {

public AddTimerMethodAdapter6(int access, String name, String desc,

MethodVisitor mv) {

super(ASM4, mv, access, name, desc);

}

@Override

protected void onMethodEnter() {

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LSUB);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

@Override

protected void onMethodExit(int opcode) {

mv.visitFieldInsn(GETSTATIC, owner, "timer", "J");

mv.visitMethodInsn(INVOKESTATIC, "java/lang/System",

"currentTimeMillis", "()J");

mv.visitInsn(LADD);

mv.visitFieldInsn(PUTSTATIC, owner, "timer", "J");

}

@Override

public void visitMaxs(int maxStack, int maxLocals) {

super.visitMaxs(maxStack + 4, maxLocals);

}

ASM User Guide 번역 2

yimoc — Mon, 10 Sep 2018 17:30:56 +0900

2018/09/10 - [ASM] - ASM User Guide 번역 1

Part I.

Core API

2. Classes

이 장에서는 코어 ASM API를 사용하여 컴파일 된 Java 클래스를 생성하고 변환하는 방법을 설명합니다. 그것은 컴파일 된 클래스의 표현부터 시작하여 많은 예제를 사용하여 해당하는 ASM 인터페이스, 컴포넌트 및 툴을 생성 및 변환하는 도구를 제공합니다. 메소드, 주석 및 제네릭의 내용은 다음 장에서 설명합니다.

2.1. Structure

2.1.1. Overview

컴파일 된 클래스의 전체 구조는 아주 간단합니다. 실제로 컴파일 된 클래스는 기본적으로 컴파일 된 응용 프로그램과 달리 구조 정보와 소스 코드의 거의 모든 심볼을 유지합니다. 실제로 컴파일 된 클래스에는 다음이 포함됩니다.

• modifier (예 : public 또는 private), name, super class, interface 및 클래스의 annotation을 설명하는 section

• 클래스에서 선언 된 field 당 하나의 section. 각 섹션은 필드의 modifier , name , type 및 annotation을 설명합니다.

• 클래스에서 선언 된 메서드 및 생성자 당 하나의 section. 각 섹션은 modifier, name, return 및 parameter type 및 메소드의 annotation을 설명합니다. 또한 컴파일 된 코드를 포함하고 있으며 Java 바이트 코드 명령어의 시퀀스 형태로 구현됩니다.

그러나 소스 클래스와 컴파일 된 클래스에는 몇 가지 차이점이 있습니다.

• 컴파일 된 클래스는 하나의 클래스만 설명하지만 소스 파일에는 여러 클래스가 포함될 수 있습니다. 예를 들어, 내부 클래스가 하나 인 클래스를 설명하는 소스 파일은 메인 클래스 용과 내부 클래스 용의 두 클래스 파일로 컴파일됩니다. 그러나 메인 클래스 파일에는 내부 클래스에 대한 참조가 포함되어 있습니다. 클래스 및 메서드 내부에 정의 된 내부 클래스에는 메서드를 둘러싼 참조가 포함되어 있습니다.

• 컴파일 된 클래스에는 물론 주석이 포함되지 않습니다. 하지만 , 클래스, 필드, 메서드 및 코드 속성(attribute)를 포함합니다. 이것은 이러한 요소와 연관시키는 데 사용할 수있습니다. Java 5에서 주석을 도입 한 이후로 동일한 목적으로 사용될 수있는 속성은 거의 쓸모 없게 되었습니다.

• 컴파일 된 클래스에는 패키지 및 가져 오기 섹션이 없으므로 모든 Type의 이름은 fully Qualified합니다.

매우 중요한 또 다른 구조적 차이점은 컴파일 된 클래스가 상수 풀(Constant pool) 섹션을 포함한다는 것입니다. 이 풀은 클래스에 나타나는 모든 숫자, 문자열 및 type 상수를 포함하는 배열입니다. 이 상수는 상수 풀 섹션에서 한 번만 정의되며 클래스 파일의 다른 모든 섹션에서 해당 인덱스로 참조됩니다. ASM은 상수 풀과 관련된 모든 세부 사항을 숨기므로 바라기를 귀찮게 생각하지 않아도됩니다. 그림 2.1은 컴파일 된 클래스의 전체 구조를 요약 한 것입니다. 정확한 구조는 Java Virtual Machine Specification, 섹션 4에 설명되어 있습니다.

Modifiers, name, super class, interfaces
Constant pool: numeric, string and type constants
Source file name (optional)
Enclosing class reference
Annotation*
Attribute*
Inner class*	Name
Field*	Modifiers, name, type
	Annotation*
	Attribute*
Method*	Modifiers, name, return and parameter types
	Annotation*
	Attribute*
	Compiled code

Figure 2.1.: Overall structure of a compiled class (* means zero or more)

또 다른 중요한 차이점은 Java 유형은 컴파일 된 클래스와 소스 클래스에서 다르게 표현된다는 것입니다. 다음 섹션에서는 컴파일 된 클래스의 표현에 대해 설명합니다.

2.1.2. Internal names

많은 경우, Type은 클래스 또는 인터페이스 Type으로 제한됩니다. 예를 들어, 클래스의 수퍼 클래스, 클래스에 의해 구현 된 인터페이스 또는 메소드에 의해 던져지는 예외는 기본 유형이나 배열 유형 일 수 없으며 반드시 클래스 또는 인터페이스 Type입니다. 이러한 Type은 내부 이름이있는 컴파일 된 클래스로 표시됩니다. 클래스의 내부 이름은이 클래스의 fully qualified된 이름이며 점(.)이 슬래시(/)로 대체됩니다. 예를 들어 String의 내부 이름은 java / lang / String입니다.

2.1.3. Type descriptors

내부 이름은 클래스 또는 인터페이스 Type으로 제한되는 Type에만 사용됩니다. 필드 Type과 같은 다른 모든 상황에서는 Java Type은 type descriptor(see Figure 2.2)가있는 컴파일 된 클래스로 표시됩니다.

Java type	Type descriptor
boolean	Z
char	C
byte	B
short	S
int	I
float	F
long	J
double	D
Object	Ljava/lang/Object;
int[]	[I
Object[][]	[[Ljava/lang/Object;

Figure 2.2.: Type descriptors of some Java types

primitive type의 descriptor는 Single character로 표기됩니다: boolean 형의 경우는 Z, char의 경우는 C, byte 형의 경우는 B, int의 경우는 I, float의 경우는 F, long의 경우는 J, double의 경우는 D입니다. 클래스 타입의 기술자는이 클래스의 내부 이름이며 L이 앞에오고 세미콜론이 뒤 따른다. 예를 들어 String의 유형 설명자는 Ljava / lang / String입니다. 마지막으로 배열 타입의 기술자는 대괄호 뒤에 배열 원소 타입의 기술자가옵니다.

2.1.4. Method descriptors

Method descriptors는 Type descriptor의 List입니다. 하나의 Type Descriptor는 메소드의 parameter type과 return type을 단일 문자로 설명되어있습니다. Method descriptor는 왼쪽 괄호로 시작하여 각 형식 매개 변수의 type descriptor, 이어서 오른쪽 괄호, 그 다음에 반환 유형의 유형 설명자, 혹은 void를 반환하면 V로 시작합니다 (메소드 설명자에는 메소드의 이름 또는 인수 이름을 포함하지 않는다)

Method declaration in source file	Method descriptor
void m(int i, float f)	(IF)V
int m(Object o)	(Ljava/lang/Object;)I
int[] m(int i, String s)	(ILjava/lang/String;)[I
Object m(int[] i)	([I)Ljava/lang/Object;

Figure 2.3.: Sample method descriptors

타입 디스크립터가 어떻게 작동하는지 알게되면, 디스크립터를 이해하는 것이 쉽습니다. 예를 들어 (I)는 int 형의 하나의 인수를 취하고 int를 리턴하는 메소드를 설명합니다. Figure 2.3은 몇 가지 메소드 설명자 예제를 제공합니다.

2.2. Interfaces and components

2.2.1. Presentation

컴파일 된 클래스를 생성하고 변환하는 ASM API는 ClassVisitor 추상 클래스를 기반으로합니다 (Figure 2.4 참조). 이 클래스의 각 메소드는 같은 이름의 클래스 파일 구조 섹션에 해당합니다.(그림 2.1 참조). > visitSource() 가 Source 구조에 해당한다.

단순 섹션은 인수가 내용을 설명하고 void를 반환하는 단일 메소드 호출로 찾습니다.>visit으로 '방문하다'보단 '찾다'란 의미가 강하다. 다만 함수 이름이 visit임으로 이렇게 사용하는듯하다. 콘텐츠가 임의의 길이와 복잡성을 가질 수있는 섹션은 보조 visitor 클래스를 반환하는 초기 메서드 호출을 통해 찾습니다. visitAnnotation, visitField 및 visitMethod 메서드의 경우는 각각 AnnotationVisitor, FieldVisitor 및 MethodVisitor를 반환한다.

이 동일한 원칙이 보조 클래스에 대해 재귀적으로 사용됩니다. 예를 들어 FieldVisitor 추상 클래스 (그림 2.5 참조)의 각 메소드는 동일한 이름의 클래스 파일 하위 구조에 해당하며 visitAnnotation은 ClassVisitor 에서처럼 보조 AnnotationVisitor를 반환합니다.

public abstract class ClassVisitor {

public ClassVisitor(int api);

public ClassVisitor(int api, ClassVisitor cv);

public void visit(int version, int access, String name, String signature, String superName, String[] interfaces);

public void visitSource(String source, String debug);

public void visitOuterClass(String owner, String name, String desc);

AnnotationVisitor visitAnnotation(String desc, boolean visible);

public void visitAttribute(Attribute attr);

public void visitInnerClass(String name, String outerName, String innerName, int access);

public FieldVisitor visitField(int access, String name, String desc, String signature, Object value);

public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions);

void visitEnd();

}

Figure 2.4.: The ClassVisitor class

public abstract class FieldVisitor {

public FieldVisitor(int api);

public FieldVisitor(int api, FieldVisitor fv);

public AnnotationVisitor visitAnnotation(String desc, boolean visible);

public void visitAttribute(Attribute attr);

public void visitEnd();

}

Figure 2.5.: The FieldVisitor class

이러한 보조 방문자의 생성 및 사용법은 다음 장에서 설명합니다. 실제로 이 장은 ClassVisitor 클래스만으로 해결할 수있는 간단한 문제로 제한됩니다.

ClassVisitor 클래스의 메서드는이 클래스의 JavaDoc에 지정된, 다음과 같은 순서로 호출해야합니다 :

visit visitSource? visitOuterClass? ( visitAnnotation | visitAttribute )* ( visitInnerClass | visitField | visitMethod )* visitEnd

즉, visit를 먼저 호출 한 다음, visitSource를 한 번만 호출 한 다음, visitAuterClass를 한 번만 호출하고 , 그 다음에 임의의 순서로 visitAnnotation 및 visitAttribute를 호출하고, 다음 visitInnerClass, visitField 및 visitMethod를 임의의 순서로 호출 할 수 있고 visitEnd를 한 번 호출하여 종료되었습니다.

ASM은 ClassVisitor API를 기반으로 클래스를 생성하고 변환하는 세 가지 핵심 컴포넌트를 제공합니다.

• ClassReader 클래스는 바이트 배열된 컴파일 된 클래스를 파싱하고 인수로 전달 된 ClassVisitor 인스턴스의 해당 visitXxx 메서드를 accept 메서드로 호출합니다. 이벤트 프로듀서로 볼 수 있습니다.

• ClassWriter 클래스는 컴파일 된 클래스를 직접 바이너리 형식으로 빌드하는 ClassVisitor 추상 클래스의 하위 클래스입니다. toByteArray 메소드로 검색 할 수있는 컴파일 된 클래스를 포함하는 바이트 배열을 출력으로 생성합니다. 이벤트 소비자로 볼 수 있습니다.

• ClassVisitor 클래스는 수신 한 모든 메서드 호출을 다른 ClassVisitor 인스턴스에 위임합니다. 이벤트 필터로 볼 수 있습니다.

다음 섹션에서는 이러한 구성 요소로 어떻게 클래스를 생성하고 변환하는지 구체적인 예를 제시합니다.

2.2.2. Parsing classes

기존 클래스를 구문 분석하는 데 필요한 유일한 구성 요소는 ClassReader 구성 요소입니다. 이것을 설명하기위한 예를 들어 봅시다. javap 도구와 비슷한 방법으로 클래스의 내용을 인쇄하고 싶다고 가정 해 보겠습니다. 첫 번째 단계는 방문하는 클래스에 대한 정보를 인쇄하는 ClassVisitor 클래스의 하위 클래스를 작성하는 것입니다.

다음은 지나치게 단순화 된 구현입니다.다.

public class ClassPrinter extends ClassVisitor {

public ClassPrinter() {

super(ASM4);

}

public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) {

System.out.println(name + " extends " + superName + " {");

}

public void visitSource(String source, String debug) { }

public void visitOuterClass(String owner, String name, String desc) { }

public AnnotationVisitor visitAnnotation(String desc, boolean visible) {

return null;

}

public void visitAttribute(Attribute attr) { }

public void visitInnerClass(String name, String outerName, String innerName, int access) { }

public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) {

System.out.println(" " + desc + " " + name);

return null;

}

public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {

System.out.println(" " + name + desc); return null;

}

public void visitEnd() {

System.out.println("}");

}

두 번째 단계는 이 ClassPrinter를 ClassReader 구성 요소와 결합하여 ClassReader가 생성 한 이벤트가 ClassPrinter에서 사용되도록합니다.

ClassPrinter cp = new ClassPrinter();

ClassReader cr = new ClassReader("java.lang.Runnable");

cr.accept(cp, 0);

두 번째 행은 ClassReader를 만들어 Runnable 클래스를 구문 분석합니다. 마지막 줄에서 호출 된 accept 메소드는 Runnable 클래스 바이트 코드를 파싱하고 cp에서 해당 ClassVisitor 메소드를 호출합니다. 결과는 다음과 같습니다.

java/lang/Runnable extends java/lang/Object {

run()V

}

ClassReader 인스턴스를 구성하는 방법은 여러 가지가 있습니다. 읽어야하는 클래스는 이름, 위와 같이 또는 값, 바이트 배열 또는 InputStream으로 지정할 수 있습니다. 클래스의 내용을 읽어 들이기위한 입력 스트림은, 다음과 같이 ClassLoader의 getResourceAsStream 메소드를 사용해 취득 할 수 있습니다.

cl.getResourceAsStream(classname.replace(’.’, ’/’) + ".class");

2.2.3. Generating classes

클래스를 생성하는 데 필요한 유일한 구성 요소는 ClassWriter 구성 요소입니다. 이것을 설명하기위한 예를 들어 봅시다. 다음 인터페이스를 고려하십시오.

package pkg;

public interface Comparable extends Mesurable {

int LESS = -1;

int EQUAL = 0;

int GREATER = 1;

int compareTo(Object o);

}

ClassVisitor에 대한 6 가지 메소드 호출로 생성 될 수 있습니다.

ClassWriter cw = new ClassWriter(0);

cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE,

"pkg/Comparable", null, "java/lang/Object", new String[] { "pkg/Mesurable" });

cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, "LESS", "I",

null, new Integer(-1)).visitEnd();

cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, "EQUAL", "I",

null, new Integer(0)).visitEnd();

cw.visitField(ACC_PUBLIC + ACC_FINAL + ACC_STATIC, "GREATER", "I",

null, new Integer(1)).visitEnd();

cw.visitMethod(ACC_PUBLIC + ACC_ABSTRACT, "compareTo", "(Ljava/lang/Object;)I",

null, null).visitEnd();

cw.visitEnd();

byte[] b = cw.toByteArray();

첫 번째 줄은 클래스의 바이트 배열 표현을 실제로 작성하는 ClassWriter 인스턴스를 만듭니다 (생성자 인수는 다음 장에서 설명합니다).

visit 메소드를 호출하여 클래스 헤더를 정의합니다. V1_5 인수는 다른 모든 ASM 상수와 마찬가지로 ASM Opcode 인터페이스에 정의 된 상수입니다. 클래스 버전 인 Java 1.5를 지정합니다. ACC_XXX 상수는 Java 제어자(modifier)에 해당하는 플래그입니다. 여기에서는 클래스가 인터페이스이고 public과 abstract(인스턴스화 될 수 없기 때문에)임을 지정합니다. 다음 인수는 클래스 이름을 내부 형식으로 지정합니다 (2.1.2 절 참조). 컴파일 된 클래스에는 패키지 또는 import 섹션이 없으므로 모든 클래스 이름을 fully qualified해야합니다. 다음 인수는 제네릭에 해당합니다 (4.1 절 참조). 이 경우에는 인터페이스가 type변수에 의해 매개 변수화되지 않았기 때문에 null입니다. 다섯 번째 인수는 내부 형식 (객체 클래스에서 암시 적으로 상속 된 인터페이스 클래스)의 수퍼 클래스입니다. 마지막 인수는 내부 이름으로 기술한 extends된 인터페이스들의 배열입니다.

다음 세 번의 visitField 호출은 비슷하며 세 인터페이스 필드를 정의하는 데 사용됩니다. 첫 번째 인수는 Java 제어자에 해당하는 플래그 집합입니다. 여기서 필드는 public, final 및 static으로 지정합니다. 두 번째 인수는 소스 코드에 나타나는대로 필드의 이름입니다. 세 번째 인수는 type descriptor 양식의 필드 유형입니다. 여기서 필드는 int 필드이며, 그 기술자는 I입니다. 네 번째 인수는 제네릭에 해당합니다. 이 경우 필드 유형이 제네릭을 사용하지 않기 때문에 null입니다. 마지막 인수는 필드의 상수 값입니다.이 인수는 진정한 상수 필드, 즉 final static 필드에만 사용해야합니다. 다른 필드의 경우, 널 (NULL)이어야합니다. 여기에 annotation이 없으므로 반환 된 FieldVisitor 후에 visitEnd 메서드를 호출합니다. 즉, 해당 visitAnnotation 또는 visitAttribute 메서드를 호출하지 않습니다.

마지막으로 visitEnd에 대한 마지막 호출은 클래스가 완료되었음을 cw에 알리고 toByteArray에 대한 호출을 사용하여이를 바이트 배열로 검색하는 데 사용됩니다

Using generated classes

이전 바이트 배열은 나중에 사용할 수 있도록 Comparable.class 파일에 저장할 수 있습니다. 다른 방법으로는 ClassLoader를 사용하여 동적으로 로드 할 수 있습니다. 한 가지 방법은 public인 defineClass 메소드를 가진 ClassLoader 서브 클래스를 정의하는 것입니다.

class MyClassLoader extends ClassLoader {

public Class defineClass(String name, byte[] b) {

return defineClass(name, b, 0, b.length);

}

그런 다음 생성 된 클래스는 다음을 사용하여 직접로드 할 수 있습니다.

Class c = myClassLoader.defineClass("pkg.Comparable", b);

또 다른 방법은 요청 된 클래스를 생성하기 위해 findClass 메서드가 재정의 된 ClassLoader 하위 클래스를 정의하는 것입니다.

class StubClassLoader extends ClassLoader {

@Override

protected Class findClass(String name) throws ClassNotFoundException {

if (name.endsWith("_Stub")) {

ClassWriter cw = new ClassWriter(0);

...

byte[] b = cw.toByteArray();

return defineClass(name, b, 0, b.length);

}

return super.findClass(name);

}

실제로 생성 된 클래스를 사용하는 방법은 컨텍스트에 따라 다르며 ASM API의 범위를 벗어납니다. 컴파일러를 작성하는 경우 클래스 생성 프로세스는 컴파일 할 프로그램을 나타내는 추상 구문 트리로 구동되며 생성 된 클래스는 디스크에 저장됩니다. 동적 프록시 클래스 생성기 또는 aspect weaver를 작성하는 경우, 어떤 방법 으로든 ClassLoader를 사용할 것입니다.

2.2.4. Transforming classes

지금까지 ClassReader 및 ClassWriter 구성 요소는 단독으로 사용되었습니다. 이벤트는 "손으로"제작되어 ClassWriter에 의해 직접 소비되거나 대칭 적으로 ClassReader에 의해 생성되어 "손으로"즉 사용자 정의 ClassVisitor 구현에 의해 소비되었습니다. 이러한 구성 요소를 함께 사용하면 모든 것이 정말 흥미로워지기 시작합니다. 첫 번째 단계는 ClassReader가 생성 한 이벤트를 ClassWriter로 전달하는 것입니다. 결과적으로, 클래스 리더에 의해 구문 분석 된 클래스는 클래스 작성자에 의해 재구성됩니다.

byte[] b1 = ...;

ClassWriter cw = new ClassWriter(0);

ClassReader cr = new ClassReader(b1);

cr.accept(cw, 0);

byte[] b2 = cw.toByteArray(); // b2 represents the same class as b1

이것은 그 자체로는별로 흥미롭지 않습니다 (바이트 배열을 복사하는 더 쉬운 방법이 있습니다!). 그러나 기다려주십시오. 다음 단계는 클래스 판독기와 클래스 작성기 사이에 ClassVisitor를 도입하는 것입니다.

byte[] b1 = ...;

ClassWriter cw = new ClassWriter(0);

// cv forwards all events to cw\

ClassVisitor cv = new ClassVisitor(ASM4, cw) { };

ClassReader cr = new ClassReader(b1);

cr.accept(cv, 0);

byte[] b2 = cw.toByteArray(); // b2 represents the same class as b1

위의 코드에 해당하는 아키텍처는 Figure 2.6에 나와 있으며 구성 요소는 사각형으로 표시되고, 이벤트는 화살표로 표시된다.((시퀀스 다이어그램 에서처럼 수직 타임 라인이 있음).

Figure 2.6 : A transformation chain

그러나 ClassVisitor 이벤트 필터가 아무 것도 필터링하지 않기 때문에 결과는 변경되지 않습니다. 그러나 이제는 클래스를 변형 할 수 있도록 일부 메서드를 재정 의하여 이벤트를 필터링하는 것으로 충분합니다. 예를 들어 다음 ClassVisitor 하위 클래스를 생각해 볼 수 있습니다.

public class ChangeVersionAdapter extends ClassVisitor {

public ChangeVersionAdapter(ClassVisitor cv) {

super(ASM4, cv);

}

@Override

public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) {

cv.visit(V1_5, access, name, signature, superName, interfaces);

}

이 클래스는 ClassVisitor 클래스의 한 메서드 만 재정의합니다. 결과적으로 모든 호출은 변경된 클래스 버전 번호로 전달되어진다.

visit 메소드에 대한 호출을 제외하고 생성자에 class visitor CV로 변경되지 않고 전달됩니다.

해당 시퀀스 다이어그램이 Figure 2.7에 나와 있습니다.

Figure 2.7 : Sequence diagram for the ChangeVersionAdaptor

visit 메소드의 다른 인수를 수정하면 클래스 버전을 변경하는 것 이외의 다른 변환을 구현할 수 있습니다. 예를 들어, 구현 된 인터페이스 목록에 인터페이스를 추가 할 수 있습니다. 클래스의 이름을 변경하는 것도 가능하지만, 이는 visit 메소드에서 name 인수를 변경하는 것 이상을 필요로합니다. 실제로 클래스의 이름은 컴파일 된 클래스의 여러 다른 위치에 나타날 수 있으며 이러한 모든 변경은 클래스의 실제 이름을 바꾸기 위해 변경되어야 합니다.

Optimization

이전 변환은 원래 클래스에서 4 바이트 만 변경합니다. 그러나 위의 코드에서 b1은 완전히 파싱되고 해당 이벤트는 처음부터 b2를 구성하는 데 사용되며 이는 그리 효율적이지 않습니다. 이러한 부분을 파싱하지 않고 해당 이벤트를 생성하지 않고 직접 b2로 변환되지 않은 b1 부분을 복사하는 것이 훨씬 더 효율적입니다. ASM은 메소드 최적화를 자동으로 수행합니다.

• ClassReader Component에서 MethodVisitor를 감지하면 ,이 메서드의 내용은 변형되지 않으며 응용 프로그램에서도 실제로 볼 수 없습니다. #MethodVisitor는 ClassVisitor의 accept 메서드에 대한 인수로 전달 된 ClassWriter에 >해석 애모모함

• 이 경우 ClassReader Component는 이 메서드의 내용을 parse하지 않고, 해당 이벤트를 생성하지 않고, 그냥 바이트 배열 표현을 ClassWriter에 복사합니다.

이 최적화는 ClassReader 및 ClassWriter 구성 요소에 의해 수행됩니다.

그들이 서로에 대한 참조를 가지고 있다면, 다음과 같이 설정할 수 있습니다 :

byte[] b1 = ...

ClassReader cr = new ClassReader(b1);

ClassWriter cw = new ClassWriter(cr, 0);

ChangeVersionAdapter ca = new ChangeVersionAdapter(cw);

cr.accept(ca, 0);

byte[] b2 = cw.toByteArray();

이 최적화 덕분에 위의 코드는 이전 버전보다 2 배 빠릅니다. 왜냐하면 ChangeVersionAdapter가 어떤 방법도 변환하지 않기 때문입니다.

일부 또는 모든 메소드를 변환하는 공통 클래스 변환의 경우 속도향상은 작지만 여전히 눈에 띕니다. 그것은 실제로 10-20 %의 순서입니다. 불행하게도이 최적화는 원래 클래스에 정의 된 모든 상수를 변환 된 상수로 복사해야합니다. 이는 필드, 메소드 또는 지침을 추가하는 변환에 대해서는 문제가되지 않지만 많은 클래스 요소를 제거하거나 이름을 바꾼 변환에 대해서는 최적화되지 않은 경우와 비교하여 더 큰 클래스 파일로 이어집니다. 따라서 "additive"변환에만이 최적화를 사용하는 것이 좋습니다.

Using transformed classes

변환 된 클래스 b2는 이전 섹션에서 설명한대로 디스크에 저장하거나 ClassLoader로로드 할 수 있습니다. 다만, ClassLoader 내부에서 행해지는 클래스 변환은,이 클래스 로더에 의해로드 된 클래스만을 변환 할 수 있습니다. 모든 클래스를 변환하려면 java.lang.instrument 패키지에 정의 된대로 ClassFileTransformer 내에 변환을 넣어야합니다.

(자세한 내용은이 패키지의 문서를 참조하십시오) :

public static void premain(String agentArgs, Instrumentation inst) {

inst.addTransformer(new ClassFileTransformer() {

public byte[] transform(ClassLoader l, String name, Class c,

ProtectionDomain d, byte[] b)

throws IllegalClassFormatException {

ClassReader cr = new ClassReader(b);

ClassWriter cw = new ClassWriter(cr, 0);

ClassVisitor cv = new ChangeVersionAdapter(cw);

cr.accept(cv, 0);

return cw.toByteArray();

}

});

}

2.2.5. Removing class members

이전 섹션에서 클래스 버전을 변환하는 데 사용 된 메서드는 ClassVisitor의 메서드입니다. 예를 들어, visitField 및 visitMethod 메소드에서 access 또는 name 인수를 변경하기위해 ,필드나 메소드의 modifier나 이름을 변경할 수 있습니다. 또한 , 수정 된 인수를 사용하여 메서드 호출을 전달하는 대신, 이 호출에 전혀 전달하지 않도록 선택할 수 있습니다. 결과는 해당 클래스 요소가 제거 된 것입니다.

예를 들어, 다음 클래스 어댑터가 클래스의 컴파일 된 소스 파일의 이름뿐만 아니라 외부 및 내부 클래스에 대한 정보를 제거합니다 (결과 클래스는 디버깅 목적으로 만 사용되기 때문에 완전한 기능을 유지함). 이는 적절한 visit 메서드에서 아무 것도 전달되지 않게 수행됩니다.

즉, 아무것도 설정하지 class생성에 값이 전달되지않는다. 유지하기 위해서는 cv.visitXXX을 호출 해 줘야한다.

public class RemoveDebugAdapter extends ClassVisitor {

public RemoveDebugAdapter(ClassVisitor cv) {

super(ASM4, cv);

}

@Override

public void visitSource(String source, String debug) { }

@Override public void visitOuterClass(String owner, String name, String desc) { }

@Override public void visitInnerClass(String name, String outerName, String innerName, int access) { }

}

이 전략은 visitField 및 visitMethod 메서드가 결과를 반환해야하기 때문에 필드와 메서드에 대해서는 작동하지 않습니다. 필드 또는 메서드를 제거하려면 메서드 호출을 전달하지 말고 호출자에게 null을 반환해야합니다. 예를 들어, 다음 클래스 어댑터는 이름과 설명자로 지정된 단일 메소드를 제거합니다 (클래스는 동일한 이름이지만 매개 변수가 다른 여러 메소드를 포함 할 수 있기 때문에 이름은 메소드를 식별하기에 충분하지 않습니다).

public class RemoveMethodAdapter extends ClassVisitor {

private String mName;

private String mDesc;

public RemoveMethodAdapter( ClassVisitor cv, String mName, String mDesc) {

super(ASM4, cv); this.mName = mName;

this.mDesc = mDesc;

}

@Override

public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {

if (name.equals(mName) && desc.equals(mDesc)) {

// do not delegate to next visitor -> this removes the method

return null;

}

return cv.visitMethod(access, name, desc, signature, exceptions);

}

2.2.6. Adding class members

당신은 클래스 element를 추가하여 더 많은 것을 전달할 수 있습니다. 원래의 메소드 호출 사이의 여러 곳에 새로운 호출을 삽입할 수 있으며, 다양한 visitXxx 메소드를 이용하면 된다. (섹션 2.2.1 참조).

예를 들어, 클래스에 필드를 추가하려면 원래 메서드 호출 사이에 새로운 visitField의 호출을 삽입해야 하며, 클래스 어댑터의 visit 메서드 중 하나로 이 새로운 호출을 추가해야 합니다. visit메소드에서 이 작업을 수행 할 수 없습니다. 예를 들어 visitField 호출 다음에의 visitSource, visitOuterClass, visitAnnotation 또는 visitAttribute 는 유효하지 않습니다. 같은 이유로 새로운 호출을 visitSource, visitOuterClass, visitAnnotation 또는 visitAttribute 메소드에 넣을 수 없습니다. 가능한 옵션은 visitInnerClass, visitField, visitMethod 또는 visitEnd 메소드입니다.

>>visit는 순서가 있다.

visitEnd 메소드에 새 호출을 넣으면 이 메소드가 항상 호출되기 때문에 필드가 항상 추가됩니다 (명시 적 조건을 추가하지 않는 한).

visitField 또는 visitMethod에 입력하면 여러 필드가 추가됩니다. 원래 클래스의 필드 또는 메소드 당 하나씩 필드가 추가됩니다. 두 솔루션 모두 의미가 있습니다. 그것은 당신이 필요한 것에 달려 있습니다. 예를 들어 객체의 호출 수를 계산하는 단일 카운터 필드 또는 메소드 당 하나의 카운터를 추가하여 각 메소드의 호출을 개별적으로 계산할 수 있습니다.

참고 : 사실 유일한 해결책은 visitEnd 메서드에서 추가 호출을 만들어 새 멤버를 추가하는 것입니다. 실제로 클래스에는 중복 멤버가 없어야하며 새 멤버가 고유한지 확인하는 유일한 방법은 모든 기존 멤버와 비교하는 것입니다.이 멤버는 모두 방문한 후에 만 수행 할 수 있습니다 (예 : visitEnd 메서드). 이것은 다소 제한적입니다. _counter $ 또는 _4B7F_와 같이 프로그래머가 사용하지 않는 생성 된 이름을 사용하면 중복 된 멤버가 visitEnd에 추가하지 않고도 피할 수 있습니다. 첫 번째 장에서 설명한 것처럼 트리 API에는이 제한이 없습니다.이 API를 사용하여 변환 내에서 언제든지 새 멤버를 추가 할 수 있습니다.

위의 설명을 설명하기 위해이 필드가 이미 존재하지 않는 한 클래스에 필드를 추가하는 클래스 어댑터가 있습니다.

public class AddFieldAdapter extends ClassVisitor {

private int fAcc;

private String fName;

private String fDesc;

private boolean isFieldPresent;

public AddFieldAdapter(ClassVisitor cv, int fAcc, String fName, String fDesc) {

super(ASM4, cv);

this.fAcc = fAcc;

this.fName = fName;

this.fDesc = fDesc;

}

@Override

public FieldVisitor visitField(int access, String name, String desc,String signature, Object value) {

if (name.equals(fName)) {

isFieldPresent = true;

}

return cv.visitField(access, name, desc, signature, value);

}

@Override

public void visitEnd() {

if (!isFieldPresent) {

FieldVisitor fv = cv.visitField(fAcc, fName, fDesc, null, null);

if (fv != null) {

fv.visitEnd();

}

cv.visitEnd();

}

필드는 visitEnd 메소드에 추가됩니다. 기존 필드를 수정하거나 필드를 제거하기 위해 visitField 메소드를 재정의하지 않고 추가하려는 필드가 이미 존재하는지 여부를 감지합니다. fv.visitEnd ()를 호출하기 전에 visitEnd 메소드에서 fv! = null 테스트를 참고하십시오. 이전 섹션에서 보았듯이 class visitor는 visitField에서 null을 리턴 할 수 있기 때문입니다.

2.2.7. Transformation chains

지금까지 우리는 ClassReader, class adapter 및 ClassWriter로 이루어진 간단한 변환 체인을 보았습니다. 물론 더 복잡한 체인을 사용할 수도 있습니다. 여러 개의 클래스 어댑터가 함께 연결됩니다. 여러 어댑터를 연결하면 복잡한 변형을 수행하기 위해 여러 개의 독립적 인 클래스 변환을 작성할 수 있습니다. 변환 체인은 반드시 선형 적이지는 않습니다. 받은 모든 메소드 호출을 여러 ClassVisitor에 동시에 전달하는 ClassVisitor를 작성할 수있다.

public class MultiClassAdapter extends ClassVisitor {

protected ClassVisitor[] cvs;

public MultiClassAdapter(ClassVisitor[] cvs) {

super(ASM4);

this.cvs = cvs;

}

@Override public void visit(int version, int access, String name,

String signature, String superName, String[] interfaces) {

for (ClassVisitor cv : cvs) {

cv.visit(version, access, name, signature, superName, interfaces);

}

...

}

대칭 적으로 여러 클래스 어댑터가 동일한 ClassVisitor에 위임 할 수 있습니다 (예 : visit 및 visitEnd 메소드가이 ClassVisitor에서 한 번만 호출되도록하는 몇 가지 예방 조치가 필요함). 따라서 그림 2.8에 제시된 것과 같은 변형 체인이 완벽하게 가능합니다.

Figure 2.8 : A complex transformation chain

2.3. Tools

ClassVisitor 클래스 및 관련 ClassReader 및 ClassWriter 구성 요소 외에도 ASM은 org.objectweb.asm.util 패키지에 클래스 생성기 또는 어댑터의 개발 중에 유용 할 수 있는 (runtime에서필요하지 않은) 여러 가지 도구를 제공합니다. ASM은 런타임에 내부 이름, 유형 설명자 및 메소드 설명자를 조작하기위한 유틸리티 클래스도 제공합니다. 이 모든 도구는 다음과 같습니다.

2.3.1. Type

이전 섹션에서 보았 듯이, ASM API는 컴파일 된 클래스, 즉 내부 이름 또는 유형 설명자로 저장되는 Java 유형을 노출합니다. 소스 코드에 나타나는대로 코드를 노출하여 코드를 보다 쉽게 읽을 수 있습니다. 그러나 이것은 ClassReader와 ClassWriter의 두 표현 사이의 체계적인 변환을 필요로 하며 이는 성능을 저하시킵니다. 그렇기 때문에 ASM은 내부 이름과 유형 설명자를 동등한 소스 코드 형식으로 투명하게 변환하지 않습니다. 그러나 필요한 경우 수동으로 수행하기위한 Type 클래스를 제공합니다.

Type object는 Java 타입을 나타내며, type descriptor 또는 Class object부터 구축 할 수 있습니다. Type class는 primitive type을 나타내는 정적 변수도 포함합니다. 예를 들어, Type.INT_TYPE는 int 유형을 나타내는 Type 객체입니다.

getInternalName 메소드는 Type의 내부 이름을 리턴합니다. 예를 들어, Type.getType (String.class) .getInternalName ()은 String 클래스의 내부 이름을 제공합니다 (예 : "java / lang / String"). 이 메소드는 클래스 또는 인터페이스 유형에만 사용해야합니다.

getDescriptor 메소드는 Type의 디스크립터를 리턴한다. 예를 들어, 대신 "Ljava / lang / String;"을 사용하십시오. 코드에서 Type.getType (String.class) .getDescriptor ()를 사용할 수 있습니다. 또는 I를 사용하는 대신 Type.INT_TYPE.getDescriptor ()를 사용할 수 있습니다.

Type object는 메서드 type을 나타낼 수도 있습니다. 이러한 객체는 메소드 설명자 또는 Method 객체에서 구성 할 수 있습니다.. 그런 다음 getDescriptor 메소드는이 유형에 해당하는 메소드 설명자를 리턴합니다. 또한 getArgumentTypes 및 getReturnType 메서드를 사용하여 메서드의 인수 형식 및 반환 형식에 해당하는 Type 개체를 가져올 수 있습니다. 예를 들어 Type.getArgumentTypes ( "(I) V")는 단일 요소 Type을 포함하는 배열을 반환합니다.

INT_TYPE. 같이, Type.getReturnType ( "(I) V")를 호출하면 (자), Type.VOID_TYPE object가 반환됩니다.

2.3.2. TraceClassVisitor

생성되거나 변환 된 클래스가 예상 한 것과 일치하는지 확인하려면, ClassWriter에 의해 반환 된 바이트 배열은 사람이 읽을 수 없으므로 별로 도움이 되지 않습니다. 텍스트 표현은 사용하기가 훨씬 쉬울 것입니다. 이것은 TraceClassVisitor 클래스가 제공하는 것입니다. 이 클래스는 이름에서 알 수 있듯이 ClassVisitor 클래스를 확장하고 visited class의 텍스트 표현을 작성합니다. 따라서, ClassWriter를 사용하여 클래스를 생성하는 대신 TraceClassVisitor를 사용하여 실제로 생성 된 내용을 읽을 수있는 추적을 얻을 수 있습니다. 또는 두 가지를 동시에 사용할 수 있습니다. 실제로 TraceClassVisitor는 기본 비헤이비어 외에 메소드에 대한 모든 호출을 다른 방문자 (예 : ClassWriter)에게 위임 할 수 있습니다.

ClassWriter cw = new ClassWriter(0);

TraceClassVisitor cv = new TraceClassVisitor(cw, printWriter);

cv.visit(...);

...

cv.visitEnd();

byte b[] = cw.toByteArray();

이 코드는 수신 한 모든 호출을 cw에 위임 한 TraceClassVisitor를 만들고이 호출의 텍스트 표현을 printWriter에 인쇄합니다.

예를 들어, 2.2.3 절의 예제에서 TraceClassVisitor를 사용하면 다음을 얻을 수 있습니다.

// class version 49.0 (49)

// access flags 1537

public abstract interface pkg/Comparable implements pkg/Mesurable {

// access flags 25

public final static I LESS = -1

// access flags 25

public final static I EQUAL = 0

// access flags 25

public final static I GREATER = 1

// access flags 1025

public abstract compareTo(Ljava/lang/Object;)I

}

TraceClassVisitor는 생성 또는 변형 체인의 어느 지점에서나 ClassWriter 바로 전에뿐만 아니라 체인의이 시점에서 어떤 일이 발생하는지 확인할 수 있습니다. 이 어댑터에 의해 생성 된 클래스의 텍스트 표현은 String.equals ()를 사용하여 클래스를 쉽게 비교하는 데 사용될 수 있습니다.

2.3.3. CheckClassAdapter

ClassWriter 클래스는 메서드가 올바른 순서와 유효한 인수로 호출되는지 확인하지 않습니다. 따라서 Java 가상 머신 검증 자에 의해 거부 될 유효하지 않은 클래스를 생성 할 수 있습니다.

가능한 빨리 이러한 오류 중 일부를 감지하기 위해 CheckClassAdapter 클래스를 사용할 수 있습니다. TraceClassVisitor와 마찬가지로이 클래스는 ClassVisitor 클래스를 확장하고 메서드에 대한 모든 호출을 다른 ClassVisitor (예 : TraceClassVisitor 또는 ClassWriter)에 위임합니다. 그러나 vistied class의 텍스트 표현을 인쇄하는 대신이 클래스는 다음 방문자에게 위임하기 전에 해당 메소드가 올바른 순서 및 유효한 인수로 호출되는지 확인합니다. 에러가 발생했을 경우, IllegalStateException 또는 IllegalArgumentException가 발생됩니다.

클래스를 검사하고이 클래스의 텍스트 표현을 출력하고 마지막으로 바이트 배열 표현을 만들려면 다음과 같이 사용해야합니다.

ClassWriter cw = new ClassWriter(0);

TraceClassVisitor tcv = new TraceClassVisitor(cw, printWriter);

CheckClassAdapter cv = new CheckClassAdapter(tcv);

cv.visit(...);

...

cv.visitEnd();

byte b[] = cw.toByteArray();

이러한 클래스 visitor를 다른 순서로 연결하면 수행하는 작업도 다른 순서로 수행됩니다. 예를 들어 다음 코드를 사용하면 trace 후에 검사가 수행됩니다.

ClassWriter cw = new ClassWriter(0);

CheckClassAdapter cca = new CheckClassAdapter(cw);

TraceClassVisitor cv = new TraceClassVisitor(cca, printWriter);

TraceClassVisitor와 마찬가지로, 체인의 클래스를 확인하기 위해 ClassWriter 바로 전에뿐만 아니라 생성 또는 변형 체인의 어느 지점에서나 CheckClassAdapter를 사용할 수 있습니다.

2.3.4. ASMifier

이 클래스는 TraceClassVisitor 도구에 대한 대체 백엔드를 제공합니다 (기본적으로 Textifier 백엔드를 사용하여 위에 표시된 출력 유형을 생성합니다). 이 백엔드는 TraceClassVisitor 클래스의 각 메소드를 호출하는 데 사용 된 Java 코드를 인쇄합니다. 예를 들어 visitEnd () 메서드를 호출하면 cv.visitEnd ();가 인쇄됩니다. 결과적으로 ASMifier 백엔드가있는 TraceClassVisitor 방문자가 클래스를 방문하면 ASM을 사용하여이 클래스를 생성하는 소스 코드를 인쇄합니다. 이 방문자를 사용하여 이미 존재하는 클래스를 방문하는 경우에 유용합니다. 예를 들어 ASM을 사용하여 컴파일 된 클래스를 생성하는 방법을 모르는 경우 해당 소스 코드를 작성하고 javac을 사용하여 컴파일 한 다음 ASMifier를 사용하여 컴파일 된 클래스를 방문하십시오.

이 컴파일 된 클래스를 생성하는 ASM 코드를 얻게됩니다!

The ASMifier class can be used from the command line. For example using:

java -classpath asm.jar:asm-util.jar \ org.objectweb.asm.util.ASMifier \ java.lang.Runnable

produces code that, after indentation, reads:

package asm.java.lang;

import org.objectweb.asm.*;

public class RunnableDump implements Opcodes {

public static byte[] dump() throws Exception {

ClassWriter cw = new ClassWriter(0);

FieldVisitor fv;

MethodVisitor mv;

AnnotationVisitor av0;

cw.visit(V1_5, ACC_PUBLIC + ACC_ABSTRACT + ACC_INTERFACE,

"java/lang/Runnable", null, "java/lang/Object", null);

{

mv = cw.visitMethod(ACC_PUBLIC + ACC_ABSTRACT, "run", "()V",null, null);

mv.visitEnd();

}

cw.visitEnd();

return cw.toByteArray();

}

2018/09/11 - [분류 전체보기] - ASM User Guide 번역 3

ASM User Guide 번역 1

yimoc — Mon, 10 Sep 2018 16:24:52 +0900

https://asm.ow2.io/asm4-guide.pdf

ASM 4.0

A Java bytecode engineering library

1.2. Overview

1.2.1. Scope

ASM 라이브러리의 목표는 컴파일 자바클래스 파일을 생성, 변환 및 분석하는 것입니다.Java 클래스는 바이트 배열로 표현됩니다 (디스크에 저장되고 Java 가상 머신에 로드 됨). 이를 위해 ASM은 숫자 상수, 문자열, Java 식별자, Java 유형, Java 클래스 구조 요소 등과 같이 바이트보다 상위 개념을 사용하여 바이트 배열을 읽고 쓰고 변환하는 도구를 제공합니다. ASM의 범위는 클래스의 읽기, 쓰기, 변형 및 분석에만 엄격하게 제한됩니다. 특히 클래스 로딩 프로세스는 범위를 벗어납니다.

1.2.2. Model

ASM 라이브러리는 컴파일된 클래스의 생성과 변환을위한 두 개의 API를 제공합니다.

코어 API는 클래스의 이벤트 기반 표현을 제공하지만 트리 API는 객체 기반 표현을 제공합니다.

이벤트 기반 모델에서 클래스는 일련의 이벤트로 표현되며, 각 이벤트는 클래스의 요소 (예 : 헤더, 필드,메소드 선언, 명령어 등)를 표현한다.

이벤트 기반 API는 가능한 이벤트 세트 및 발생 순서를 정의하며

분석되는 요소 당 하나의 이벤트를 발생하는 클래스 구문 분석기와

이러한 이벤트의 시퀀스에서 컴파일 된 클래스를 생성하는 클래스 작성기를 제공합니다.

객체 기반 모델을 사용하면 클래스는 객체 트리로 표현됩니다.

각 객체는 클래스 자체, 필드, 메소드 등의 클래스의 일부를 나타내는 객체.지시 등를 나타냅니다.

각 객체는 해당 구성을 나타내는 객체에 대한 참조를가집니다.

객체 기반 API는 클래스를 나타내는 일련의 이벤트를 그클래스를 나타내는 객체 트리로 변환하거나 ,

반대로 객체 트리를 동등한 이벤트 시퀀스로 변환하는 방법을 제공합니다.

즉, 객체 기반 API는 이벤트 기반 API 위에 구축됩니다.

이 두 API는 SAX (Simple API for XML) 및 DOM (Document Object Model) API와 비교할수 있습니다 : 이벤트 기반

API는 SAX와 유사하지만 객체 기반 API는 DOM과 유사합니다. 객체 기반 API는 DOM이 SAX기반에 제공되듯이 이벤트 기반 객체 위에 구축됩니다.

ASM은 최상의 API가 없기 때문에 두 API를 모두 제공합니다. 실제로 각 API에는 장점과 단점이 있습니다.

• 이벤트 기반 API가 빠르고 객체기반API보다 적은 메모리가 필요합니다.

왜냐하면 , 클래스를 표현하기 위해 메모리에 트리를 생성하고 저장할 필요가 없기 때문이다.(SAX 및 DOM도 동일한 차이가 있다).

• 그러나, 이벤트 기반 API를 사용하여 클래스 변환을 구현하는 것이 더 어려울 수 있습니다.

객체 기반 API를 사용하여 전체 클래스를 메모리에서 사용하여 하는것보다, 어느 한 주어진 시점(현재 이벤트에 해당하는 요소)에 클래스의 한 요소만 사용하기 때문이다.

> SAX처럼 한 이벤트가 발생하는 시점에 이루어지기 때문에 전체를 보고 작업하는것보다는 어렵다는 얘기

두 API는 한 번에 하나의 클래스 만 관리하고 독립적으로 관리합니다.

클래스 계층 구조에 대한 정보는 유지되지 않으며 클래스 변환이 다른 클래스에 영향을주는 경우 다른 클래스를 수정하는 것은 사용자의 책임입니다.

1.2.3. Architecture

ASM 애플리케이션은 강력한 아키텍처 측면을 가지고 있습니다. 사실 이벤트 기반 API는 이벤트 생성자 (클래스 파서), 이벤트 소비자 (클래스 작성자) 및 미리 정의 된 다양한 이벤트 필터를 구성됩니다. 또한, 사용자 정의한 생성자, 소비자 및 필터도 추가할수 있습니다. 따라서, 이 API를 사용하는 것은 두 단계 프로세스입니다.

• 이벤트 생성자, 필터 및 소비자 구성 요소를 가능한 복잡한 구조로 모으고,

• 생성 또는 변환 프로세스를 실행하기 위해 이벤트 생성자를 시작합니다.

오브젝트 기반 API는 또한 아키텍처 측면을 가지고 있습니다. 실제로 객체트리에서 작동하는 클래스 생성기 또는 변환기 구성 요소가 구성 될 수 있으며, 이들 사이의 링크는 변환 순서를 나타냅니다.

전형적인 ASM 애플리케이션의 대부분의 컴포넌트 아키텍처는 매우 간단하지만 다음과 같은 복잡한 아키텍처를 상상할 수 있습니다.

화살표는 클래스 파서, 생성자 또는 변환기 사이의 이벤트 기반 또는 오브젝트 기반 통신을 나타냅니다.

체인 내의 이벤트 기반 표현과 객체 기반 표현 간의 가능한 변환이다.

CR은 ClassReader, CW는 ClassWriter이다. 중간의 박스는 Adaptor 및 기타 CR, CW 사용가능하다.

1.3. Organization

ASM 라이브러리는 여러 패키지로 구성되며 각패키지는 jar 파일로 배포됩니다.

• org.objectweb.asm 및 org.objectweb.asm.signature 패키지

이벤트 기반 API를 정의하고 클래스 parser와 writer 구성 요소를 제공합니다.

이 파일은 asm.jar 아카이브에 들어 있습니다.

• org.objectweb.asm.util 패키지는 asm-util.jar 에 있습니다.

ASM 애플리케이션의 개발 및 디버깅에 사용되는 다양한 도구를 제공합니다.

해당 tool은 core API를 기반으로 합니다.

• org.objectweb.asm.commons 패키지는 core API를 기반으로 하는 몇 가지 유용한 미리 정의 된 클래스 변환기를 제공합니다.

asm-commons.jar 아카이브에 포함되어 있습니다.

• org.objectweb.asm.tree 패키지는 asm-tree.jar 아카이브에 있습니다.

객체 기반 API를 정의하고 이벤트 기반 및 객체 기반 표현간의 변환을 위한 툴을 제공합니다.

• org.objectweb.asm.tree.analysis 패키지는 클래스 분석 프레임워크을 제공합니다.

또한, 몇 가지 미리 정의 된 클래스 분석기를 제공합니다. 해당 기능은 트리API기반입니다.

asm-analysis.jar 아카이브에 포함되어 있습니다.

이 문서는 두 부분으로 구성되어 있습니다. 첫 번째 부분은 핵심 API, 즉 asm, asm-util 및 asm-commons 아카이브를 다룹니다. 두 번째 부분은 트리 API, 즉 asm-tree 및 asm-analysis 아카이브를 다룹니다. 각 Part에는 클래스와 관련된 API 장, 메소드와 관련된 API에 대한 장 및 annotation, generic Type 등과 관련된 API에 대한 장이 포함됩니다. 각 장에는 프로그래밍 인터페이스와 관련 도구가 포함되어 있습니다 사전 정의 된 구성 요소. 모든 예제의 소스 코드는 ASM 웹 사이트에서 제공됩니다.

이 구조을 통해 클래스 파일 기능을 점진적으로 도입하는 것이 더 쉬워 지지만 때로는 여러 섹션에서 단일 ASM 클래스의 프레젠테이션을 분산해야하는 경우가 있습니다. 따라서이 문서를 순차적으로 읽는 것이 좋습니다. ASM API에 대한 참조 가이드는 Javadoc을 사용하십시오.

javadoc : https://javadoc.io/doc/org.ow2.asm/asm/6.2.1

2018/09/10 - [ASM] - ASM User Guide 번역 2