Oracle 은 Java SE 에 대해서 유료화 모델을 발표했습니다.
상업적 목적으로 이용시 어떻게 해서든 과금을 시키겠다는 정책입니다.

주변분들의 평가들이 서로 다른 거 같습니다.

무료화 버젼도 있으며, openJDK 를 쓰면 된다, JVM != OracleJDK 가 아니다라고 생각하는 사람과,
유료화 모델이 나왔기 때문이 아니라, JAVA 자체의 생산성보다 더 좋은 것들이 많이 나오는 시점에서,
유료화 모델은 국내 회사에서의 개발 언어에 대한 선택의 폭을 좁히는 결과가 올 것이라고 생각하는 사람도 있습니다.

예전 같았으면, 이 두가지 생각 중 하나를 선택했을 거 같습니다. 토비님의 [Oracle Code Seoul 2017] Java 9과 Spring 5로 바라보는 Java의 변화와 도전 을 들어보면, 이 위기도 결국 극복해나갈 거라 확신합니다.

그럼에도 불구하고 개발자로 살아가기 위해서는, 결과적으로 여러 언어는 많이 알아두면 좋은 거 같습니다.

모든 언어가 영원할 거라 믿지 않기 때문입니다.

예전 javascript 의 MVN 패턴에 대해서 크게 뜨면서, 7년 전 프로젝트에 Ext.js 를 사용했지만,
모바일로 잠깐 반짝거리고 지금은 잘사용안하죠.
5년전에는 backbone.js 가 떳고 요즘 대세는 Vue.js 입니다. 작년엔 React.js 를 모르면 바보였던거 같습니다.

자바로 평생 먹고 살 생각을 했던게 10년전이라면, 요즘은 어떤 언어든 배우면 된다로 바뀐거 같습니다.

자바를 하기 위해 몽고DB를 알아야하고 OracleDB, Mysql, MariaDB, 카산드라, ehcache 이제는 HBase, 카프카 등등.. 알야할 게 끊임없는거 같습니다. 다만, 예전 backbone.js 와 Vue.js 나 React 를 비교해보면 요즘 나온 언어는 예전에 비해 정말 사용하기 쉬운거 같습니다.

코틀린이 뜬다고 해서 코틀린도 해봤습니다.
재미있더군요.

그냥 지정된 API 나 commands 만 알면 왠만한 것은 해당 라이브러리, 툴, 솔류션들이 알아서 해주니, 점차 개발자들은 단순히 해당 오픈소스를 그냥 쓰면된다라는 마인드로 바뀐게 아닐까요? 도메인 주도의 설계의 본질에 조금 더 접근하는 거 같습니다.

소프트웨어의 본질은 기술이 아니며, 기술력의 너무 촛점을 둬서 본질을 흐려서는 안된다고 봅니다.

저는 당연히 개발자는 도메인에 대한 개념을 알아야한다고 생각합니다. 모든 개발 시작시 어떤 요구사항인지, 궁극적으로 원하는 것이 무엇인지 파악하는데 중점을 둡니다.

자바가 쉽게 사장되진 않겠지만, 계속 무언가 변화하고 있습니다. 자바 8 의 람다. 자바 9 의 모듈화. 자바 10 의 var.

변화하는 것에 따라가지 못하면서, 근시적인 유료화에 불만을 가지지 않고 나아가야겠습니다.

참고로,

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10)
OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode)

openJDK 는 openjdk라고 뜨고, OracleJDK 는 Java(TM)이라고 뜹니다.

참조

• OracleJDK 의 유료화, 그래서 Java 는 망했다?

• OracleJDK 유료화 FAQ

시작 ====

자바 언어에서는 이미 전체 프로젝트를 모듈화하는 기본적인 기재들은 갖추고 있다. jar, war 등을 써서 이미 필요한 부분을 떨어뜨릴 수 있고,

그렇기 때문에 그런것들을 다운받아서, 라이브러리로 받아서 한글처리나, 구아바, RXJava 같은 비동기 라이브러리가 되었든, 새로 개발하지 않고 사용 가능하다.

사실 내가 짜고 있는 프로그램에서도, interface 를 잘 쓰면 모듈화가 가능하다. 자바에서는 패키지를 제공하기 때문에 3 dept, 4 dept 처럼 단계를 가지고, 자바 언어에서 제공해주는 public, private 등을 이용하여 기본적인 구조화, 모듈화가 가능하다.

그럼에도 불구하고 왜 이런 모듈이란 새로운 게 나왔는지, 기존것과 무엇이 다른지를 이해해야한다.

자바 9의 언어의 모듈화는 어떻게 되었을까?

1. javadoc 이 달라졌다. https://docs.oracle.com/javase/10/docs/api/index.html?overview-summary.html

예전 자바doc을 들어가면 좌측은 패키지와 우측은 해당 패키지의 doc이었는데, 좌측 상단의 모듈들이 생기게 되었다. 모듈에서 패키지가 나온다.

base 모듈을 들어가보면, Exports Package 라는 항목이 나온다.

provides 와 usec 는 서비스입니다.

자바 내부가 모듈화가 되었다는 첫번째 의미로 보았을, 여지껏 패키지로 모듈화가 되었다고 한다면, JAVA 7 기준으로 서로가 서로를 참조하는 매우 어려운 구성에서, JAVA 9 에서는 모듈화가 되면서 조금더 간략하게 되었다.

트리구조는 아래쪽을 띄어내서 모듈화하기 쉽지만, A > B > C > D > A 구조와 같은 순환처리를 하게 되면 트리구조와는 다르게 띄어내기가 힘들다. 그래서 JDK 라는 전체 클래스가 5천개가 넘는데, 해당 클래스들의 순환참조를 다 끊어냈다가, 2년여간에 걸쳐 Project jigsaw (모듈화된 JDK)라는 이름하에 다 끊어냈다. java.se 를 보더라도 순환처리가 없는 것을 알 수 있다.

모듈로 패키징하여 서로간의 순환참조를 하지 않도록 구성했다. 이것이 가능해지면서 기존에는 불가능한 구조가 가능하게 되었다.

원래는 2017년 9월에 나왔는데 2016년 초에 나오는게 목표였는데, 2016년부터 자바의 라이브러리를 만드는 최신 트랜드를 고민하는 개발자들은, 내가 가진 라이브러리로 고정부와 변동부, 확장과 기본, 아니면 계열분리와 같은 식으로, 라이브러리를 재작성하는 사례들이 있었다.

RxJava 도 그런 형태로 그렇고, JUnit 또한 테스트 프로그램을 만들 때, JUnit5 가 모듈화되어서 나왔다. 테스팅을 하는 일반적인 JUnit5, Junit 쥬피터, Junit3나 4에 대한 레거시를 확장가능한 Junit 빈티지 와 같은 3개의 라이브러리를 모듈화하여 나왔었다. (JUnit 5 = JUnit platform + JUnit Jupiter + Junit vinatage)

- foundaton for launching testung frameworks on the JVM
- the combination of the new programming model and extension model for writing test and extenstions Junit 5
- TestEngine for running JUnit 3 and JUnit 4 based tests on the platform

솔직히 이렇게 하려면 어렵다. 고정부와 변동부를 쪼갠다는 건 매우 어려운 일이다. 관리자들이 이게 왜 필요한지를 모른다. 실제로 고정부와 변동부를 잘 쪼갰는지에 대해서는 잘 이해하기 어렵다. 그랬을 경우 성능은 떨어지지 않았는지에 대한 고민 또한 필요하다.

1. 자바 언어에서 모듈이란 키워드가 추가되었다. 그리고 모듈이란 키워드는 module-info.java에 들어간다. 들어가는 것은 export, requires 등이 있다. 그리고 사실 usec도 있고 provides도 있 커테인스도 있고 멘데이스도 있 많다.

2. Project Jigsaw라는 프로젝트에 의해 JDK도 모듈이 되었다. 가장 자주 쓰이는 것은 java.base, java.xml, java.sql 등이 있다.

3. 모듈은 exports 한다. 모듈은 내부적으로 숨길수도 있고 외부에 노출 시킬 수 있지만, 기본적으로 exports는 패키지 단위로 한다. 이것은 java 9의 설계한 설계자의 선택이었다.

4. public 도 exports 해야만 외부에서 참조 가능하다. (Reflection도 불가능하다.) public 은 어디서나 참고가능했었다. 패키지 내부는 default 나 protected 나 그런것으로 보호하지 않는 한, 완전히 다 열려있는데 모듈이라는 개념이 와서 public 이라도 모든 걸 가져올 수 없게 되었다. 한마디로 public 개념 축소되었다. 원하는 기능이 있을 때, 오픈소스의 경 소스를 다 볼 수 있었다. 근데 그 기능이 Hide된 API 라고 하더라도, 그럴 경우 그 시그너쳐만 따다가, 리플렉션으로 동적 호출을 합니다. 아예 그런것들이 JVM 단에서 막힌다. 그래서 Reflection도 안되게 강력하게 막을 수 있게 되었다.

5. 동일 패키지는 중복할 수 없음 (Split pakages) 순환참조가 없어야하는 제약과 함께, A와 B라는 모듈에서 동일한 패키지명을 가질 수 없는 제약이 생겼다. 클래스 이름만 같지 않으면 되었는데, 패키지는 완벽하게 modules의 하위가 되버림. 예전에는 전체에서 어떤 패키지를 쓰는지 자유로웠다면, 모듈 하위에서 패키지가 들어가므로, 중복되는 이름을 사용할 수 없게 되었다.

6. JVM 시작시 필요한 모든 클래스를 확인 (Module Resolution) JVM 이 실행할때 모든 클래스를 확인합니다. 예전에는 컴파일에서는 확인하지 않고 런타임되었을때 에러났을 부분들을 예방하기 위해서 Module Resolution이라는 모든 클래스를 확인하는 절차가 생겼다.

7. Custom JDK 만들 수 있음 (JLink)

정상적으로 지원되는 IDE IntelliJ IDEA (2017.9) 이클립스 Photom (2018.6) : 아직도 불안정함. ETC. Netbeans 9.0 RC1 (2018.7) 은 아직도 동작못함.(정식버젼아님.)
표준 그레들 방식으로 한다면 아직 IntelliJ 형태로 진행하는게 좋다.

175.125.19.92 - - [23/Jul/2018:00:45:24 +0900] "GET /servlet/xxxx HTTP/1.1" 200 433 "-" "newspaper/0.2.6" 57ms

특정아이피에서 이상한 USER-AGENT 값이 지속적으로 유입되고 있습니다.
보통의 USER-AGENT 의 경우에는,

"Mozilla/5.0 (Linux; Android 7.1.1; SM-N950N Build/NMF26X; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/62.0.3202.84 Mobile Safari/537.36 [FB_IAB/FB4A;FBAV/159.0.0.38.95;]"

이런 형태로 해당 유입패턴을 가지고 웹, 모바일을 구분하거나

모바일에서도, 삼성인지, 아이폰인지 분석하는 용도로 잘 사용합니다.

근데 해당 ua(user-agent)값에 떡하니, “newspaper/0.2.6”란 값이 들어오며,
해당 패턴들이 부정유입,
들어와서는 안되는 예전 데이터들로 파악되어, 추측컨데 크롤링이나 bot 으로 판단이 되었습니다.

실제, 해당 녀석이 무엇인지 검색을 해보기 위해,
newspaper로 검색해보니 파이썬 크롤링관련 내용이 검색이 되었으며,

해당 github의 66라인을 보니

self.browser_user_agent = 'newspaper/%s' % __version__

위와 같이 별도의 설정이 없으면 “newspaper/0.2.6” 라는 ua값이 찍히도록 되어있는 것을 확인했습니다.

해당 IP는 바로 차단을 해야할 것으로 보이며, ua에 대한 체크로직을 추가했습니다.

참조

• Newspaper3k