바이트코드 조작(리플렉션, 다이나믹 프록시, 애노테이션 프로세서)

스프링에서 다양한 설정기능들 (@Autowried 등)은 어떻게 코드없이 객체를 주입하고, 조작할 수 있는 것일까? 또 Lombok같은 어노테이션 기반 라이브러리는 어떻게 동작하는 것일까? 그 비밀은 모두 자바의 바이트코드에 있다.

2021.08.16 - [기본 지식/Java 기본지식] - JVM의 원리와 바이트코드

JVM의 원리와 바이트코드

Java Reflection - Dynamic Proxies (jenkov.com)

Java Reflection - Dynamic Proxies

 

---

# 자바의 바이트코드를 조작하는 방법

리플렉션 기법이 아니라 그냥 바이트코드 자체를 조작하는 라이브러리도 있다.

• CGLib (Code Generator Library) - 리플렉션을 이용한 다이나믹 프록시 생성도구
• ASM 바이트코드 조작 (low level) https://asm.ow2.io/
• Javassist https://www.javassist.org/
• ByteBuddy 바이트코드 조작(ASM을 기반으로 만듦)https://bytebuddy.net/#

바이트코드 조작을 사용하는 다양한 예시

 

---

# 리플렉션

스프링의 Dependency Injection은 어떻게 동작할까?

@Service
public class BookService {
	@Autowired // 스프링은 어떻게 bookRepository 인스턴스를 넣어 준 것일까?
	BookRepository bookRepository;
}

 

---

@ 리플렉션이란?

리플렉션이란 [Class 정보를 담는 객체]를 이용해 해당 클래스의 정보를 분석해내는 프로그래밍 기법을 의미한다. 즉  구체적인 클래스 타입, 정보를 알지 못하더라도 객체 이름("my.ClassName")으로 런타임 시점에서 [리플렉션 객체의 바이트코드]를 이용해 내가 원하는 객체와 메서드를 사용할 수 있다는 말이다.

 

동적 바인딩이 되지 않던 자바에서, 리플렉션 기법을 이용해 런타임에 동적인 바인딩을 제공하는 것이라고 이해하면 쉽다. 자바의 Object 객체에는 Object.Class 라는 리플렉션 객체(=해당 Class의 정보를 담고있는 객체)를 가지고 있는데, 컴파일 타임에 클래스의 이름을 알 수 있다면 이 Object.Class 객체를 얻을 수 있다.

// Class.forName("패키지 전체 경로") 
// 클래스이름.class
MyHello.class
Class.forName("mypackage.core.MyHello")

// 또는 인스턴스에서 getClass()로 받아오는 방법도 있다.
Book book = new Book();
Class<? extends Book> aClass = book.getClass();

Class myObjectClass = Class.forName("me.package.className"); // 클래스를 생성 후 반환
Class.forName("oracle.jdbc.driver.OracleDriver");

// 참고 :: Class.forName() 메서드 정의
public static Class<?> forName(String className)
                        throws ClassNotFoundException {...}

 

---

@ 리플렉션 사용해보기, java.lang.Class<T>

public class App {
    public static void main(String[] args) {
        Class<User> userClass = User.class;
        User user = new User("test", "name", "1234"); // 테스트용 인스턴스
        
        Arrays.stream(userClass.getDeclaredFields())
                .forEach(filed -> {// User.class에 정의된 필드를 모두 가져와서
                    try {
                        filed.setAccessible(true); // private 접근제어자 무시
                        // filed.get(인스턴스)로 해당 인스턴스의 데이터를 읽어서 반환함.
                        // 만약 .get(null)을 한다면 static인 클래스 데이터를 반환함.
                        System.out.println(filed + " " + filed.get(user));
                        
                    } catch (IllegalAccessException e) {
                        // 잘못된 접근, 해당 메서드가 없는 경우등등..
                    }
                });
    }
}

이렇게 해당 클래스의 정보를 얻거나, 컴파일 이후 런타임에 동적으로 인스턴스를 만들 수 있다.

 

Class<T>는 클래스에 관련된 모든 정보를 제공한다.

 

---

@ 리플렉션과 어노테이션

눈썰미가 좋다면 위에서 봤겠지만, Class<T>에는 getAnnotation()이라는 메서드가 있다. 그래서 클래스에 어노테이션을 달고 아래와 같은 코드를 작성해보면 어노테이션들이 나와야할 것 같지만 실제로는 아무런 값도 찍히지 않는다.

 // 등록된 어노테이션이 없음. 콘솔창에 찍어도 아무것도 안나온다.
 Arrays.stream(User.class.getAnnotations()).forEach(System.out::println);

그 이유는 어노테이션 자체가 주석 (//)과 동일한 취급을 받기 때문이다. 컴파일러를 위한 주석.

자바 어노테이션(@Annotation)

@MyAnnotation의 정보는 JVM이 읽어들여 처리한다. 즉 자바 코드와 바이트코드(.class)까지는 남지만 해당 바이트코드가 읽어들여진 후에 런타임 메모리에는 어노테이션에 대한 어떠한 정보도 남아있지 않다.

 

다만 자바에서는 코드에서 리플렉션을 사용할 수 있도록 어노테이션을 정의할 때 생명주기(@Retention)를 런타임까지 남아있도록 설정할 수 있다. Class.getAnnotation()을 사용하고 싶다면 아래와 같이 어노테이션을 만들면 된다.

import java.lang.annation.*;

@Documented
@Retention(RetentionPolicy.RUNTIME) // 런타임에도 어노테이션 사용가능(리플렉션)
@Target( ElementType.TYPE, ElementType.FILED )
public @interface FunctionalInterface{...}

이후 getAnnotation()을 콘솔에 찍어보면 다음과 같이 애노테이션 데이터를 보고, 사용할 수 있다.

// 해당 클래스에서 사용된 모든 어노테이션 조회
//ex:: @my.package.MyAnnotation(value="haha", number=100)
Arrays.stream(User.class.getAnnotations()).forEach(System.out::println);

// 특정 필드, 메소드에 있는 어노테이션만 가져올 수도 있다.
Arrays.stream(User.class.getDeclaredFields()).forEach(
        field -> {// 해당 필드에 있는 어노테이션들을 모두 꺼낸다
            Arrays.stream(field.getAnnotations()).forEach(
                    annotation -> {// 어노테이션은 타입을 비교해서 찾을 수 있다.
                        if (annotation instanceof MyAnnotation) {
                            MyAnnotation myAnno = (MyAnnotation) a;
                            System.out.println(myAnno.value() + " " + myAnno.myNumber());
                        }
                    });
        }
);

 

---

@ 리플렉션 API - 인스턴스 생성 , 클래스 수정

import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;

public class App {
    // 리플렉션 사용시 발생할 수 있는 예외들.
    public static void main(String[] args) throws ClassNotFoundException, NoSuchMethodException,
            InvocationTargetException, InstantiationException, IllegalAccessException, NoSuchFieldException {

        //Class<User> userClass = User.class; 제네릭 생략가능
        Class userClass = Class.forName("my.package.User");

        // (~) 에는 파라메타의 타입을 적는다. 만약 없다면 null
        Constructor constructor = userClass.getConstructor(String.class, String.class, String.class);
        User user = (User) constructor.newInstance("생성자에 매개변수 문자열값", "name", "1234");

        Field a = User.class.getDeclaredField("name"); // 클래스 멤버(static 멤버)를 가져온다.
        a.setAccessible(true); // 접근제어자(private) 를 무시함.
        
        String classMember = (String) a.get(null); // 클래스 멤버(static) name 값을 가져옴
        String name = (String) a.get(new User("a","b","c")); // 해당 인스턴스의 name 값을 가져옴
    }
}

참고로 메서드는 아래와 같이 가져와서 사용할 수 있다.

Method m = User.class.getDeclaredMethod("methodName");
m.setAccessible(true); // 접근제어자(private) 를 무시함.
m.invoke(메소드 파라메타); // 메서드 실행

 

---

@ 나만의 DI 컨테이너 만들어보기

스프링 컨테이너에서 getBean() 은 어떻게 동작하는 걸까? 간단한 나만의 어노테이션 컨테이너를 만들어보자.

public Class BookService(){
    @Inject // 직접 만든 어노테이션
    BookRepository bookRepository;
    
}

public class Container {
    private static <T> T createInstance(Class<T> classType) {
        try {
            // 매개변수가 없는 기본생성자를 사용하여 인스턴스 생성
            return classType.getConstructor(null).newInstance();
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    public static <T> T getObject(Class<T> classType) {
        T myInstance = createInstance(classType); // 1. 리플렉션으로 해당 객체를 만듬

        Arrays.stream(classType.getDeclaredFields()).forEach(
                field -> { // 2. 필드 중에 Inject 어노테이션이 있다면 동작
                    if (field.getAnnotations(Inject.class) != null) {
                        // 3. 리플렉션으로 주입할 객체의 인스턴스를 만듬.
                        Object fieldInstance = createInstance(field.getType());
                        field.setAccessible(true); // private 접근제어자 무시
                        try {
                            // 4. @Inject가 붙은 필드를 찾아, 그 필드에 알맞은 객체 만들어 주입함.
                            field.set(myInstance, fieldInstance);

                        } catch (IllegalAccessException e) {
                            throw new RuntimeException(e);
                        }
                    }
                }
        );
        
        // @Inject 를 이용하여 필드값에 원하는 객체를 주입한 [classType] 객체를 반환함.
        return myInstance;
    }
}

 

이렇게 어노테이션이 달린 객체, 메서드를 찾아 원하는 필드를 삽입할 수 있다. 스프링의 싱글톤 빈도 이런 식으로 만들어진다. 이는 아래에서 프록시를 배우며 더 자세하게 알아보자.

@Bean
public MemberRepository memberRepository() {
        if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
            return 스프링 컨테이너에서 찾아서 반환;
            
        } else { //스프링 컨테이너에 없으면
            기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
            return 반환
        }
}

---

@ 주의사항

리플렉션은 프레임워크를 포함해서 다양한 곳에서 활용된다.

• 스프링 - 의존성 주입, MVC 뷰에서 넘오온 데이터를 객체에 바인딩할 때
• 하이버네이트(JPA) - @Entity 클래스에 Setter가 없다면 리플렉션을 사용
• JUnit - 어노테이션을 이용한 테스트 환경설정

 

그만큼 강력한 기능이지만, 리플렉션의 잘못된 사용은 아래와 같은 문제점을 만들 수 있다는 걸 명심하자.

• 리플렉션의 과도한 사용은 성능 이슈를 발생시키기 쉽다. 리플렉션이 꼭 필요한 곳에만 사용하자.
• 리플렉션은 런타임시에 객체를 조작하는 기술이므로 컴파일 타임에 확인되지 않는 문제를 만들 수 있다.
• 런타임에 객체를 조작하기에 마음만 먹는다면 접근 지시자(private)를 무시할 가능성이 있다. (캡슐화 파괴)

 

---

 

# 다이나믹 프록시

다이나믹 프록시란 애플리케이션 실행도중, 특정 인터페이스들을 [구현하는 클래스 또는 인스턴스]를 자동으로 만드는 기술이다. 다이나믹 프록시는 리플렉션 기술을 통해 만들어진다.

• 스프링 데이터 JPA에서 인터페이스 타입의 인스턴스는 누가 만들어주는 것인가?
  -> Spring AOP를 기반으로 동작하며 RepositoryFactorySupport에서 프록시를 생성한다.
  -> Spring AOP의 가장 밑단에서는 Proxy 라이브러리를 이용한 리플렉션을 사용하는 것을 볼 수 있다.

@Entity
public class Book{
    ...
}

@Service
public class BookService{
    @Autowired // 인터페이스에 자동주입
    BookRepository bookRepository;
}

public interface BookRepository extends JpaRepository<Book, Integer>{
}

// 스프링 빈으로 등록될 것 같지도 않고, 인터페이스에는 아무런 코드도 없다.
// 하지만 위의 @Autowired는 정상적으로 동작하고, 실제 인스턴스가 주입된다.
// 어노테이션도 없는데 어떻게 리플렉션으로 이 모든기능을 만들 수 있었을까?

 

---

@ 프록시 패턴

다이나믹 프록시를 살펴보기 이전에, '프록시'가 정확하게 무엇인지 알아보자.

Proxy는 '대리인' 이라는 의미를 가진다. 개발에서 사용하는 Proxy 객체는 클라이언트-서버 등의 관계에서 중간에 끼어 대리인 역할을 하는 객체라고 생각하면 된다.

• 프록시와 실제 객체가 공유하는 인터페이스가 있고, 클라이언트는 인터페이스를 통해 프록시를 사용한다.
• 클라이언트는 실제 객체를 사용하는 것처럼 동작하지만, 실제로는 프록시를 통해서 접근하게된다.
• 이렇게 중간에 프록시를 사용함으로서 접근관리(보안), 캐싱(성능), 필터등의 부가기능들을 제공할 수 있다.
• 또한 실제 객체는 자신이 해야할 일(단일책임원칙, SRP)만 집중하면서 부가적인 기능(로깅, 트랜잭션 처리등)을 프록시 객체에게 넘겨 객체지향적인 프로그래밍을 할 수 있게 된다.

public interface BookService{ ... }

// 클라이언트는 인터페이스를 사용해서 객체를 사용한다.
// 하지만 실제로 호출되는 것은 중간에 있는 프록시 객체이다.
public class BookServiceProxy implements BookService {
    BookService bookService; // 실제 객체를 담는 곳
    
    @Override
    public void rent(Book book){
    	bookService.rent(book); // 보통은 프록시를 호출하면 실제객체에게 위임하도록 설계한다.
        // 물론 실제 객체를 호출하지 않고 프록시에서 원하는 동작을 하도록 바꿀 수도 있다.
    }
}

 

---

@ 프록시의 문제점

기존 프록시의 가장 큰 단점은 부가적인 기능을 추가할 때 마다 프록시를 새롭게 만들어야 한다는 것이다. 프록시를 하나만 사용한다면 괜찮겠지만, 실제 어플리케이션을 구현할 때에는 정말 많은 프록시들이 중첩되게 된다. 그렇다고 단 하나의 프록시에 모든 기능을 합치게되면 프록시를 사용하여 실제 객체와 분리하는 의미 자체가 없어지게 된다. 그냥 객체가 많아져 코드 관리만 복잡해질뿐이다.

• 실제 객체가 인터페이스를 구현한다면 프록시 또한 사용하지도 않는 모든 메서드를 @Override 해야한다.
• 프록시가 중첩되면 코드가 복잡해지고, 같은 코드의 중복이 발생한다.

이를 해결하기위해 나온 것이 리플렉션을 사용해서 런타임에 만드는 동적 프록시, 즉 Dynamic proxy이다. 프록시 객체를 기존 객체를 상속받아 하나하나 직접 만드는게 아니라, 런타임 시점에 [클래스 정보 Object.class]를 이용하여 어노테이션, 메서드에 따라 동적으로 다른 메서드 동작을 실행하도록 프록시를 만들 수 있다. 

---

@ 다이나믹 프록시

다이나믹 프록시 : 런타임에 특정 인터페이스들을 구현하는 클래스 또는 인스턴스를 만드는 기술, 리플렉션을 사용해 직접 구현해도 상관없지만, 편하게 사용하기 위해 자바 리플렉션API 에서 다이나믹 프록시 기능을 제공한다.

조금 쉽게 말하자면,

• 실제 객체와 같은 인터페이스를 사용하는 프록시 객체를 만든다.
  자바 API로는 실제 객체를 바로 상속받아서 조작하는 기능을 제공하지 않는다.
• 프록시 객체에서 해당 객체의 리플렉션 Class<T> (myClass.class)를 조작하고 조작된 Class<T>를 이용해서 런타임에 [프록시 객체 인스턴스]를 만든다.
• 개발자는 리플렉션 Class<T>를 쉽게 조작하기 위해서 Java API에 있는 InvocationHandler 객체의 invoke() 메서드만 오버라이딩하여 조작하고 싶은 내용을 작성하면 된다.
• 이렇게 프록시 객체를 만들면, 특정 메서드나 @어노테이션 값에 따라 동적으로 동작이 달라지는 프록시를 만들 수 있다. => 다이나믹 프록시

Proxy 객체의 IH(Invoke Handler)만 개발자가 구현하여 편하게 사용할 수 있는 API를 제공해준다.

public class BookServiceProxy implements BookService {
    // java.lang.reflect.Proxy.newProxyInstance
    // BookService 인터페이스에 프록시 객체 인스턴스를 런타임에 동적으로 등록하는 방법.
    BookService bookService = (BookService) Proxy.newProxyInstance(
            BookService.class.getClassLoader() // 프록시를 만들 ClassLoader
            ,new Class[]{BookService.class} // 프록시를 만들 인터페이스
            ,new InvocationHandler() { //invoke handler, 프록시의 내용. 직접 작성한 구현체
                BookService bookService = new DefaultBookService();
 
                @Override
                public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                    // 아무런 동작도 하지않고, 단순히 실제 객체에게 위임하는 프록시 코드.
                    // Object invoke = method.invoke(...)등으로 리플렉션 조작가능.
                    // method.invoke(메서드를 호출할 객체 , 메서드에 전달할 파라메타)
                    
                    // 여기에 추가코드를 작성하면 객체의 모든 메서드가 해당 코드를 동작한다.
                    return method.invoke(bookService, args);
                }
            });
            
    /*... 기타 메서드 생략 ...*/
}

 

만약 특정 메서드( rent() )만 추가적인 동작을 하도록 만들고 싶다면, 아래와 같이 조건을 만들어주면 된다.

if (method.getName().equals("rent")) {
    System.out.println("aaaa");
    Object invoke = method.invoke(bookService, args);
    System.out.println("bbbb");
    return invoke; // 이제 bookService.rent()는 실행 전후로 aaaa, bbbb를 출력한다.
}

다만 자바 API에서 제공하는 다이나믹 프록시는 인터페이스에서만 생성할 수 있다.(BookService.class.getClassLoader()). 인터페이스를 사용하는게 코드도 깔끔하고 제약사항도 없다. + 아마 자바 코드의 하위 호완성 때문에 제공하지 않는게 아닌가 싶다. 실제로 클래스로 생성하려고 하려고 하면 컴파일 오류가 나오게 된다. 만약 클래스의 다이나믹 프록시가 필요하다면 다른 방법이 있는데, 이는 아래의 [@클래스의 프록시 만들기] 에서 알아보도록 하자.

• JDK dynamic proxy로 구현되면 프록시 사용을 위해 Interface 사용이 강제화 한다는 단점이 있다.
• Dynamic Proxy는 Invocation Handler를 상속받아서 실체를 구현하게 되는데, 이 과정에서 특정 객체를 통으로 Reflection을 사용하는 방식이라서 성능이 조금 떨어진다.

https://www.baeldung.com/spring-aop-vs-aspectj

---

@ 스프링 AOP와 프록시

하지만 위와 같이 직접 동적 프록시를 만드는 것은 코드도 상당히 복잡해지고 구현하기도 어렵다. 그래서 스프링에서는 리플렉션 라이브러리(CGlib)를 이용하여 위와 같은 복잡한 구조를 추상화된 인터페이스로 포장해서 제공해주는데, 이것이 바로 스프링 AOP이다.

• 그래서 스프링 AOP는 프록시 기반으로 동작한다고 말한다. 이는 스프링을 공부하면서 배워보도록 하자.
• 스프링에서 AOP를 어떻게 만들었는가 궁금하면 [토비의 스프링3.1, 6장-AOP]를 읽어보도록 하자.

 

---

@ 클래스의 프록시 (인터페이스가 없는 경우, 상속 프록시)

위에서 말했지만 자바 API에서 제공하는 다이나믹 프록시는 인터페이스에서만 생성할 수 있다. 클래스 프록시가 필요하다면 직접 리플렉션으로 구현하거나 아래와 같은 리플렉션 라이브러리들을 사용하면 된다.

참고로 타겟 객체의 상속을 이용해서 프록시를 만드는 방법을 Subclass 프록시라고도 한다.

• CGlib ( https://github.com/cglib/cglib/wiki )
  - CGlib는 바이트코드를 조작하여 프록시 객체를 생성해주는 코드 생성(Code gen)라이브러리이다.
  - 런타임에 동적으로 자바 클래스의 프록시 생성 기능을 제공한다
  - 스프링, 하이버네이트가 사용하는 리플렉션 라이브러리 (물론 Java 리플렉션 API도 같이 사용한다)
  - 버전 호환성이 좋지 않아서 서로 다른 라이브러리 내부에 내장된 형태로 제공하기도 한다.
  - 스프링에서는 객체를 상속해서 프록시를 만들고 CGlib를 이용해 리플렉션을 활용한다.
  왜 스프링 빈 객체의 생성자는 protected, public 밖에 사용할 수 없는가? 에 대한 답변이 된다.
  
  
• JDK API에서 제공하는 동적 프록시와의 차이점 
  • JDK 프록시는 인터페이스에 적혀있는 모든 메서드에 프록시를 적용시킨다. 그리고 Class<T>정보로 조건문을 만들어 특정 메서드만 추가동작을 하도록 만들 수 있다.
  • CGlib는 MethodInterceptor 객체를 사용하여 특정 메서드만 프록시화 하고, 나머지는 프록시를 거치지 않고 실제 객체 메서드를 호출하도록 만들 수 있다.
  • 이게 가능한 이유는 CGlib는 인터페이스가 아닌 타겟 객체를 직접 상속받아 만들기 때문이다.

MethodInterceptor handler = new MethodInterceptor() {
    private final MethodMatcher methodMatcher; // 특정 메서드를 찾는 객체
    BookService bookService = new BookService();
	
    public MethodInterceptor(MemthodMatch m){
    	this.methodMatcher = m;
    }
    
    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy
            methodProxy) throws Throwable {    
        if (methodMatcher.matches(method)) {
            // CGlib는 상속된 프록시 객체를 사용하기에 특정메서드만 프록시로 바꿀 수 있음
            // JDK 다이나믹 프록시와 다르게 필요없는 메서드는 프록시를 안거치게 할수있음.
            return methodName.toUpperCase();
        }
        return method.invoke(bookService, objects);
    }
};

// CGlib로 조작한 프록시 객체를 삽입
BookService bookService = (BookService) Enhancer.create(BookService.class, handler);

• ByteBuddy
  - 바이트 코드를 조작을 제공해주는 라이브러리지만 Cglib처럼 런타임(다이나믹) 프록시를 만들 때도 사용한다.
  - CGlib와 마찬가지로 상속을 이용한 (subClass) 프록시를 지원한다.

Class<?> dynamicType = new ByteBuddy()
  .subclass(Object.class)
  .method(ElementMatchers.named("toString"))
  .intercept(FixedValue.value("Hello World!"))
  .make()
  .load(getClass().getClassLoader())
  .getLoaded();
 
assertThat(dynamicType.newInstance().toString(), is("Hello World!"));

 

* 다만 리플렉션과 프록시를 사용할 정도의 어플리케이션이라면 비즈니스 규모가 크고 코드가 복잡한 경우가 많다. 그래서 가능하면 클래스를 상속받아서 만드는 것 보다는, 가능하면 인터페이스 프록시를 사용해서 만드는 것이 좋다.

• 상속을 사용하지 못하는 경우 프록시를 만들 수 없다. (스프링 빈 private, final 클래스가 안되는 이유)
• 클래스로 프록시를 계속 상속받으면 비즈니스가 커졌을 때 유지보수, 확장이 힘든 코드가 될 수 있다.
• 즉 가능하면 클래스가 아닌 인터페이스의 프록시를 만드는 것이 유연한 코드를 만들기 좋다.

 

 

---

@ 다이나믹 프록시 정리 (바이트코드 Weaving)

다이나믹 프록시를 사용한다는 말은 런타임에 [인터페이스 프록시 인스턴스] 또는 [클래스의 프록시 인스턴스] 또는 [리플렉션을 이용한 클래스 자체]를 만들어 사용하는 프로그래밍 기법을 사용한다는 말이다.

 

이렇게 원하는 타겟 객체에 프록시를 적용시켜,  동적으로 [프록시된 객체]를 삽입하는 기술을 Runtime Weaving이라고 표현한다. 스프링에서는 JDK Weaving, CGlib Weaving을 사용하는데 이는 위에서 설명한 리플렉션,프록시 내용과 같은 말이다.

 

다이나믹 프록시는 아래와 같이 다양한 곳에 사용된다. 

• 스프링 AOP
  AOP는 설명하면 끝도 없으므로, 궁금하다면 [토비의스프링3.1v 6장 AOP]를 읽어보자.

• 하이버네이트 Lazy Initialization

@Entity
@Getter
public class Book {
    @Id @GeneratedValue
    private Integer id;

    private String title;

    @OneToMany
    private List<Note> notes;
    // Book을 조회할 때 List<Note>를 같이 가져오진 않는다. 실제 notes를 사용할 때 쿼리를 발생시켜 받아온다.
    // 이는 Fetch 전략을 Lazy로 했기 때문. 그렇다면 notes를 사용하기 전까지는 값은 null 인가?
    // 하지만 실제로 조회해보면 null이 아니다. 그 이유는 다이나믹 프록시 객체를 이용하기 때문이다.
}

 

• Mockito (진짜처럼 동작하는 테스트용 Mock 객체를 지원하는 프레임워크)

import static org.mockito.Mockito.mock;

// 실제 객체를 상속한 다이나믹 프록시를 활용해서 만든 mock 객체.
BookRepository bookRepositoryMock = mock(BookRepository.class);

// Mockito 프레임웤은 이렇게 특정 메서드의 반환값을 내가 원하는 객체로 조작 가능 (mocking)
Book testBook = new Book("myBookName");
when(bookRepositoryMock.save(any())).thenReturn(testBook); // 아무거나 넣어도 testBook 반환

BookService bookService = new BookService(bookRepositoryMock);
bookService.rent(new Book("custom name"))
book.rent() // Mockito의 다이나믹 프록시 적용 => 무조건 Book("myBookName")이 반환됨

public class BookService {
    BookRepository bookRepository;

    public BookService(BookRepository bookRepository) {
        this.bookRepository = bookRepository;
    }

    public void rent(Book book) {
        Book savedBook = bookRepository.save(book);
        System.out.println("rent: " + savedBook.getTitle());\
    }
}

 

---

 

# 애노테이션 프로세서

음! 그렇다면 Lombok도 다이나믹 프록시처럼 리플렉션을 활용해서 동작하겠구나! 하고 생각할 수 있지만, 이는 리플렉션을 이용해서 구현한 것이 아니다. 이에 대해서 알아보도록 하자.

 

@ JDK 1.5, 애노테이션의 등장

애노테이션은 소스코드에 컴파일 타임에 읽을 수 있는 주석을 통해 메타데이터(설정정보)를 추가하는 기능이다.

• 기존의 자바 프로그램은 소스코드와 그에 대한 문서를 따로 작성하는게 일반적이었다. 하지만 매번 코드와 문서를 동기화해주는 작업은 매우 번거로웠고, 자바 개발자들은 소스코드의 주석으로 부터 HTML문서를 자동 생성해내는 javadoc.exe를 만들게 되었다. 
• 기존의 자바 설정파일은 프로젝트 내에 XML 파일의 형태로 관리했었는데, 이것도 문서와 마찬가지로 소스코드와 함께 관리할 수 없을까? 라는 아이디어에서 나오게 된 것이 컴파일러를 위한 주석, [@애노테이션] 이다. 애노티에션의 등장으로 설정파일을 자바코드 내에 삽입하고 간단하게 설정을 변경할 수 있게 바뀌었다.

현재 자바에서 어노테이션 정보를 이용하는 방법은 크게 3가지가 있다.

1. 컴파일러에게 문법 에러를 확실하게 체크하도록 정보 제공 (@Override등)
2. 컴파일 타임에 자동으로 코드를 생산할 수 있는 정보 제공 (애노테이션 프로세서)
3. 런타임에 동적으로 특정 기능을 수행할 수 있도록 정보를 제공 (리플렉션)

 

---

@ Java(JVM)의 다양한 기능

컴파일된 바이트코드(.class)는 JVM이 읽어들여 프로그램을 실행한다. JVM에서는 특정 인터페이스를 상속받았을 때 다른 동작을 하도록 컴파일해주거나 아예 런타임 시점에서 특정 동작이 발생하였을 때 중간에 가로채서 다른 코드를 실행하게 만드는 hook등을 제공한다. 

• Shutdown Hook
  - JDK1.3에 나온 기능으로 JVM이 종료될 때 작업을 가로채서 특정 코드를 실행하도록 만들 수 있다.
• Annotation Processor
  - JDK1.5~1.6에 나온 기능으로 어노테이션 기반 빌드 툴이다.(javac.exe, 즉 자바 컴파일러에 포함되어있음)
  - 컴파일 도중 애노테이션을 만나면 특정한 동작을 하도록 만들 수 있다.
  - AbstractProcessor 객체를 상속받아 사용할 수 있다.
• 객체 직렬화
  - JDK1.1에 나온 기능으로 Serializable 인터페이스를 상속받으면 JVM이 자동으로 해당 객체가 직렬화(객체 -> 바이트코드 전환)될 수 있도록 만들어준다. 

 

---

@ Lombok이란

https://projectlombok.org/features/all

애노테이션 기반으로 자주 사용하는 코드를 대신 생성해주는 자바 오픈소스 라이브러리이다. 현재 자바에서 가장 많이 쓰는 라이브러리로, @Getter @Setter @Builder등의 전용 어노테이션과 어노테이션 프로세서 코드(AbstractProcessor)를 제공한다.

애노테이션 프로세서는 Javac(자바 컴파일러)에 포함되어있는 프로그램이다.

 

---

@ Lombok의 동작원리

• 우선 lombok 라이브러리를 가져오면 전용 어노테이션을 사용할 수 있다.
• [애노테이션 프로세서]를 이용해 만든 라이브러리이다. 내부에서 AbstractProcessor를 상속받아 사용한다.
• 애노테이션들로 적은 정보를 바탕으로 컴파일 시점에 [애노테이션 프로세서]를 이용하여 소스코드의 AST(abstract syntax tree)를 조작한다. 이를 이용해서 마치 코드가 바뀐 것처럼 동작하게 만든다.
  

  

  AST객체. javac(컴파일러)에서는 내부 메서드를 이용해서 AST를 만든다.

• 다만 이는 자바에서 공식적으로 제공하는 참조만 가능한 객체(TypeElement 와 RoundEnvironment)를 하위타입으로 강제 캐스팅하여 javac가 사용하는 메서드를 사용하여 AST를 조작한다. 일종의 컴파일러 해킹이라고 볼 수도 있다.
• 그래서 이클립스는 agent로, VsCode와 IntelliJ는 플러그인으로 lombok을 사용할 수 있도록 제공해준다.
  (IntelliJ에서는 플러그인을 설치하고, Lombok 라이브러리를 import한 후 어노테이션프로세스를 활성화 시키면 사용할 수 있다.)

애노테이션 프로세스는 javax.annotation.processing.AbstractProcessor 를 상속받아 사용할 수 있다.

그럼에도 불구하고 Lombok을 사용하는 이유, 논란거리

Lombok은 공개된 API가 아닌 컴파일러 내부 클래스를 사용하여 기존 소스코드를 조작한다.

 

심지어 이클립스의 Lombok은 java agent를 사용하여 컴파일러 내부 클래스 자체도 조작해버린다. 해당 클래스들 역시 공식적으로 공개된 API가 아니다보니, JVM이 업데이트 되면서 버전 호환성등 정말 다양한 문제가 생길 수 있는 위험성을 가진다.

 

그럼에도 불구하고 lombok이 제공하는 엄청난 편의기능들 덕분에 압도적인 사용률을 보이고 있다. 물론 자바 공식API만을 사용한 다른 라이브러리들도 있지만, lombok만큼 편하지는 않아서 대체하지 못하는 현실이다.

• 구글의 AutoValue (https://github.com/google/auto/blob/master/value/userguide/index.md)
• Immutables (https://immutables.github.io/)

 

사실 이러한 논란은 롬복 공식홈페이지와 Lombok을 만든 개발자의 블로그에도 정상적인 자바API 사용이 아닌 해킹임을 인정하고 있고, 개발자의 입장이 자세하게 적혀있다. 하지만 우리는 애노테이션 프로세서의 원리를 이해하려고 하는거지 Lombok에 대해 알고자하는 것이 아니기에, 이정도만 알고 넘어가도록 하자.

자바API를 사용하는 게 아니라 Javac 메서드를 강제로 캐스팅해서 사용하기에 컴파일러 해킹이 맞다.

 

---

 

# 애노테이션 프로세서 구현해보기

@ 1. 사용할 어노테이션을 정의한다.

@Target(ElementType.TYPE) //타입으로 지정하면 인터페이스, 클래스, enum에 사용가능하다.
@Retention(RetentionPolicy.SOURCE) // 컴파일 시점에만 존재하는 어노테이션 정보이다.
public @interface Magic {
}


@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.TYPE)
public @interface MyCustomAnnotation {
    String tag();
}

 

---

@ 2. AbstractProcessor를 상속받아 어노테이션 Parser를 만든다. 

• 어노테이션 프로세서를 설정 없이 컴파일러에 등록할 수 있게 구글의 auto-service(@AutoService)를 사용했다.
• 이를 다른말로 Service Provider 레지스트리(설정정보) 생성기라고 한다. Service Provider를 사용하기위한
  [ META-INF/services/javax.annotation.processor.Processor ] 정보를 자동으로 생성한다.
  
  
• ServiceProvider란 JDK1.6부터 제공하는 기능으로 Java의 META-INF 디렉토리에 인터페이스나 클래스 정보를 작성하면 개발자가 따로 객체를 선언, 생성하지 않아도 해당 서비스를 이용할 수 있게 만들어준다. (설정영역의 분리)

@AutoService(Processor.class)
public class AutoFactoryProcesser extends AbstractProcessor {
  @Override
  // init함수로 processingEnvironment 객체를 얻을 수 있다.
  // 이 객체를 이용하여 파일생성(Filer)과 로깅(Message)을 할 수 있다.
  public synchronized void init(ProcessingEnvironment env) {
     super.init(processingEnv);
     filer = processingEnv.getFiler();
     messager = processingEnv.getMessager();
  }

  @Override
  // 어떠한 어노테이션을 처리할 건지 정한다.
  public Set<String> getSupportedAnnotationTypes() {
      return Set.of(Magic.class.getName());
  }

  @Override
  // 어떤 소스코드 버전을 지원하는지 정한다.
  public SourceVersion getSupportedSourceVersion() {
      return SourceVersion.latestSupported();
  }

  @Override
  // 어노테이션 프로세서의 동작 코드 작성
  public boolean process(Set<? extends TypeElement> set, RoundEnvironment env) {            
        // @Magic을 가지고있는 요소(필드, 메서드, 변수...)들을 전부 가지고 온다.
        Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(Magic.class);  
        
        /* 어노테이션에 따라 컴파일 타임에 추가로 할 동작 코드를 작성한다 */
            
        return true; // false를 반환하면 다음 round를 한번 더 진행한다.
  }
                         
}

 

 

어노테이션 프로세서는 라운드(단계)별로 반복해서 진행된다. process는 아래와 같이 구현할 수 있다. 이렇게 얻은 어노테이션의 정보를 element 객체로 받아와 내가 원하는 Builder 클래스를 만들어서 코드를 조작할 수 있다.

  @Override
  // 어노테이션 프로세서는 round(단계)를 반복하면서 동작한다.
  // 각 round마다 특정한 어노테이션을 처리한 후, 결과를 다음 round로 반환한다.
  // 이렇게 큰그림으론 Filter-Chaning처럼 동작하지만, 실제 동작은 조금 더 복잡하다.
  public boolean process(Set<? extends TypeElement> set, RoundEnvironment env) {            
        // @Magic을 가지고있는 요소(필드, 메서드, 변수...)들을 전부 가지고 온다.
        Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(Magic.class);   
        
        for (Element element : elements) {
            Name elementName = element.getSimpleName();
        
             if (element.getKind() != ElementKind.INTERFACE) {
                // element가 원하는 타입이 아닌 경우 processingEnv를 이용해 컴파일 에러를 발생시키는 코드
                processingEnv.getMessager().printMessage(Diagnostic.Kind.ERROR,
                        "Magic annotation can not be used on " + elementName);
            } else {
                processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Processing " + elementName);
            }
        }

        return true // true는 모든 작업이 완료되었다는 의미. 애노테이션 프로세서가 종료됨
  }

 

---

@3 코드 생성 라이브러리(javapoet)

다만 이렇게 직접 구현하면 자바 소스코드를 생성하기는 상당히 번거로운데, 이를 직관적으로 사용할 수 있게 만든 javapoet이라는 오픈소스 라이브러리가 있다. javapoet은 소스코드를 쉽게 생성하는 도구이다.

MethodSpec main = MethodSpec.methodBuilder("main")
    .addModifiers(Modifier.PUBLIC, Modifier.STATIC)
    .returns(void.class)
    .addParameter(String[].class, "args")
    .addStatement("$T.out.println($S)", System.class, "Hello, JavaPoet!")
    .build();

TypeSpec helloWorld = TypeSpec.classBuilder("HelloWorld")
    .addModifiers(Modifier.PUBLIC, Modifier.FINAL)
    .addMethod(main)
    .build();

JavaFile javaFile = JavaFile.builder("com.example.helloworld", helloWorld)
    .build();
    
javaFile.writeTo(System.out);

위의 javapoet 코드는 아래와 같은 자바코드를 컴파일 시점에 생성해낸다.

package com.example.helloworld;

public final class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, JavaPoet!");
  }
}

 

다만 '생성' 해내는 것이지, 이미 작성된 클래스 코드를 마음대로 변경하는 건 lombok처럼 컴파일러를 해킹해서 사용하는 방법밖에는 없다.

 

---

 

# 정리

애노테이션 프로세서는 컴파일 시점에 작동하는 빌드 툴이다. 즉 리플렉션과 다르게 컴파일 시점에 모두 조작이 완료되기에, 추가적인 런타임 비용은 없다. (그냥 동일한 바이트코드이다). 그래서 기존의 코드를 조작하더라도 리플렉션에 비해 위험성이 덜하다.

 

다만 애노테이션 프로세서는 코드 생성이 아니라 기존의 코드를 수정하기는 어려운데, 이를 구현하려면 lombok처럼 컴파일러 메서드를 해킹해야한다는 단점이 있다. 하지만 미래의 JVM에서는 공식적인 API로 할 수 있게 언젠가 바뀌지 않을까?

• lombok
  - 어노테이션 프로세서 + 컴파일러 메서드 해킹
• 구글의 AutoService
  - 서비스로더용 리소스를 자동으로 만들어줌. java.util.ServiceLoader용 라이브러리
• Javapoet 라이브러리
  - 자바 코드를 쉽게 생성할 수 있게 도와주는 라이브러리 (애노테이션 프로세서등에서 주로 사용)
• @Override
  - 엥? 이건 어노테이션 프로세서가 아닌데요? 라고 할 수 있지만 사실 이러한 태그들도 어노테이션 프로세서를 이용하여 구현한다. 궁금하면 해당 링크에 들어가서 읽어보자
  
  

그 외에 어노테이션 프로세서를 사용한 라이브러리들

• Dagger2(컴파일 타임의 DI 제공, 근데 보통 Spring core에 있는 IoC, DI, AOP를 사용)
• 안드로이드 라이브러리 (안드로이드 OS도 JVM 바이트코드 기반으로 만들어졌다.)
  ○ ButterKinfe: @BindView (뷰 아이디와 애노테이션 붙인 필드 바인딩)
  ○ DeepLinkDispatch: 특정 URI 링크를 Activity로 연결할 때 사용

---

# 수고하셨습니다.

이 글에서는 정말 많은 내용을 다루었다.

• 바이트코드 자체를 조작하는 라이브러리 - ASM, Javassist, ByteBuddy(ASM으로 구현한 라이브러리)
  
  
• 바이트코드를 리플렉션 기법(Class<T>)를 이용해서 런타임에 조작하는 방법 - Java Reflection API
• 자바의 리플렉션 API - 클래스 정보(메소드, 필드, 어노테이션, 생성자..)를 참조하고 사용하는 법
  
  
• 리플렉션 기법을 활용한 다이나믹 프록시 구현 - 런타임에 일어나는 동적인 인스턴스 바운딩
• 다이나믹 프록시 라이브러리 - Java Proxy, CGlib, ByteBuddy(프록시 생성에도 사용가능)
  
  
• 컴파일 시점에서의 빌드 도구 - 애노테이션 프로세서 (AbstractProcessor)
• 애노테이션 프로세서 구현을 도와주는 라이브러리 - AutoService, Javapoet 

이제 스프링, 하이버네이트, Junit, Mockito 같은 프레임워크들이 어떻게 구현됬는지 감이 잡히는가? 이러한 지식들이 당장 서비스를 만드는데는 필요없지만, 더 나은 자바 개발자로 성장하는데 도움을 줄거라고 확신한다.