기본 콘텐츠로 건너뛰기

글

2022의 게시물 표시

Javascript: this 키워드

1. Javascript의 this 키워드도 대체로 자기 자신(객체)을 가리킨다 보통 Java 같은 객체지향 언어에서 this 가 가리키는 대상은 this 을 선언한 해당 메서드를 수행 중인 자기 자신(객체)이다. Javascript 에서 this 는 이와 비슷한 역할을 한다. 우선, 기본적으로 Javascript 의 this 키워드는 다른 객체지향 언어와 마찬가지로 this 가 선언된 메서드를 수행 중인 객체를 가리킨다. function person ( ) { this . name = '강아무개' ; //person클래스의 생성자 메서드에서 선언. 즉, 생성자를 통해 생성할 person 객체를 가리킨다. } //ES6 문법에서 등장한 class 선언 문법 class person { constructor ( ) { this . name = '강아무개' ; //마찬가지로 this는 새로 생성할 person 객체를 가리킨다. } } 2. Javascript this를 메서드 블록 밖에서도 사용할 수 있다 Javascript에서의 this 는 특별하다. 자신의 객체를 가리키는 this 의 용도상 메서드 선언 블록에서만 this 를 사용해야 하는 게 보통의 언어지만, Javascript는 this 를 사용자 코드 어디에서든지 사용이 가능하다. 메서드를 포함한 모든 종류의 함수 내부에서 사용되며, 함수 밖 전역에서 단독으로 사용될 수도 있다. 2.1. 함수 내부에서 사용된 this 키워드 함수 내부에서 사용된 this 키워드는 호출 형태에 따라 참조하는 값이 달라진다. 2.1.1. 객체의 메서드로서 호출될 때 this 는 함수가 어떤 객체의 메서드로서 호출될 때, 해당 객체를 참조한다. ES6의 클래스 문법 또는 리터럴 방식으로 메서드를 선언할 수 있다. 메서드로 선언되지 않은 함수들도 동적으로 임의의 객체에 메서드로 할당될 수 있다. Javascript의 객체는 메서드를 프로퍼티로 가...

알고리즘의 자바 솔루션에서 GC로 인한 메모리 초과를 방지하는법

1. 자바 솔루션에서 메모리 초과가 나는 이유 1.1. 메모리 누수? 먼저, 메모리 누수 는 아니다. 메모리 누수는 고려하지 않는다. 알고리즘 문제는 대게 메모리 요구사항이 있고 메모리 요구사항은 GC 가 돌아가는 조건에 한참 못미친다. 애초에 후술하겠지만 GC 가 수행도중에 돌아가서도 안된다. GC 가 돌아가지 않으니 해당 솔루션이 메모리 누수가 나는 설계를 하였다고 하여도 메모리 초과의 직접적인 원인이라 할 수 없다. 그러나 현업에서는 GC 가 비정상적인 상황이 아니며, 따라서 현업 앱 설계에는 메모리 누수에대한 고려가 필요하다. 1.2. 주요 2가지 원인 경험상 크게 2가지 이유가 있다. 문제에서 요구하는 공간 복잡도를 만족시키지 못한 경우. 이런 경우는 오히려 알고리즘의 재설계를 통해 쉽게 해결될 수 있다. 문제 해결이 쉽다. 공간 복잡도는 만족했지만 GC가 제때 되지 않아 메모리 초과가 나는경우 대게 자바는 2번 이유로 메모리 초과가 나는경우가 많다. 알고리즘의 공간 복잡도를 따져보면 조건을 만족하지만, 메모리 초과가 뜨는 경우이다. System.gc() 를 코드 중간에 삽입해서 강제로 gc를 돌려주면 메모리 요구사항을 만족하는 것을 확인할 수 있다. 2. GC 강제로 돌리기 System.gc() 는 강제로 GC 를 수행시켜주는 시스템 메소드이다. 이 메소드를 Unreachable Object 가 생기는 시점마다 강제로 호출시켜주면 C 언어의 malloc() 동적할당 변수에 free() 를 써준 것처럼, 즉시 모든 Unreachable Object 들의 메모리가 해제된다. 이렇게 강제로 GC 를 돌려주면 알고리즘이 자신이 가진 공간복잡도를 온전히 발휘하여 문제의 메모리 요구사항을 만족시킬 순 있다. 하지만, GC 는 기본적으로 시간이 오래 걸리는 연산이다. c 언어의 free() 와는 다르게 GC는 그 대상을 명시해서 사용하지 않는다. GC는 스스로 자신이 해제시켜야할 Unreachable Object 들을 찾아야하며...

JVM에서 가장 빠른 비교연산자

1. 비교연산자의 구분 Equal과 Less, Greater Equal과 not Equal은 not을 하나 추가, 1클럭 차이나므로 어떤 CPU에서도 연산속도가 같을 수 밖에 없다. 이와 동일하게 < 는 not >=와 같고 > 는 not <=과 같다. 그렇다면 CPU연산에서 속도가 같을 수밖에 없는 다음 3가지 그룹이 나오게 된다. == , != < , >= > , <= 일단 결론부터 말하자면, **==**과 **!=**이 현저히 느리고 나머지 비교연산은 동등하게 빠르다. 2. 테스트 나중에 이어쓰기 3. 이유 나중에 이어쓰기

가장 빠르게 시스템 출력 스트림에 쓰는법

1. 시스템 출력 스트림 객체에 직접 접근. 시스템 출력 스트림 객체에 System.out 을 통해 직접 접근해서 사용한다. 내가 필요한 기능만 사용 가능하므로, 다른 데코레이터 클래스를 사용해서 생기는 불필요한 작동으로 인해 소모되는 시간과 메모리를 절약할 수 있다. 2. 출력 버퍼를 쓰기 시스템의 출력 스트림에 데이터를 쓰는 작업은 언제나 시간이 소모되는 작업이다. 따라서 데이터를 하나하나 써가는 것 보다는 버퍼에 한번에 쓰고 출력 스트림에 버퍼를 한번에 쓰게하는 편이 훨신 빠르다. 3. 예제 코드 byte [] outBuf = new byte [ 1024 ]; //1024바이트의 버퍼 //outBuf에 직접 값을 입력 예제. for ( int i= 0 ;i< 1024 ; i++){ outBuf[i] = 'a' ; //전부 a로 채워 넣기 } System.out.write(outBuf);

가장 빠르게 정수와 문자열 입력을 받는법

이 포스팅은 가장 빠른 정수 입력 받기 포스팅의 연장이다. 1. 정수와 문자열 입력이 모두 존재할때 빠르게 입력받는 법 정수와 문자열이 입력으로 함께 존재하는 문제에서는 정수 입력용 커스텀 메소드를 쓰기가 까다롭다. 문자열 처리용으로 자바 입력 라이브러리를 함께 쓴다면 라이브러리와의 미묘한 처리방식 차이로 스트림에 특수문자(특히 \n나 \r)가 남아 원하지 않는 결과를 만들게 된다. 기왕 이렇게된거 문자열까지 커스텀 메소드로 작성하여 더욱 빠르게 처리하는게 좋다. 정수 입력 커스텀 메소드도 문자열 입력 커스텀 메소드가 혹시라도 남길 공백 및 개행문자를 처리하기위해 특별한 로직 필요하다. 2. 문자열 입력 커스텀 메소드 private static String readStr ( int bufSize) throws IOException{ byte [] bytes = new byte [bufSize]; int i= 0 ; while ( true ) { int input = System.in.read(); if (input != '\n' && input != '\r' && input != ' ' ) { bytes[i++] = ( byte )input; break ; //앞 공백 제거 후 시작. } } while ( true ) { int input = System.in.read(); if (input == '\n' || input == '\r' ) { return new String (bytes, 0 , i); } else bytes[i++] = ( byte )input; } } 문자열앞에 개행(운영체제별 개행방법 모두 고려)과 공백이 연속해서 존재할 경우도 고려. 운영체제 또는 입력 인코딩에 따라 메소드 종료 후에 I...

가장 빠르게 정수 입력 스트림 읽는법

1. 빠른 정수 입력 스트림 읽기의 필요성 백준 알고리즘 문제를 풀다보면 정수로 구성된 일련의 데이터 를 받아서 처리해야할 때가 있다. 백준은 입력과 출력 시간도 알고리즘 수행시간에 포함되다 보니 입, 출력 시간 절약이 아주 중요하다. 사람들이 입력 스트림을 읽는 방법은 크게 4 가지 이다. Scanner 사용 BufferedReader 사용 사칙연산 을 사용하는 커스텀 메소드 사용 비트연산 을 사용하는 커스텀 메소드 사용 이중 가장 빠른 것은 사칙 연산 을 사용하는 커스텀 메소드 이다. 각 방법을 빠른 순으로 나열하면 사칙연산 사용 커스텀 메소드 비트연산 사용 커스텀 메소드 BufferedReader Scanner 커스텀 메소드 들의 성능은 거의 같다. BufferedReader 는 커스텀 메소드 의 두배정도 걸린다. Scanner 는 BufferedReader 의 두 배이상 걸린다. 테스트 수행 결과 2. 각 방법의 코드 및 사용법 2.1. Scanner 클래스 임포트 import java.util.Scanner; 객체 생성 및 정수 입력 스트림 읽기 Scanner sc = new Scanner (System.in); //생략 sc.nextInt() //생략 sc.close(); 2.2. BufferedReader 클래스 임포트 import java.io.BufferedReader; import java.io.InputStreamReader; import java.util.StringTokenizer; 객체 생성 및 정수 입력 스트림 읽기 BufferedReader br = new BufferedReader ( new InputStreamReader (System.in)); //생략 //한줄에 여러개의 입력 정수가 공백 하나를 기준으로 나뉘어서 들어올때 StringTokenizer st = new ...

@HotSpotIntrinsicCandidate을 활용한 성능 향상

1. @HotSpotIntrinsicCandidate 역할 1.1. HotSpot에서 내장 함수로 치환될 수 있는 JDK의 정적 메소드들을 표시 HotSpot JVM 에서는 최적화 기법중 하나로 JDK 의 일부 정적 메소드 들에 대한 고성능의 내장 함수(intrinsic function) 1 들을 제공한다. JDK 9 부터 등장한 @HotSpotIntrinsicCandidate 은 JDK 의 특정 메소드들이 HotSpot 의 내장 함수 로 치환될 수 있음을 나타낸다. 표시를 할뿐, 실제로 @HotSpotIntrinsicCandidate 를 통해 javac 의 Annotation Processor 가 내장 함수 또는 네이티브 코드 로 변환해주는 기능은 없다. 해당 기능은 JIT 의 역할이기 때문이다. 1.2. JDK 사용자가 HotSpot의 내장함수 기능을 최대한 활용 할 수 있게 함 JDK 를 활용한 개발을 할때, 개발자는 별도의 스펙을 찾아보지 않고 정적 메소드 상단의 @HotSpotIntrinsicCandidate 의 유무만 보고도 Hotspot 의 내장 함수 기능을 제공 받는지를 알 수가 있다. 따라서 개발자는 코드에 @HotSpotIntrinsicCandidate 가 선언된 정적 메소드 로 대체 가능한 코드는 최대한 대체시켜서 HosSpot JVM 에 최적화된 프로그래밍이 가능하다. HotSpot JVM 은 기본 JDK 배포에 포함되는 JVM 의 표준이므로 해당 어노테이션을 활용한 최적화된 프로그래밍에 익숙해져야 한다. 2. @HotSpotIntrinsicCandidate은 Internal 하다 @HotSpotIntrinsicCandidate 은 JDK 의 코어 라이브러리에서만 선언 가능하고 사용자 코드 에서는 선언이 불가하다. @HotSpotIntrinsicCandidate 의 선언은 오로지 JDK 을 만들고 배포하는 개발자 및 개발사들이 고려해야할 사항이다. The {@code @HotSpotIntrinsicCandidate} ann...

IoC(Inversion of Control)

1. IoC 소개 IoC(Inversion of Control), 제어의 역전 소프트웨어 설계**에서의 프로그래밍 원칙 으로, 프레임워크 에서 정의된 **제어의 흐름(flow of Control)**을 사용, 프레임워크 가 사용자 정의 코드 를 필요에 따라 호출하여 사용하게 한다. 기존 절차적 프로그래밍 에서의 제어의 흐름 과 비교하면 **제어가 역전**되었다. 1.1. 제어의 역전 기존 절차적 프로그래밍 에서는 어떤 작업을 처리하기 위해 사용자 정의 코드 에 제어의 흐름 (선언과 반복 및 분기문, 함수와 재사용가능한 라이브러리 호출등의 절차)을 사용자가 직접 정의하던 방식과 비교해서 IoC 원칙에 따른 설계는 프레임워크 가 작업을 수행하기 위해 프레임워크 에 정의되어있는 제어의 흐름 대로 프로그램을 수행, 필요에 따라 사용자 정의 코드 를 (마치, 재사용 라이브러리를 사용하듯)호출하게 된다. 즉, 제어의 흐름 이 사용자에게서 프레임워크 로 넘어가게 되었고 이를 제어의 역전 이라고 말한다. 2. OOP에서의 IoC 객체 지향 프로그래밍 에서 **IoC(Inversion of Control)**은 프로그래밍 원칙 으로, 모든 객체들에 대한 제어 를 제어 만을 담당하는 특별한 객체 가 하는 형태이다. 2.1. OOP의 제어(Control) 객체 들에 대한 제어 란, 간단히 말해, 객체 들의 생성 과 메소드 호출 , 소멸 등 과 같은 생명주기 를 관리하는 것을 말한다. 2.2 DI(Dependency Injection) DI(Dependency Injection), 의존성 주입 은 객체 지향 프로그래밍 에서의 IoC의 구현 인 디자인 패턴 이다. DI 패턴 에서 모든 객체는 자신이 의존성을 가지는 다른 객체에 대한 참조를 외부 코드인 Injecter 로 부터 주입 받는다. 객체는 자신이 의존성 을 가지는 다른 객체들의 생명주기 에 관여할 수 없다. 즉, 커스텀 클래스 내부에서는 다른 객체의 생성 및 초기화나 소멸 시기를 독립적으로 지정할 수가 ...

Dependency Injection(의존성 주입)

1. 의존성 주입 의 정의 의존성 주입 ( Dependency Injection , DI )은 어떤 객체 나 함수 가 자신이 의존 하는 객체 나 함수 를 전달 받는 디자인 패턴 이다. 1.1. 의존성 과 의존 어떤 객체 나 함수 A 가 다른 객체 나 함수 B 를 의존 한다는 것은 A 자신이 제공하는 서비스 에서 B 에 대한 참조를 사용한다는 것을 의미한다. 또한, A 가 B 를 의존 하는 성질을 해당 B 에 대한 의존성 이라 한다. Primitives are dependencies https://blog.ploeh.dk/2012/07/02/PrimitiveDependencies/ 1.2. 서비스 서비스 는 객체 나 함수 를 포함하는 모듈 이 제공하는 비즈니스 로직 을 뜯한다. 단위 메소드가 될수 있고, 서로 다른 클래스 혹은 인스턴스의 여러 메소드와 함수의 결합이 될 수도 있다. 2. 의존성 주입 의 목적 서로 의존성 이 있는 모듈 간의 결합도 를 낮춘다. 2.1. 모듈 하나 이상의 서비스 를 제공하는 프로그램 임의의 단위. 2.1. 결합도 서로 다른 모듈 간의 상호 의존 하는 정도, 연관된 관계를 나타낸다. 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도 등이 있다.

Spring Web MVC Controller 구현

1. Controller 사용자 입력을 해석하고 뷰를 통해 사용자에게 출력되어지는 모델로 변환해준다. 2. 컨트롤러 작성법. 2.1. Annotaion 기반 프로그래밍 모델 Spring 2.5 부터 등장. *RequestMapping 1. @Controller annotation 사용 해당 클래스위에 @Controller Annotaion을 선언한다. 2. Annotation 안쓰고 Controller 선언하는 법 해당 Controller 클래스가 org.springframework.web.servlet.mvc.Controller 인터페이스를 구현하면 된다. 3. ModelAndView 페이지 리턴 메소드 ModelAndView 객체 생성 addObject()로 전달할 객체 추가. setViewName()으로 전달될 view 지정.

빌드 자동화 도구 개요

1. 빌드 자동화 도구란? Build Automation Utility(빌드 자동화 도구) 프로젝트 빌드 및 배포 과정에서 단순하고 반복적인 작업을 자동화해준다. 2. 주요 빌드 자동화 도구 2.1. Make C 로 작성된 빌드 자동화 도구 . Unix 계열 OS 에서 사용됨. 다양한 Make 파생들이 존재함. SunPro Make Distributed Make(dmake) BSD Make pmake bmake fmake GNU Make(gmake) Glenn Fowler's nmake Microsoft's' nmake MK 2.2. Ant Java 기반 빌드 자동화 도구. 아파치 재단 의 오픈소스 프로젝트 이클립스 에 내장됨. 별도의 설치 없이 Ant 프로젝트 생성 가능. 가장 오래된 자바 프로젝트 빌드 자동화 도구 XML 문법을 사용 2.3. Maven Java 기반의 빌드 자동화 도구 Ant 의 단점들을 해소하고 자동화 수준을 높힌 Java 기반 빌드 자동화 도구 아파치 재단 의 오픈소스 프로젝트 XML 문법 사용 2.4. Gradle Java 기반의 빌드 자동화 도구 Maven 보다 빌드 속도가 훨신 빠름. 안드로이드 프로젝트 의 빌드 자동화 도구로 유명. JVM 에서 동작하는 동적 타입언어인 Groovy 문법을 사용.

trimDirectiveWhitespaces 설정을 통한 JSP Page 응답 소스의 최상단 공백 제거

1. JSP Page 응답 소스의 최상단에 공백이 발생하는 이유. 각 디렉티브 들은 보통 JSP 페이지 소스 의 최상단에서 가독성 을 위해 그 뒤에 줄바꿈 문자 를 삽입하여 줄바꿈을 하게된다. 그렇게 쓰여진 줄바꿈 문자 는 JSP 컨테이너 가 servlet 으로 변환하는데도 그대로 남게되어 그대로 변환된 서블릿 의 응답에 포함되게 되는 것이다. 또한, JSP 페이지 소스 최상단이 아닌 곳에서 사용되는 Directive 들도 출력은 고려안하고 가독성만을 위해 줄바꿈 문자 를 사용한다면 똑같은 결과를 얻게 된다. 2. Page Directive의 trimDirectiveWhitespaces 속성. Page Directive 의 trimDirectiveWhitespaces 속성은 해당 JSP Page 의 응답에서 공백으로만 이루어진 템플릿 택스트 들을 제거한다. 이는 페이지 최상단의 디렉티브 들이 만들어낸 공백 템플릿 택스트 들을 제거하여 최상단의 공백을 제거하는데 효과적이다. 다만, 페이지 에 존재하는 모든 공백 템플릿 텍스트 가 응답에서 제거되어 원하지 않은 출력 결과가 나올 수 있기에 사용에 유의해야 함. 3. trimDirectiveWhitespaces 속성 값에 따른 응답 html 파일 비교. 3.1. trimDirectiveWhitespaces가 false인 경우. 속성값으로 false 를 명시 혹은 기본값 인 사용. <%@ page trimDirectiveWhitespaces="false"%/> JSP 소스파일 <%@ page language="java"%> <%@ page contentType="text/html; charset=EUC-KR"%> <%@ page pageEncoding="EUC-KR"%> <!DOCTYPE html > < html > < head > ...

Page Directive 개요

1. Page Directive JSP Page 의 종속 속성들을 정의하고 JSP 컨테이너 에 전달하는 역할을 함. jsp 기본 템플릿 에 포함. 필수적 이다. <%@ page language="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%> 2. Page Directive 문법 <%@ page page_directive_attr_list %> page_directive_attr_list ::= { language= "scriptingLanguage" } { extends= "className" } { import= "importList" } { session= "true|false" } { buffer= "none|sizekb" } { autoFlush= "true|false" } { isThreadSafe= "true|false" } { info= "info_text" } { errorPage= "error_url" } { isErrorPage= "true|false" } { contentType= "ctinfo" } { pageEncoding= "peinfo" } { isELIgnored= "true|false" } 2.1. language attribute <%@ page language="java"%> 필수적으로 정의하는 속성. 스크립트릿 , 표현식 , 선언 에서 사용하는 스크립트 언어 를 정의. Defines the scripting language to be used in the...

STS 개요

1. STS(Spring Tool Suite)란? Spring 개발툴. 이클립스 기반의 IDE였었다( STS 3 이전). 지금은 다른 IDE에 설치하여 사용 가능하다. 2. STS3 vs STS4 STS 는 현재 STS 4 가 최신 최신버전 링크 : https://spring.io/tools STS 3 에서 STS 4 로넘어가면서, 여러 이유로 STS 3 가 Deprecated 됨. STS 4 부터는 IDE agnostic . STS 3 까지는 이클립스 기반 이기에 완성된 STS 를 직접 다운받거나 이클립스 에 필요한 구성요소를 다운받아 사용 가능함. STS 4 부터는 다른 IDE 에서도 필요한 구성요소를 다운받아 STS를 구성할 수 있게 함. The Spring Tool Suite 3 is the previous generation of the Spring tooling for the Eclipse IDE. The Spring Tool Suite distribution was based on the Eclipse JEE package and included the Spring IDE components, the tc Server integration for Eclipse, and various other pre-installed plugins for the Eclipse IDE. With the release of the all-new Spring Tools 4, the Spring Tool Suite 3 got deprecated and is no longer under active development. Instead, users of the Spring Tool Suite 3 are highly encouraged to migrate to the all-new Spring Tools 4: https://spring.io/tools . Even though the new Spring Tools 4 are IDE-agno...

JSP 개요

1. JSP 란? JavaServer Page 기술은 동적으로 웹 콘텐츠 ( HTML , DTHML , XHTML , XML )을 생성하는 Java EE 의 기술이다. JSP page는 Servlet 이랑 역할이 겹치지만 JSP page 는 일종의 text-based Document 라는 점이 다르다. JSR 245 에 기술 스펙 정의. 마지막 버전 PDF : JSP 2.3 spec 마지막인 이유는 Jakarta EE 참조 2. JSP page의 구성 JSP 페이지는 element 들과 templete data 로 구성. element JSP container 가 아는 element type 들의 인스턴스, JSP translator 가 해석 가능. templete data element 가 아닌것들, JSP translator 가 해석 불가. JSP page has elements and template data. An element is an instance of an element type known to the JSP container. Template data is everything else; that is, anything that the JSP translator does not know about. -JSP 2.3 spec-

JSP Access Model 개요

1. JSP Access Model이란? JSP를 사용해 Java Web Application를 설계하는 2가지의 디자인 패턴이다. 1998년 썬 마이크로시스템즈 에서 발표한 JSP 0.92 기술 스펙 에서 제시되었다. Model 1 과 Model 2 로 구성된다. 1.1 JSP Access Model이 공통적으로 가지는 특징 JSP 파일은 처음 요청이 들어순간 어떤 객체 로 컴파일 되어 서버 메모리에 올라감. 클라이언트 브라우저, Java Servlet 등이 JSP 파일에 요청을 보낸다. 메모리상의 객체 는 클라이언트로의 응답으로 HTML 파일을 보냄. 서버는 JSP 파일에 변동이 있는지 확인, 변동이 있다면 메모리상의 객체 를 새로 컴파일한 객체 로 바꿈. 2. Model 1 "요청이 JSP 파일로..." 클라이언트의 웹 브라우저가 직접 JSP 파일에 요청을 보냄. 동적 콘텐츠를 JavaBeans 가 생성. JSP 파일은 클라이언트의 요청을 받아 JavaBeans 의 동적 콘텐츠를 가져와서 표시함. JavaBean 은 Enterprise JavaBean 또는 DB 로부터 정보를 요청하여 동적 컨텐츠를 생성. 3. Model 2 "요청이 Java Servlet 으로..." 클라이언트의 웹 브라우저가 Java Servlet 으로 요청을 보냄. 동적 콘텐츠를 Java Servlet 이 생성. Java Servlet 은 JDBC 를 통해 DB 로부터 정보를 얻어서 동적 콘텐츠를 생성. Java Servlet 는 동적 콘텐츠를 JavaBeans 로 래핑함. JSP 파일은 JavaBean 으로부터 동적 콘텐츠를 가져와서 표시함.

Model 2 구조의 자바 웹 어플리케이션 개발

1. Model 2 패턴? 2. 응집도는 높게, 결합도는 낮게! MVC 패턴은 소프트웨어의 모듈화방법중 하나이다. 좋은 모듈화는 응집도가 높고 결합도가 낮다. 2.1 낮은 결합도 2.1.1. 인터페이스 기반으로 확장이 용이한 형태로 제작 controller 클래스들의 모든 공통 기능을 상위 추상 클래스, 인터페이스로 넘김.

Directive 개요

1. Directive란? JSP 페이지 에 작성된 JSP 컨테이너 에 보내는 메시지. JSP 컨테이너 가 JSP 페이지 를 Servlet 으로 컴파일하는데 필요한 정보들을 명시한다. 2 Directive의 기본 문법. <%@ directive {attr="value"} %> 3 Directive의 종류. Page Directive : JSP 컨테이너 에서 필요한 JSP 페이지 의 종속 속성들을 정의하는데 사용됨. <%@ page language="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%> 관련 게시글 : Page Directive 개요 . Include Directive : JSP 페이지 내부에 또 다른 JSP 페이지 를 포함시키기 위해 사용. Taglib Directive : JSP 페이지 에서 사용할 태그 라이브러리 를 지정. 4 Directive의 기술 스펙 JSP 기술 스펙 ( JSR-245 )에 기술. 현재는 Java EE 8의 JSP 2.3버전이 최신이다.[ Jakarta EE ]

Jakarta EE 개요

1. Jakarta EE, Java EE의 새 이름 Jakarta EE 는 Java EE 가 이클립스 재단으로 이관되면서 붙여진 새 이름이다. Java EE 로 불리기 이전에는 J2EE 로 불리던 때도 있었다. 2. Jakarta EE의 이름 변천사. 1999년: 썬 마이크로시스템즈 에서 J2EE 명으로 발표. 2006년: Java EE 5 부터 Java EE 로 개칭. 2010년: 오라클 의 썬 마이크로시스템즈 인수. 2013년: 오라클 , 인수 후 첫 버전인 Java EE 7 발표. 2017년: 오라클 , Java EE 8 발표 후 Java EE 를 이클립스 재단 에 이관. 이클립스 재단 의 EE4J 라는 프로젝트로 기존 Java EE 8 의 기술들을 이식하고 오픈소스로 관리하기 시작. https://projects.eclipse.org/projects/ee4j 2018년: 이클립스 재단 , 설문을 통해 플렛폼의 새 이름과 기술명을 Jakarta 로 결정. 2019년: 이클립스 재단 , Java EE 8 과 완벽 호환되는 Jakarta EE 8 발표. 2020년: 이클립스 재단 , Jakarta EE 9 발표, API 네임스페이스를 javax. 에서 jakarta. 으로 변경. 3. 왜 이클립스 재단은 이름을 변경해야 했을까? 오라클 은 Java EE 를 이클립스 재단 에 이관했지만 여전히 Java 에 대한 상표권을 소유하고 있어 이클립스 재단 측은 Java 라는 이름을 가지고 새로운 기술을 발표할 수가없었다. 따라서, 투표를 통해 새 이름을 지정(2019), 새 플랫폼과 기술 이름을 Jakarta 로 변경하기로 결정하고 새 기술이 등장하는 Jakarta EE 9 부터는 javax. 네임스페이스를 비슷한 느낌의 jakarta. 로 변경할 수 밖에 없었다. 4. Jakarta EE만의 차별점. Jakarta EE 는 Java EE 의 오픈소스 버전. 이클립스 재단 에 이관되면서 모든 Java 네임스페이스가 Jaka...

JSTL 개요

1. JSTL 이란? 많은 JSP 응용에서 보편적으로 사용되는 기능들을 캡슐화한 커스텀 태그 라이브러리. JSP 표준 태그 라이브러리 ( JavaServer Pages Standard Tag Library ). 현재 가장 마지막 버전은( Java EE 8 에 사용) Java EE 5 에 등장한 JSTL 1.2 . 공식 링크 : https://www.oracle.com/java/technologies/jstl.html . Jakarta EE 8 부터는 기술이름이 Jakarta Standard Tag Library 로 변경됨. Jakarta EE 8 : JSTL 1.2 Jakarta EE 9 : JSTL 2.0 Jakarta EE 10 (최신) : JSTL 3.0 공식 링크 : https://jakarta.ee/specifications/tags/ 2. JSTL의 구성(JSTL 1.1버전 이상) Core 기능 : 변수 지원, 흐름 제어, URL 관리 등등. prefix : c uri : http://java.sun.com/jsp/jstl/core XML 기능 : XML 처리 기능, XML 흐름 제어, XML 번역. prefix : x uri : http://java.sun.com/jsp/jstl/xml Internationalization uri : Locale 기능, 메시지 포매팅, 숫자 및 날짜 포매팅. prefix : fmt uri : http://java.sun.com/jsp/jstl/fmt Database 기능 : DB와의 연결, SQL을 통한 DB작업들을 처리. prefix : sql uri : http://java.sun.com/jsp/jstl/sql Functions uri : Collection 의 길이를 반환, String 조작. prefix : fn uri : http://java.sun.com/jsp/jstl/functions 3. J...

EL 개요

1. EL이란? Expression Language 은 JSF 와 JSP 에서 JavaBeans 의 동적 콘텐츠에 접근할 수 있는 간결한 표현식이다. 1.1 EL의 특징 기본적으로 ${expr} 또는 #{expr} 구분자를 통해 나타낸다. JSP page의 Action Elements 와 Template Data 에서 사용. 표현식의 Deffered Evaluation (지연된 평가)와 Immediate Evaluation (즉시 평가) 기능을 제공. 표현식에서 JavaBeans 의 데이터를 get하거나 set가능. 표현식에서 메소드를 호출가능. 1.2. EL의 역사 ECMAScript 와 XPath 의 영감을 받음. JSP 1.2 의 JSTL 1.0 스펙의 일부로 JSTL 액션 의 속성 값을 런타임에 입력하는 간결한 문법으로써 EL 이 처음 등장. " JSTL 1.0 의 EL 은 오직 JSTL 액션 에서만 사용 가능했다" The JSP Standard Tag Library (JSTL) version 1.0 (based on JSP 1.2) was therefore first to introduce an Expression Language (EL) to make it easy for page authors to access and manipulate application data without having to master the complexity associated with programming languages such as Java and JavaScript. JSP 2.0 부터는 별도의 기술로 JSP 스펙에 포함 되었으며, JSP 컨테이너 스스로가 EL 표현식을 해석, JSTL 액션 이외의 커스텀 액션 , 템플릿 데이터 에서도 사용 가능해짐. " JSP 2.0 부터 기술 스펙에 등장한 EL 은 JSP 의 모든 부분에서 사용 가능하다" Given its succe...

Java EE 개요

1. Java EE란? Java Enterprise Edition 기업용 분산 어플리케이션 개발 목적의 산업 표준 플렛폼. Java SE 의 확장. Web Profile (JSP, Servlet등 웹 어플리케이션 서버에 관련된 사양)이 포함된다. 2. Java EE의 기술들(Technologies) 마지막 버전인 Java EE 8 의 기술목록, 오라클 공식 문서 참조 더 이상의 업데이트는 없다. 이유는 Jakarta EE 포스트를 참조. 2.1 웹 어플리케이션 기술들 WebSocket 1.1 JSON Binding 1.0 JSON Processing 1.1 Java Servlet 4.0 JavaServer Faces( JSF ) 2.3 Expression Language( EL ) 3.0 JavaServer Pages( JSP ) 2.3 Standard Tag Library for JavaServer Pages( JSTL ) 1.2 2.2 엔터프라이즈 어플리케이션 기술들 Batch Applications for the Java Platform 1.0 Concurrency Utilities for Java EE 1.0 Contexts and Dependency Injection for Java 2.0 Dependency Injection for Java 1.0 Bean Validation 2.0 Enterprise JavaBeans 3.2 Interceptors 1.2 Java EE Connector Architecture 1.7 Java Persistence 2.2 Common Annotations for the Java Platform 1.3 Java Message Service API 2.0 Java Transaction API (JTA) 1.2 JavaMail 1.6 2.3 웹 서비스 기술들을 Java API for RESTful Web Services (JAX-RS) 2.1 ...