스프링은 객체를 어떻게 관리할까? (24.04.30)

블로그 작성법
목표 > 공부한 내용 > 얻었고, 앞으로 이걸 해봐야지 적기

✋ 수업 목표

• 빌드에 대해 공부해보자.

🤔 공부한 내용

인텔리제이 JVM 버전 수정

Spring 3점대 이상 버전을 사용하려고 다운 받고 인텔리제이를 사용하였는데, 호환이 되지 않았다.
이를 해결하기 위해 Settings에서 JVM 버전을 수정하였다.

Spring 3.x 버전을 사용하기 위해
Setting -> Build, Execution, Deployment -> Build Tools -> Gradle
이 부분에서 JVM 버전을 11 -> 17로 수정하였다.

참고 자료
https://dev-emmababy.tistory.com/139
https://www.itworld.co.kr/news/110817
https://velog.io/@nemo/spring-boot-java-error

빌드 도구

컴파일, 빌드

1. 빌드 프로세스 순서
   컴파일로 목적 코드를 만들고, 이 목적 코드들을 실행파일로 만들기 위해 연결*병합하는 링크 과정을 거친다. 이 과정이 빌드이다.

2. 빌드, 컴파일 각 한 줄 설명
   빌드: 소스 코드 파일을 실행할 수 있는 실행파일로 변환하는 과정으로 컴파일, 링크 과정을 포함한다.
   컴파일: 고급 언어에서 저급 언어로 번역하는 과정이다.

참고 자료
https://kimvampa.tistory.com/27

소스코드, 바이너리 코드, 바이트 코드

바이트 코드: 컴파일을 통해 JVM이 이해할 수 있는 코드
바이너리 코드: JVM에서 컴파일된 바이트코드를 링킹하여 CPU가 이해할 수 있는 코드

.exe, jar

실행: .exe, 실행 시키는 용도
배포: jar, 서버에 배포하는 용도
java를 돌리기 위한 압축 파일

라이브러리가 jar 형식인 이유
라이브러리는 선배 개발자들이 짜 놓은 코드이다.
이 코드들을 압축 파일로 사용한다.
압축하지 않으면 용량이 너무 크다.

하이브리드 언어 = 인터프리터 + 컴파일
Link Jar

Java -> .class : compile

---

[in JVM] .class -> 링킹 (+lib, res..) -> .exe
OS

링킹 과정에서 코드를 안 읽을까?

클래스 파일을 JVM은 읽을 수 있다.
JVM은 인터프리터로 일한다.

build.gradle, settings.gradle

(무수히 많은 작업을 통틀어 얘기하는) 빌드를 알아서 해주는 도구
= "빌드 (자동화) 도구"

• Ant: 명령이 어려웠음, 느려요
• Maven: 명령이 보다 쉬워짐, 좀 빨라졋음
• Gradle: 명령이 진짜 쉬움, 겁나 빨라짐

빌드 도구는
우리가 사용해야 하는 라이브러리들을
알아서 다운로드 받아서, 버전 호환성까지 따져서 사용한다.

필요한 라이브러리를 설치하려면 아래 라이브러리 사이트에서 다운로드 받아서 사용하자.
https://mvnrepository.com/

위 파일은 build.gradle이다.

• java로 구현
• spring boot 3.2.5
• repository는 mavencentral에서 가져올거다.

spring-boot-starter-web의 버전을
3.2.5 -> 3.2.4로 변경해보자.
https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/3.2.5

build.gradle에서 버전을 수정하고, gradle을 수정해보았다.
그랬더니 다음과 같이 내가 명시한 버전으로 라이브러리가 수정되었다.

버전을 명시하는게 좋을까, 명시하지 않는게 좋을까?

명시해야한다 입장
gradle이 바꾼다고 바꿔주는게 맞냐

명시하지 말자 입장
gradle이 해주는데 편하잖아

오픈소스

MIT license
: MIT에 저작권이 있으며, 사용시 출처 명시만 해줘.
Beerware license
: 코드 사용해도 되니까 나중에 맥주나 사줘.

실습: 프로젝트에 라이브러리를 찾아서 넣어보자

Lombok: 어노테이션으로 코드를 가져다 사용할 수 있다.
https://projectlombok.org/features/GetterSetter

1. 어디서 명령어 찾았는지
   : mvnrepository에서 찾았다.
   

위치
https://mvnrepository.com/artifact/org.projectlombok/lombok/1.18.32

2. 어디다 붙였는지
   : build.gradle
   버전은 떼고 사용하였다.

3. 누구에게 새로고침 하라고 알려줬는지
   : gradle

4. 어디에 라이브러리 추가되었나 확인

• 라이브러리 추가 과정

1. build.gradle의 dependecies에 다음과 같은 코드 추가
   
2. Gradle에서 새로고침
   
   
3. Lombok이 추가된 것을 확인
   
4. Settings -> Plugins에서 Lombok 추가
   
5. External Library에서 확인
   
6. 클래스 파일에서 Lombok 어노테이션 확인
   

참고자료
https://jaewonna.tistory.com/65

build.gradle의 dependencies 키워드

Spring 공식 문서에서 gradle의 dependencies에 대해 찾아보았다.
Declare dependencies

The simple Hello World sample is completely self-contained and does not depend on any additional libraries. Most applications, however, depend on external libraries to handle common and/or complex functionality.

간단한 Hello World 샘플은 완전히 독립적이며 추가 라이브러리에 의존하지 않습니다. 그러나 대부분의 애플리케이션은 일반 기능 및/또는 복잡한 기능을 처리하기 위해 외부 라이브러리에 의존합니다.

For example, suppose that in addition to saying "Hello World!", you want the application to print the current date and time. You could use the date and time facilities in the native Java libraries, but you can make things more interesting by using the Joda Time libraries.

예를 들어, "Hello World!"라고 말하는 것 외에도 응용 프로그램이 현재 날짜와 시간을 인쇄하기를 원한다고 가정합니다. 기본 Java 라이브러리의 날짜 및 시간 기능을 사용할 수 있지만 Joda Time 라이브러리를 사용하면 작업을 더욱 흥미롭게 만들 수 있습니다.

First, change HelloWorld.java to look like this:

먼저 HelloWorld.java를 다음과 같이 변경합니다.

package hello;

import org.joda.time.LocalTime;

public class HelloWorld {
  public static void main(String[] args) {
    LocalTime currentTime = new LocalTime();
    System.out.println("The current local time is: " + currentTime);

    Greeter greeter = new Greeter();
    System.out.println(greeter.sayHello());
  }
}

Here HelloWorld uses Joda Time’s LocalTime class to get and print the current time.

여기서 HelloWorld는 Joda Time의 LocalTime 클래스를 사용하여 현재 시간을 가져오고 인쇄합니다.

If you ran gradle build to build the project now, the build would fail because you have not declared Joda Time as a compile dependency in the build.

지금 프로젝트를 빌드하기 위해 gradle build를 실행했다면 빌드에서 Joda Time을 컴파일 종속성으로 선언하지 않았기 때문에 빌드가 실패할 것입니다.

For starters, you need to add a source for 3rd party libraries.

우선, 타사 라이브러리용 소스를 추가해야 합니다.

repositories { 
    mavenCentral() 
}

The repositories block indicates that the build should resolve its dependencies from the Maven Central repository. Gradle leans heavily on many conventions and facilities established by the Maven build tool, including the option of using Maven Central as a source of library dependencies.

repositories 블록은 빌드가 Maven Central 저장소의 종속성을 해결해야 함을 나타냅니다. Gradle은 Maven Central을 라이브러리 종속성의 소스로 사용하는 옵션을 포함하여 Maven 빌드 도구에서 설정한 많은 규칙과 기능에 크게 의존합니다.

Now that we’re ready for 3rd party libraries, let’s declare some.

이제 타사 라이브러리를 사용할 준비가 되었으므로 일부 라이브러리를 선언해 보겠습니다.

sourceCompatibility = 1.8
targetCompatibility = 1.8

dependencies {
    implementation "joda-time:joda-time:2.2"
    testImplementation "junit:junit:4.12"
}

With the dependencies block, you declare a single dependency for Joda Time. Specifically, you’re asking for (reading right to left) version 2.2 of the joda-time library, in the joda-time group.

종속성 블록을 사용하여 Joda Time에 대한 단일 종속성을 선언합니다. 특히 joda-time 그룹에서 joda-time 라이브러리 버전 2.2(오른쪽에서 왼쪽으로 읽기)를 요청하고 계십니다.

Another thing to note about this dependency is that it is a compile dependency, indicating that it should be available during compile-time (and if you were building a WAR file, included in the /WEB-INF/libs folder of the WAR). Other notable types of dependencies include:

이 종속성에 대해 주목해야 할 또 다른 점은 이것이 컴파일 종속성이라는 것입니다. 즉, 컴파일 시간 동안 사용할 수 있어야 함을 나타냅니다(WAR 파일을 빌드하는 경우 WAR의 /WEB-INF/libs 폴더에 포함됨). 다른 주목할만한 종속성 유형은 다음과 같습니다.

• implementation. Required dependencies for compiling the project code, but that will be provided at runtime by a container running the code (for example, the Java Servlet API).

• 구현. 프로젝트 코드를 컴파일하는 데 필요한 종속성은 코드를 실행하는 컨테이너(예: Java Servlet API)에 의해 런타임 시 제공됩니다.

• testImplementation. Dependencies used for compiling and running tests, but not required for building or running the project’s runtime code.

• 테스트 구현. 테스트를 컴파일하고 실행하는 데 사용되지만 프로젝트의 런타임 코드를 빌드하거나 실행하는 데는 필요하지 않은 종속성입니다.

Finally, let’s specify the name for our JAR artifact.
마지막으로 JAR 아티팩트의 이름을 지정해 보겠습니다.

jar {
    archiveBaseName = 'gs-gradle'
    archiveVersion =  '0.1.0'
}

The jar block specifies how the JAR file will be named. In this case, it will render gs-gradle-0.1.0.jar.

jar 블록은 JAR 파일 이름 지정 방법을 지정합니다. 이 경우 gs-gradle-0.1.0.jar을 렌더링합니다.

Now if you run gradle build, Gradle should resolve the Joda Time dependency from the Maven Central repository and the build will succeed.

이제 Gradle 빌드를 실행하면 Gradle은 Maven Central 저장소에서 Joda Time 종속성을 해결해야 하며 빌드가 성공합니다.

• implementation
  : 컴파일 타임과 런타임 모두에 걸쳐서 사용자에게 의존성을 부여하는 지시어이다.
  내부적으로만 사용되고 사용자에게는 의존성을 노출시키지 않게 선언한다.
  의존 라이브러리를 수정해도 직접적으로 사용하는 모듈까지만 재빌드한다.
  해당 모듈까지만 재빌드

• compile
  : 모든 모듈을 재빌드(D)
  deprecated 되었다.

• compileOnly
  : lombok과 같이 컴파일시에만 필요한 의존성을 명시할 수 있다.
  컴파일 할 때만 사용한다. 런타임에는 필요 없다.

• runtimeOnly
  : 런타임에만 필요하다.
  DB 연동할 때 필요하다.

• annotationProcessor
  : 어노테이션으로 일하는 라이브러리.

• testImplementation
  : Test 할 때만 적용되며, 기본 작동 방식은 위와 동일하다.
  테스트 코드 수행할 때만 작동한다.

• api
  : 해당 모듈이랑 관계있는 모듈 재빌드
  곧 deprecated 될 것이다.

참고자료
https://spring.io/guides/gs/gradle
https://bnzn2426.tistory.com/136

Maven vs Gradle

차이점

1. 가시적: 빌드 스크립트(빌드 할 때 쳐다보는 파일)
   gradle: build.gradle
   아래 자료에서 gradle의 빌드 속도가 훨씬 빠른 것을 확인할 수 있다.
   https://gradle.org/maven-vs-gradle/

2. 느낄점: 속도 차이! "점진적 빌드"
   Maven: 5 + 1 = 6
   Gradle: 5 + 1 = 1
   Gradle은 처음에 빌드한 거를 기억하고, 다시 빌드할 때는 새로운 것만 빌드한다.

스프링 빈으로 등록하는 방법 2가지

우리가 직접 객체를 생성하는 대신, 스프링이 객체를 생성 등등
관리하고 요청

1. @Component
2. @Configuration + @Bean
   @Bean이라는 어노테이션이랑 같이 쓰면
   스프링이 기동되면서,
   @Bean이 붙은 모든 메소드 호출
   : C 1, S 2, R 3 만들어 질 것 같은데..?
   : "아니네.. 싱글톤이네..?"

스프링은 (기본적으로) 스프링빈을 등록할 때 "싱글톤" 패턴을 따릅니다.

default 최대한 건드리지 않는 것

1. @Configuration은 스프링이 어떻게 찾아낸 것일까?
2. 그게 아니라 저 어노테이션도 비밀이 있을 것이다.

1. main 클래스가 실행될 때, ComponentScan이 모든 Component를 스캔한다.
2. @Component인 클래스들이 잡힌다.

😉 앞으로 이걸 해봐야지

스프링 프로젝트를 위한 빌드 프로세스와 스프링에서 객체를 관리하는 방법에 대해 배우게 되었다. 앞으로도 IntelliJ에서 어떻게 빌드를 처리하는지 상세히 알아보고 내가 짠 코드가 어떻게 프로그램이 되는지 확인해볼 것 이다. 또한, 스프링에서 생성한 객체들이 어떻게 관리되는지 확인하였고, 스프링 내부적으로 어떠한 프로세스로 관리 프로세스가 동작되는지 확인해보고 싶다.