기본 콘텐츠로 건너뛰기

글

10월, 2022의 게시물 표시

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 ...

JQuery 개요

1. JQuery란? JavaScript 라이브러리 *$*키워드를 통해 Dom 요소 의 접근과 수정을 용이하게 한다. 이벤트 핸들링 을 용이하게 한다. AJAX 구현 API 제공, AJAX 통신을 용이하게 한다. 2. Vanilla-JS VS JQuery 2.1. Dom요소의 접근 비교 #title 요소에 대한 접근 Vanilla-JS document.getElementById("title"); JQuery $("#title"); 2.2. 이벤트 핸들링 비교 숨겨진 #message 요소가 #button 요소를 클릭했을때 보여지게 하기. Vanilla-JS var hiddenMsg = document.getElementById("message"); document.getElementById("button").onClick = function() { hiddenMsg.style.display='block'; }; JQuery var hiddenMsg = $( "#message" ); $( "#button" ).on( "click", function( event ) { hiddenMsg.show(); }); 2.3. AJAX 통신 비교 비동기로 https://rkdgusrn1212.github.io/ 에서 get 요청으로 텍스트를 받아와 #content 요소에 넣기. Vanilla-JS var request = new XMLHttpRequest(); request.open("GET", "https://rkdgusrn1212.github.io/"); request.send(); request.onreadystatechange = function() { if ( request.readyState === 4 && request.st...

Jekyll 정적 사이트 생성기

Jekyll 이란? Jekyll *(지킬)*은 Ruby 언어로 작성된 정적 사이트 생성기이다. Jekyll 은 특히 Github 의 정적 웹 호스팅 서비스인 Github Pages 에서 유용한데, Github Pages 에는 Jekyll 이 내장되어 있어서, Jekyll 을 활용하면 Github Pages 에서의 사이트 구축과 포스팅이 훨신 빠르고 간편해진다. Jekyll의 특징 DB를 안쓴다. 따라서 댓글 기능이 없다. 또한 모든 페이지가 HTML파일로 서버에 존재한다. 프로젝트 폴더의 _posts 폴더에 각 게시글을 나타내는 Markdown 문서를 유지한다. 각 Markdown 문서는 빌드 후 웹 서버 루트 디렉토리인 _site 의 하위 경로에 페이지를 구성하는 모든 레이아웃 요소가 적용된 하나의 완성된 HTML 문서로 저장된다. Liquid 문법을 통해 컨텐츠의 동적 로드를 구현 게시글에 미리 Markdown으로 작성할 수 없는 동적인 콘텐츠를 추가하려고 한다면 Markdown문서에 Liquid 템플릿 언어를 사용하여 서버 런타임에 동적인 콘텐츠를 로드하도록 할 수 있다. Liquid로 작성한 구문은 빌드 시 동적으로 HTML을 변경하는 스크립트를 생성한다. 테스트용 웹 서버 기능 제공. Jekyll serve --host SERVER*IP(default는 127.0.0.1) --port SERVER_PORT (default는 4000) 를 하면 프로젝트를 빌드하면 생성되는 *_site_ 디렉토리를 루트 디렉토리로 하는 정적 웹 서버를 구동시킨다. 그러나 언제까지나 테스트용 서버라는 것을 명심해야 한다. 다른 ip에서 접근하기 위해선 server_ip를 루프백이 아닌 외부에서 접근 가능한 ip로 설정해주고, 포트 방화벽을 해제 시켜줘야한다. Jekyll의 작동 원리 Jekyll 프로젝트를 생성한다. Jekyll 은 Ruby Gem 으로 Ruby 환경에서 설치가 가능하다. YAML 으로 작성된 프로젝트 설정파일...