서비의 다락방

With Java < 8, you would need to write something like:

Calendar cal = Calendar.getInstance();
cal.set(Calendar.HOUR, cal.get(Calendar.HOUR) + 2);

vs. with Java 8:

LocalTime now = LocalTime.now();
LocalTime later = now.plus(2, HOURS);

The improvements are essentially on

• readability:
  • Calendar.getInstance() is not very well named: it is hard to tell which instance you are getting without reading the Javadoc. LocalTime.now() is quite self-describing: you get a time and it is now.
  • To offset a date, you call an offsetting method (plus) whereas with the Calendar API, you have to manually change the fields of the object (in this example, the hour) which is error prone.
• ease of use (see for example the table towards the bottom of this page for a comparison):
  • the Calendar API is complicated to use because it mixes concepts, such as a simple date (June 26th 2015) and an instant in time (June 26th 2015 at 10am UTC) - there isn't a class for the former concept
  • The new Time API has a clear separation between the various date/time concepts
• safety:
  • The Calendar API is not safe: nothing prevents you from writing cal.set(123, 2) which would throw a not-so-helpful ArrayOutOfBoundsException. The new API uses enums which solves that problem.
  • The new API uses immutable objects, which makes it thread safe.

Overall, the new API is significantly inspired from jodatime which has been the preferred Java Date API for quite some time now. You can also read this detailed comparison of Java (<1.8) date vs. JodaTime (most of it should apply to the Java 8 Date API).

참고 : http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

필요할때마다 검색하기 구찮아서 정리해 둠

IBM DB2를 가지고 개발할 일이 생겼다.
늘 하던대로 executeable-jar 형식으로 빌딩을 수행하는 메이븐 프로젝트를 구성하는데.. 으잉? DB2의 jdbc 드라이버 db2jcc4.jar가 메이븐센트럴에 등록되어있지 않는것이다. 뭐지.. 이건?
회사 넥서스에 등록하고 땡겨쓰면 되긴 하지만 넥서스같은 로컬 메이븐 레파지토리가 없는 환경에서 이런경우는 어떻게 해야하는지 궁금했다.
귀찮겠지만 빌드하고 라이브러리 폴더에 jar를 복사해도 되긴하지만 문제는 POM파일에 기술되지 않으면 dependancy 관리가 안된다는것. 곧 IDE에서 클래스를 참조할 수 없다는 치명적인 문제가 발생한다.

이럴때를 대비해 메이븐은 dependencies.dependency.scope 속성 값으로 system을 제공하고 있고 <scope>system</scope> 를 사용한 경우 추가로 systemPath 속성을 정의할 수 있다.

이렇게 말이지..
[code xml]     <dependencies>
        <dependency>
            <groupId>ibm.db2</groupId>
            <artifactId>db2jcc4</artifactId>
            <version>10.5</version>
            <scope>system</scope>
            <systemPath>${basedir}/lib/db2jcc4.jar</systemPath>
        </dependency>
    </dependencies>
[/code]
이제, 코드를 짤 수 있고 라이브러리 참조도 된다. 그런데.. 문제가 하나 있는데 <scope>system</scope> 속성은 메이븐 빌드 시 <scope>provided</scope> 와 마찬가지로 라이브러리를 빌드 결과물에 포함시키기 않는다.
이 현상은 maven-dependency-plugin의 configuration 조정을 통해 우회할 수 있다.
plugins.plugin.executions.execution.configuration.includeScope 속성을 추가하고 그 값으로 system 을 설정한다.
[code xml]             <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>2.10</version>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                            <overWriteReleases>false</overWriteReleases>
                            <overWriteSnapshots>false</overWriteSnapshots>
                            <overWriteIfNewer>true</overWriteIfNewer>
                            <includeScope>system</includeScope>
                        </configuration>
                    </execution>
                </executions>
            </plugin>[/code]
이제 빌드를 수행하면 system 스코프로 설정된 db2jcc4.jar 가 /lib/db2jcc4-10.5.jar 란 이름으로 이쁘게 들어와 있는걸 확인할 수 있다.

나는 이 프로그램을 executeable-jar 로 뽑을거라서 maven-jar-plugin 을 사용한다. 그런데 빌드 후 jar 내부의 MENIFEST 파일을 까 보니 Class-Path 정의에 db2jcc4-10.5.jar 가 기술되어 있지 않다... maven-dependency-plugin을 통해 복사까진 어떻게 처리했는데 메니페스트를 만드는건 maven-jar-plugin 역할이니 당연한건지도 모르겠다.
이제 마지막으로 /lib/db2jcc4-10.5.jar 에 들어온 jar를 메니페스트의 class path에 꾸겨넣어보자.
 plugin.configuration.archive.manifestEntries.Class-Path 속성을 사용했다.

[code xml]    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.6</version>
        <configuration>
            <archive>
                <manifest>
                    <addClasspath>true</addClasspath>
                    <addExtensions>true</addExtensions> 
                    <mainClass>com.usbcopy.repository.DBProcess</mainClass>
                    <classpathPrefix>lib/</classpathPrefix>                            
                </manifest>
                <!--MANIFEST  with systemPath-->
                <manifestEntries>
                    <Class-Path>lib/db2jcc4-10.5.jar</Class-Path>
                </manifestEntries>
            </archive>
        </configuration>
    </plugin>[/code]
이제 빌드하고 java -jar app.jar 로 실행도 잘 된다.

우선, 테스트 진행한 json 라이브러리 후보군은

• JSON.simple ( Yidong Fang )
• GSON ( Google )
• Jackson ( FasterXML )
• JSONP  ( Oracle )

과 같음. 상기 라이브러리를 이용한 비교적 큰 사이즈의 json 문서 파싱 속도 벤치마킹 결과를 java 어플리케이션 성능평가/모니터링 도구를 개발하는 Takipi에서 공개.

벤치마크는 190MB 짜리( https://github.com/zeMirco/sf-city-lots-json )와 1KB 짜리( http://www.json-generator.com/ ) JSON 파일을 파싱하는 속도를 측정. AWS c3.large 인스턴스에서 큰 파일은 라이브러리당 10회 씩, 작은 파일은 10,000회 씩 수행한 결과를 정리했다고 함.

큰 파일 파싱
큰 파일 파싱에는 Jackson과 Json.simple 이 빠르고 Jsonp와 gson이 상대적으로 느린걸로...

가장 빠른 Jakson 성능을 기준으로 나타낸 상대 수치.

작은 파일 파싱
큰 파일 때와는 다른 양상을 보임. 작은 파일일때는 정도의 차이는 있지만 모든 라이브러리들이 측정 때마다 들쑥날쑥한 결과를 보임.  GSON 이 1순위를 가장많이 나타내고 있고 Json.simple 은 1순위가 한번도 없음.

가장 빠른 GSON 성능을 기준으로 나타낸 상대 수치.

결론.

• 당신의 개발 환경이 빅데이터처리와 같이 주로 큰사이즈의 JSON을 처리해야한다면 Jackson 을 써라. 대용량 환경에서 GSON은 좋지않은 선택임.
• 마이크로 서비스와 분산아키텍처 설정등과 같이 작은 용량의 많은 json 파일을 처리하는 환경이라면 GSON을 써라.
• 대용량과 소용량 모두를 다양하게 처리하는 환경이라면 양쪽에서 2순위 정도를 기록한 JSON.simple 이 좋을수도 있겠다.