리척
788
2017-10-09 12:27:36.0
40
2448

JavaOne 2017 요약 - Serverless, Kubernetes, Java 릴리즈 주기 변경...


JavaOne 2017 – Oracle Competing with Amazon, Going Serverless, Open Source, Vectoring Above The Clouds and Kubernetes


TL; DR:

* JavaEE를 이클립스 재단에 기부

* 자가 치유, 튜닝, 자가 운전 가능한 RDB인 18c 발표. AWS RDS를 겨냥한 것으로 클라우드 호스팅 비용을 절반으로 줄일수 있다고 자신한다.

* AWS 람다 시장을 겨냥한 자바함수 서버리스 구현체인 Project FN 발표

* kubernetes 프로젝트에 많은 자원 투자

* OpenJDK와 Oracle JDK에 동일한 구현을 사용하며 OpenJDK는 GNU 라이선스와 호환. 아마도 Jigsaw 모듈이 JDK9에 포함되었기 때문에 앞으로 독자적인 Oracle 모듈을 발표하지 않을까..

* Java는 앞으로 6개월마다 릴리즈되며, 2018년 3월에 Java9 릴리즈 18 버전을 발표하고, 2018년 9월에 Java9 릴리즈 19 버전 발표


릴리즈18 버전에서는 JEP 286 : 로컬 변수 타입 추론 기능 추가


var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>


릴리즈19 버전에서는 JEP 305 : 패턴 매칭 추가 예정


String formatted;
switch (obj) {
    case Integer i: formatted = String.format("int %d", i); break;
    case Byte b:    formatted = String.format("byte %d", b); break;
    case Long l:    formatted = String.format("long %d", l); break;
    case Double d:  formatted = String.format(“double %f", d); break;
    case String s:  formatted = String.format("String %s", s); break
    default:        formatted = obj.toString();
}


7
1
  • 댓글 40

  • LichKing
    6k
    2017-10-09 14:45:51.0

    좋은정보 감사합니다.

    하나 궁금한게...지역변수 타입추론이 가능해지면 변수선언할때 타입을 일일이 작성해주지않아도 된다는것 외에 어떤 장점이 있나요?

    0
  • iops
    1k
    2017-10-09 15:05:28.0

    자바가 점점 스칼라 같아지네요

    0
  • 리척
    788
    2017-10-09 15:19:23.0

    LichKing 

    타입선언 노가다를 하지 않음으로서 타이핑 시간 감소과 가독성 향상정도가 장점이지 않을까요?


    inyl

    스칼라 뿐만 아니라 코틀린, 그루비, 스위프트 등과 비교해도 점점 비슷해진다고 볼 수 있을 것 같네요. 현대 언어들에 이미 포함되어 있는 기능들을 하나둘씩 받아들이기 시작한 것 같은데, 6개월마다 릴리즈하기로 한 건 그런 변화를 최대한 빨리 제공하려고 한게 아닌가 싶습니다.

    0
  • webmajm
    442
    2017-10-10 09:12:46.0

    final 은 let으로 가는건가요 ㅎ

    0
  • 구구구구우
    1k
    2017-10-10 09:18:06.0

    저는 보통 IDE를 통해서 타입 선언을 하는 편인데,

    예를들면 stm = list.stream() 이렇게 적고 퀵 픽스(Ctrl + 1)를 이용하는 거지요(이렇게 하면 stm에 타입이 알아서 작성이 됩니다.)

    이러한 타입선언을 작성하는 방법도 있는데, var이 타입 선언 작성에 대한 수고를 덜어주는 장점이 앞서 말한 것보다 메리트가 있는지 궁금하네요.

    리척님께서 말씀한신 가독성 향상은 var을 안써봐서 그런지 잘모르겠네요. 오히려 더 떨어질거 같은데....

    0
  • LichKing
    6k
    2017-10-10 09:38:33.0

    저도 로컬변수 타입추론이 좋은건지가 애매하다고 생각해서^^; 저렇게 써놓으면 컴파일러가 타입추론하듯 개발자도 타입추론을 위해 변수 초기화부분까지 확인해야할거같은데... 타입 타이핑하는건 IDE가 대중화된지금 별의미없어보이고요. 다른 장점이 있으니 넣을것같아서 여쭤봤습니다.

    0
  • 앙앙이
    1k
    2017-10-10 10:19:06.0 작성 2017-10-10 11:24:53.0 수정됨

      var 라니... 아아..

    오라클로 넘어간 순간 자바 무너지는것은 시간문제라는것 알면서도 억장이 무너지는것은 어쩔수없네요.


    누군가에게는 코드 노가다로 개선해야할 악의축이겠지만

    저에게는 한가지만 알면 같은 맥략으로 충분히 그렇게 코딩해야 한다는것쯤을 쉽게 알 수 있는

    일괄성있는 모습이기에 자바가 좋습니다.

    혼돈은 hashcode와 "== 과 equals 논쟁" 만으로 충분한데 사람들 참 징하네요.



    ------------- var 혼돈:: IDE 에서 t 는 과연 어떤것을 보여주어야 할까요?
    var t = new MyClass01();
    if (true) {
    t = new MyClass02();
    }
    
    myfunc(t);
    void myfunc(var t) {
    // IDE 에서 t. 을 눌렀을 경우 과연 MyClass01, MyClass02 중 어떤것을 보여주어야 할까요?
    }


    0
  • 구구구구우
    1k
    2017-10-10 11:36:40.0

    앙앙이 

    MyClass01하고 MyClass02가 같은 타입(또는 부모 자식 관계)이 아니면 컴파일 에러가 날거 같은데, 아닌가요?? 

    제가 알기로는 var가 컴파일 시점에 추론 하는거지 코드가 실행되는 동적인 상황에서 추론하는게 아닌걸로 아는데, 그니까 애초에 저런 상황은 기존처럼 IDE가 syntex에러를 보여줬듯이 보여줄거 같은데요

    0
  • 구구구구우
    1k
    2017-10-10 11:39:51.0

    JAVA에서 저 문법을 지원하는게 너무나 큰 혼돈을 야기 할것 같진 않아요. 다만 제가 궁금한건 IDE 도움을 통해 타입선언에 작성을 도웅 받는 것이 가능한 상황에서 var가 가져다 주는 장점이 무엇이 있는지가 궁금할 뿐이네요

    0
  • LichKing
    6k
    2017-10-10 11:46:04.0 작성 2017-10-10 11:46:27.0 수정됨

    타입추론은 정적으로 진행합니다. 저런건 컴파일단에서 걸러집니다.

    http://openjdk.java.net/jeps/286

    0
  • 앙앙이
    1k
    2017-10-10 12:03:30.0 작성 2017-10-10 12:04:31.0 수정됨

    // 구구구구우

      저는 잘 모릅니다. 모르지만 var 라는 키워드를 제공하는 이상 될거라고 예상하는 코드를 짜 본거구요.

    문법 에러가 발생한다는 말씀이시군요.

    그러면 코드를 살짜 바꾸겠습니다.

    var t = null;

    if (사용자가 "실행" 을 외친경우) {

    t= new MyClass01();

    } else {

    t= new MyClass02();

    }

    이 코드도 문법 에러가 있을지 모르겠지만 만약 없다면

    자 이제 IDE 에서 t. 을 누른후 어떤 클래스의 메소드들을 보여주어야 할까요?


    개인적으로 자바 "Write once, run anywhere" 라는 말은 왕 구라 맞지만

    이런 제약 사항 있는 변수 선언은 "Write once, run anywhere" 라는 자바 철학에 정면으로 배신하는 행동이기에  달갑지 않네요.

    0
  • LichKing
    6k
    2017-10-10 12:12:22.0

    링크걸어드린거 한번 봐보세요 null 로 초기화 안됩니다.

    0
  • 구구구구우
    1k
    2017-10-10 12:20:09.0 작성 2017-10-10 12:22:47.0 수정됨

    지금 예제나 앞서 예제나 같은거에요,

    var가 그런측면의 문제를 가져오는 마법과도 같은 존재가 아니에요,

    누구나 인정할수 있는 수준에서 var를 사용하는 거죠, 컴파일 시점에 체크한다는건 그런 의미입니다.

    어떻게 될지 알수 없는(즉 동적으로 실행이 되어야 알수 있는 사실들)건 컴파일 즉 정적으로 검사를 하겠다는 거에요

    비슷한 예로 effectively final을 들을수 있는데, 컴파일 시점에 해당 문제 여부를 파악하는 점에서 비슷하죠


    그리고 Write once, run anywhere 하고 var특성하고 상관이 없어 보이네요

    0
  • 앙앙이
    1k
    2017-10-10 12:23:02.0

    // LichKing

      제가 주장하는것은 문법은 심플해야 한다는것입니다.

    뭐 그렇다 치고 다 좋습니다.

    제약 있는 var 를 만들었으면 그에 상응하는 이익이 무엇인가요?

    로컬 변수에서 타수 몇자 줄이는것?

    그건 IDE 발전으로 보완할 수 있는 문제입니다.

    누군가한테 설명을 할때 그냥 그렇게 하는것이라고 말하면서 살고있지만

    그 목록에 var 를 추가해야 할 이유가 무엇인가요?

    "자바 이렇게 저렇게 하는것이 var 에서는 안돼? 바라 자바의 비 일관성을...."

    라고 자바 꾸지다는 분들께 그래 뭐라고 반박해야 합니까?

    0
  • 앙앙이
    1k
    2017-10-10 12:25:28.0

    // 구구구구우

    Object t = new Myclass01();

    t = new MyClass02();

    이건 가능한데

    왜? var 는 안되는가 말입니다.

    그것이 저는 자바 "Write once, run anywhere" 라는 철학과 맞지 않다는 말을 드립니다.

    자바는 심플 문법을 지향해서 사랑 받은거 아닌가요?

    0
  • 구구구구우
    1k
    2017-10-10 12:25:42.0

    리치님이나 저나 그게 궁금해서 이렇게 글을 남겼죠죠개인적으론 가독성을 해칠까 염려되서요

    0
  • 리척
    788
    2017-10-10 12:28:47.0 작성 2017-10-10 12:29:38.0 수정됨

    LichKing  구구구구우

    타입 선언 노가다는 확실히 IDE를 잘 선택하면 장점이라고는 할 수 없겠군요.

    가독성의 경우 말씀하신대로 항상 var 를 사용하는 것은 가독성이 오히려 안 좋아질 수 있습니다.

    개인적인 경험으로는 함수의 길이가 길어질 수록 자동 타입 추론을 쓰면 가독성이 떨어지는 경향이 있어서, 최대한 함수의 길이를 줄여서 잘게 쪼개면서 가독성이 떨어지지 않는 부분에 대해서는 타입추론을 사용하는 편입니다.


    var intList = List.of(1,2,3);
    // List<Integer> intList = List.of(1,2,3);
    
    
    var list = new ArrayList<String>();
    var stream = list.stream();
    // List<String> list = new ArrayList<>();
    // Stream<String> stream = list.stream();

    이런건 개인취향 차이라 뭐가 낫다라고 하기는 그렇지만 전 위의 코드 형태가 가독성이 좀 더 좋은 편이라서 장점이라고 봤습니다. ^^


    0
  • 구구구구우
    1k
    2017-10-10 12:29:07.0

    var 는 어찌보면 타입이 아니에요 정확히 컴파일러가 개발자가 생각했을때 이런 타입ㅇ이라고 생각하는 바를 추론하여 허용하는것이지 그것을 자바의 모든 클래스의 상위클래스인 object와 비교해서는안됩니다 말그대로 타입추론이에요

    0
  • 구구구구우
    1k
    2017-10-10 12:53:45.0 작성 2017-10-10 12:54:55.0 수정됨

    앙앙이

    다시 읽어보니까 Object 이야기는 var를 Object로 추론하면(제시하신 코드에서) 안돼냐? 라는 의미로 들리네요, 저는 var을 안써봐서 잘 모르닙니다. 다만 타입추론이라는 의미만 파악하고 있을지 뿐이지요

    그래서 세세한 문법에 대해서는 몰라요 LichKing님이 말씀하신것 처럼 var = null이 허용이 안돼는건지 저는 모른다는 겁니다. 그래서 왜 허용을 안했는지 모르겠지만 만약 허용한다면 위에서 제시한 코드에서 var는 Object로 추론 되겠죠 (이런 규칙이 생긱겠죠 var = null로 초기화하면 Object추론해라)즉 아래의 답변의 경우 IDE는 Myclass01 인지 MaClass02인지 알필요가 없고 Object로 추론 하였기 떄문에 Object의 메소드를 보여주면 되겠죠

    "자 이제 IDE 에서 t. 을 누른후 어떤 클래스의 메소드들을 보여주어야 할까요?"


    결론적으로 하고 싶은 얘기는 var가 가져올수 있는 문제는 그리 심각한 문제가 아닐거에요(찾을수 없는 버그를 야기하는 문제를 말하는 겁니다. ), 경우에 따라서 가독성을 해치는 정도? 이것도 어떻게 사용하냐에 따라 다르겠죠, 오히려 가독성을 증대시킬수도 있겠구요(이경우는 잘 모르곘어요 리척님이 답변해주었지만.....)


    0
  • 구구구구우
    1k
    2017-10-10 12:58:13.0

    리척 

    답변 감사합니다.

    0
  • 앙앙이
    1k
    2017-10-10 13:12:26.0

    // 구구구구우

    제가 이야기하는것은 그런 이야기가 아닙니다.

    Object t = new Mycalss01();  t = new Myclass02() 를 학습한 사람이지만

    var 에 무지한 저 같은 사람은 위에 제가 예시로 코드 작업을 할 수 있다는 사실을 말씀드린거며

    var t = new new Mycalss01();  t = new Myclass02() 에서 컴파일 에러가 발생시

    var 에 대한 무지로 생긴 문제로 보지 않고 본질적으로 var 라는것이 자바 문법의 심플성을  훼손한다고 생각한다는 점을 말씀드리는겁니다.


    var 라는 키워드를 기억할만큼의 이득이 무엇인지 모르겠네요. 자바가 성과급 위주의 허례허식에 빠진듯합니다.

    0
  • 리척
    788
    2017-10-10 13:32:35.0

    앙앙이

    답변이 될 지 모르겠지만 LichKing 님이 올려주신 링크에 보면 답변이 될 만 문구들이 있으니 참고하시면 될 듯합니다.


    JEP 286 Motivation:

    Developers frequently complain about the degree of boilerplate coding required in Java. Manifest type declarations for locals are often perceived to be unnecessary or even in the way; given good variable naming, it is often perfectly clear what is going on.

    The need to provide a manifest type for every variable also accidentally encourages developers to use overly complex expressions; with a lower-ceremony declaration syntax, there is less disincentive to break complex chained or nested expressions into simpler ones.

    Nearly all other popular statically typed "curly-brace" languages, both on the JVM and off, already support some form of local-variable type inference: C++ (auto), C# (var), Scala (var/val), Go (declaration with :=). Java is nearly the only popular statically typed language that has not embraced local-variable type inference; at this point, this should no longer be a controversial feature.


    Applicability and impact

    Scanning the OpenJDK code base for local variable declarations, we found that 13% cannot be written using var, since there is no initializer, the initializer has the null type, or (rarely) the initializer requires a target type. Among the remaining local variable declarations:

    • 94% have an initializer with the exact type present in the source code (63% of cases with parameterized types)
    • 5% have an initializer with some sharper denotable type (29% of cases with parameterized types)
    • 1% have an initializer with a type that mentions a capture variable (7% of cases with parameterized types)
    • <1% have an initializer with an anonymous class type or intersection type (same for cases with parameterized types)


    Non-denotable types

    ...

    These considerations led us to different answers:

    • null-typed variable is practically useless, and there is no good alternative for an inferred type, so we reject these.
    0
  • 구구구구우
    1k
    2017-10-10 13:42:00.0 작성 2017-10-10 13:43:02.0 수정됨

    충분히 알지 못한채 사용하다가 생긴 문제를 개발자의 무지에 대한 책임으로 무조건 돌리는건 안되겠죠

    하지만 이경우는 다르다고 생각합니다. var를 사용하지 않아도 동일하게 돌아가는 프로그램을 작성할수 있지요. 애초에 var를 사용하는건 개발자에 선택에 달렸다는 겁니다. 모르면 안쓰면 되지요. 모르는데 사용해서 생기는 문제는 개발자 본인의 문제가 맞다고 생각합니다.

    var 가 자바 문법의 심플성을  훼손하는지는 잘 모르겠습니다. 다만 있다 하더라도 제 경우는 그리 크지 않다고 봅니다. 타입추론 이란건 var가 아니어도 이미 많은 곳에서 사용되고 있습니다. 

    제네릭이나, 람다의 경우가 그렇지요

    ex) ArrayList<String> list = new ArrayList<>();

    ex) Predicate<String> p = str -> str.equals("ABC");

    하지만 이들의 타입추론의 경우 가독성이 떨어진다거나, 문법을 해친다거나 하는 말은 크게 나오지 않았죠, 오히려 줄어든 코드에 대해서 더 반기는 분위기 이구요. 그렇다고 이러한 타입추론을 꼭 이용해야만 하는거 아닙니다. 타입에 대해서 명시하고 싶으면 명시하면 됩니다. 자바가 타입추론이 되기 때문에 타입을 명시하지 못하게 막아놓지는 않았으니까요.

    다시한번 얘기하지만 타입추론에 대해 이해하지 못하여 발생하는 문제에 대해서는 전적으로 개발자에게 책임이 있다고 생각합니다. 안써도 할수 있으니까요, 이 말이 문제에 대한 책임을 가려내어 무지한 개발자를 탓하려는게 아닙니다. 사용하고자 하는 마음이 있어서 사용하다 생긴문제에 대해서 피하려 하지말고 학습의 기회로 삼길 바라는 마음에서 이야기하는 겁니다. 새로운 내용에 등돌리지 말고 그냥 담담히 마주하고 생각해서 결정하라는 거지요

    너무 걱정하시는것 같아서 말씀 드리는거에요,

    0
  • 마사키군
    762
    2017-10-10 13:50:49.0

    JEP 286 타입추론에 대해서는 잘 모르겠는데,

    JEP 305는 좀 신기하네요. 저건 컴파일 타임에 처리할 수 없는 내용인 것 같은데...

    컴파일하면 자동으로 instanceof 문으로 체크하는 로직으로 대체되는 걸까요?

    원리가 궁금하기는 하네요.

    0
  • 앙앙이
    1k
    2017-10-10 13:51:47.0

    // 리척

    "Java is nearly the only popular statically typed language that has not embraced local-variable type inference; at this point, this should no longer be a controversial feature." 라는 표현 참 오만 방자하네요.

    다른 언어들이 그러하다고 따라한다고 하면 남이 죽는다고 따라 죽을건지 나원참...

    위 표현 다른 생각에 대해서 귀 막겠다는 표현 맞지요?


    %% 거기 들어가서 1분만에 쫓겨나는 기네스북 도전을 해 볼까 별의별 상상을 다하게 되네요.

    0
  • 앙앙이
    1k
    2017-10-10 14:09:34.0

    // 구구구구우

    제 주장에 대해서 제가 설명을 정말로 못하는것 같습니다.


    var t=null; 이런 표현이 안되는 이유는 var 이기때문이지요.

    하지만 저는 이런 이유를 납득 못합니다.

    자바를 배운 사람들이 합리적인 추론으로 var t = null 사용하는것에 대해서 var 라는 이유로 막고 있기에

    거부감을 갖고 있다는겁니다.

    var t = null 이 잘 동작할것이다 라고 기대하는것이 자바 스러운 생각인데

    그 생각을 막으니 자바 답지 않다 라고 말하며 자바 파괴 행위라고 정의하며 var 에 대해서 거부감으 적극적으로 표현하는겁니다.

    0
  • 구구구구우
    1k
    2017-10-10 14:36:21.0 작성 2017-10-10 14:39:59.0 수정됨

    앙앙이 

    저는 개인적으로 이렇게 꼬리에 꼬리를 무는 형태에 소통을 좋아하는 편입니다. 서로 의견을 얘기하고 알아가는 과정이니까요. 근데 이건 제 개인적인거고 앙앙이님은 어떨지 모르겠네요 만약 불편하시면 죄송하다고 말씀드리고 싶네요. 

    어쨌든 "var t=null; 이런 표현이 안되는 이유는 var 이기때문이지요 하지만 저는 이런 이유를 납득 못합니다. 자바를 배운 사람들이 합리적인 추론으로...." 라고 말씀하셨는데 

    • null-typed variable is practically useless, and there is no good alternative for an inferred type, so we reject these.


    라고 왜 허용을 하지 않는지 적혀있네요, 타입추론에 대해서 공부하고 이해하고 있는(즉 컴파일 레벨시점에 추론) 개발자라면 var t = null이 안돼는것을 합리적으로 추론할수 있어보이네요.

    var는 Object타입이나 어떠한 타입도 아니고 말그대로 컴파일러에게 t는 추론가능하니까 추론해봐라고 하는것 뿐이니까요(이말은 t는 추론가능해야 한다는 겁니다. var t = null은 추론이 안돼죠)

    Object t = null이 되니까 var t = null 도 될꺼야 라는 추측이 자바스러운 생각이라고 보는건 문제가 있고, var(타입추론)가 뭔지를 알고 var t = null 이 안될꺼라고 생각이 드는게 정확한 흐름이라고 봅니다. 즉

    개발자들이 var가 뭔지 알면 정확하게 생각할테지요.

    0
  • 앙앙이
    1k
    2017-10-11 00:33:34.0

    // 구구구구우

    기존 자바 프로그램을 해왔던 사람이라면 당연히 var  t = null; 에 대해서 아무런 의심없이 될거라 생각하는것이 당연한거 아닙니까? 그런 염려가 있어서 "A null-typed variable is practically useless, and there is no good alternative for an inferred type, so we reject these." 라고 분명하게 말해준거 아닐까요.

    여기서 중요한것이 "so we reject these." 라는 표현입니다.

    이런 표현을 쓴거 자체가 화자의 거부 의사를 강력하게 어필하기 위한 화법입니다.

    기존 자바 프로그래머들 습성이 이와 관련 없다면 궂이 이렇게 강하게 자신의 거부 의지를 표현할 필요가 없지요.

    하여 " var t = null 도 될꺼야 라는 추측이 자바스러운 생각이라고 보는건 문제" 라는 지적에 공감을 해 드릴 수가 없네요.


    0
  • 구구구구우
    1k
    2017-10-11 01:37:25.0

    앙앙이

    자바의 모든 클래스는 Object의 하위클래스이죠 Object t = null 로 선언이 가능하구요. 그런 의미에서 String t = null, MyClass t = null이 선언 가능할거라는 추론은 정당합니다.

    하지만 var는 Object의 하위 타입이 아닙니다. (거의 Keyword로 보는게 맞을거에요) 그러니 var t = null이 될꺼라는 추측은 문제가 있다는 얘기입니다. 그리고 저는 var가 Object의 하위 타입이 아니란걸 모른체 var를 사용해서 낭패를 보는 개발자에 대해서 문제가 있다고 본거구요, 이러한 문법을 만든 자바진영에 대한 문제가 아니구요.

    애초에 var사용에 선택권을 가진 개발자가 var에 대해 잘 모르면서 잘못된 추론으로 사용하는건 문제가 있다는 말이었습니다.

    정리하면 var를 모르는 상황에서 var에 대해서 Object와 마찬가지로 판단하는것은 자바스러운것이 아니라 잘못된 판단 이라는 거죠. 

    그럼 var에 대해서 충분히 이해했다고 가장 하에 아래에 예제를 보면

    var t = null;

    if (value) {

        t= new MyClass01();

    } else {

        t= new MyClass02();

    }

    여기서 부터는 제 개인적인 견해 입니다. 해당 예제에서 t를 컴파일러가 추론을 하게되면 t는 어떤 타입이어야 할까요. var(타입추론)는 컴파일 시점 즉 정적 상황에서 이루어 집니다. 즉 컴파일러에게 if 문 부터 이뤄지는 코드는 안중에도 없고 오로지 var t = null를 토대로 타입추론을 하겠죠, 어떤가요 t가 무슨 타입인지 추론이 가능 한가요?

    제 생각에 억지로 끼워맞춘다면 Object말고는 없어보이네요. 그것말고 컴파일러가 추론 가능한 타입은 없죠. 하지만 자바는 이부분에 대해서 필요치 않다고 느꼈고 var t = null를 허용하지 않도록 했습니다.(컴파일 에러).

    찾아보니 C#의 경우 null이 무엇인지 타입을 명시해주면 해당문법을 허용하고 있습니다.

     var t = (string)null; 

    var t = null의 경우 어찌보면 Object로 추론할수 있을거 같지만 허용하지 않고 Object로 타입추론 하기 위해서는 마찬가지로 아래와 같이 사용해야합니다.

     var t = (Object)null;

    하지만 이러한 표기를 굳이 타입추론을 써가면서 얻는 이익이 있을까요? 없습니다. 그냥 string t= null;

    Object t = null 이라고 표기하는 것이 더 간결합니다. 애초에 null에 타입을 명시하는거 부터가 추론과는 멀어보입니다. 이때문에 자바에서는 아예 쓸모 없다 판단하여 허용하지 않아 보입니다. 



    0
  • fender
    9k
    2017-10-11 01:55:23.0 작성 2017-10-11 01:56:06.0 수정됨

    멀쩡한 개념을 혼자만의 상상으로 다르게 이해 -> 다른 사람들이 반론 -> 끝까지 우김 -> 스펙 등 근거를 제시 -> 자기가 이해한 개념과 다르니까 스펙이 잘못됐다고 우김.

    내용도 충실한 좋은 글이 또 저 분 자주 보는 패턴 때문에 산으로 가네요.

    해당 기능이 과거에 찬반이 갈리기도 했으니 토론 자체가 나쁜 건 아닙니다. 물론 그 때도 반대하는 쪽 근거는 저런 내용과 별 상관없는 IDE가 없을 때 유형을 쉽게 알기 어렵다던가 하는 내용이었습니다만...

    어쨌건, 토론도 좋고 마음에 안드는 기능이야 반대를 하건 안쓰건 자유이긴 합니다. 그런데 새로운 개념에 대해 기술적인 토론을 하려면 최소한 왜 그런 기능이 도입되었고 어떻게 동작하는 지는 이해를 하고 이야기를 하는 것이 상식입니다.

    혼자서 엉뚱하게 이해한 내용 가지고 "자바가 무너진다"느니 "자바 철학을 배신했다"느니 다른 사람들 친절하게 제시하는 근거는 깡끄리 무시하고 본인 주장만 반복하면 보는 사람들만 피곤해지는 것 같습니다.

    주제 자체에 대한 개인적인 생각을 간단히 적어보면, 해당 기능은 자바가 현대적인 언어들과 경쟁하기 위해서 꼭 필요하다는 정도입니다.

    옵션 유형이나 람다의 도입, 패턴 매칭 등과 함께 그런 기능들은 어느 정도 개발자들 사이에 공감대가 형성이 되어 있으니 다양한 언어들이 그런 방향으로 수렴하는 것이라고 생각합니다.

    자바 개발자가 스칼라 개발자보다 멍청하거나 C# 개발자와 다른 패러다임으로 개발하는 것도 아닌데, 이들 언어에서 아무 문제없이 잘 쓰이는 기능들이 자바에 도입한다고 큰 문제가 된다고 우려할 이유는 없습니다.

    원론적으로 굳이 반론의 여지를 찾아보자면 IDE를 사용하지 않을 때 변수의 유형이 명확하지 않다는 정도는 유효한 주장이라고 생각합니다. 하지만 요즘 세상에 자바 같은 언어를 텍스트 편집기로 개발하는 건 꽤 비효율적인 일이고, 그런 예외적인 경우를 배려해서 다른 모든 개발자들이 불편을 감수하거나 자바가 경쟁 언어들에 비해 뒤쳐져야 한다면 설득력이 부족하다고 봅니다.

    앞서 소개된 자료에서 OpenJDK의 소스를 분석하면 거의 90% 가까운 지역 변수 선언이 굳이 유형을 명시할 필요가 없다는 결과를 보아도 알 수 있듯이, 해당 기능의 도입으로 기대할 수 있는 장점은 충분히 그런 단점을 상쇄하고 남는다고 생각합니다.

    1
  • 리척
    788
    2017-10-11 09:27:41.0

    댓글로는 JEP 286에 대한 토론이 대부분이 되었지만, 개인적으로는 JRE만 쓸뿐 Java는 쓰지 않는 개발환경이라 그냥 이런 기능이 이제야 추가되네? 하는 정도 느낌이고, 오히려 오라클이 쿠버네티스에 전폭적인 지원을 하겠다는게 인상적이었습니다. 현재 쿠버네티스를 도입해 보려고 준비중이어서 더 그런지 모르겠지만, 내가 선택한 기술 방향이 제대로 가고 있는 것 같다는 일종의 안도감? 같은것일 수도 있겠네요.

    GitLab도 소스코드 저장소에서 벗어나 DevOps 기능을 강화하면서 200억이 넘는 투자를 받았다는 뉴스와 쿠버네티스 지원 소식을 접하면서 DevOps와 마이크로서비스쪽으로 이동이 점점 가속화되지 않을까 싶습니다. 물론 이것이 은총알은 아니지만 확실히 코드 푸시를 하는 순간부터 테스트, 빌드, 배포, 스케일 자동화까지의 프로세스를 경험하고 나니 수동으로 배포하는 환경에서 작업하려니 이게 뭔 삽질인가 싶은 생각이 들더군요.

    0
  • 겸손합시다
    220
    2017-10-11 10:51:05.0

    이 코드 자체가 이미 똥코드입니다 ㄱ-


    var t = new MyClass01();
    if (true) {
    t = new MyClass02();
    }
    0
  • 앙앙이
    1k
    2017-10-11 11:50:47.0 작성 2017-10-12 09:46:51.0 수정됨

    // 구구구구우

      다른 언어 c#에서도 기존 학습자들에 대해서 고민하고 있다는거 아닐까요.

    null 을 지정하려는 습성이 이해되니

    하고 싶으면 이렇게 해라 라고 기형적인 형태로 허용을 해준거라 생각합니다.


    기존 학습자한테 완전히 새로운 개념을 추가하는것에 대한 입장은 다를 수 있다고 생각합니다.

    새로운 개념이기에 근본적으로 var t = null 이라고 기술하는것 자체가 틀린것이라는 말씀 백번 옳습니다.

    하지만 저는 삐딱하게 생각합니다. 내가 틀린것이 아니라 var 가 틀린것이라구요.

    무슨 이득이 있어 넣었는지 모르겠습니다.

    (1) var list = new ArrayList<String>();  // infers ArrayList<String>
    (2) var stream = list.stream();          // infers Stream<String>

    2번 형태의 경우 IDE 도움 없이는 타입을 알기 힘듭니다.

    이런 지적을 알고 있기에 숨기지 않고 보여주는거겠지요.

    "openJDK의 소스를 분석하면 거의 90% 가까운 지역 변수 선언이 굳이 유형을 명시할 필요가 없다는 결과" 는 참 오만한 주장입니다. 객관성을 담보할려면 대규모 통계를 뽑아서 주장해야할 주장인데 과연 그렇게 하고 주장을 한건지 의문입니다. 세상사 소스들이 openjdk 만큼 정제되어 있는지도 의문이구요.

    하여 openjdk 에서만의 분석 결과로 그렇게 주장하는것이 공정한가도 의문입니다.

    객관적인 소스 이해도 지표를 만들어서 그룹에 적용하여 평가를 해서 얻은 결론일까요.

    주장만 있지 그렇게 햇다는 통계 근거도 같이 제시하지 않는 주장을 근거로 주장하는 분들 보면

    뭐라고 말해 주어야할지 모르겠습니다.


    애초 추가해야할 이유 자체가 객관성없는 주관적인 주장을 근거로 한거니

    이런짓이 자바를 망치는것이 아니면 뭐가 망치는건지 모르겠습니다.

    0
  • iops
    1k
    2017-10-12 17:51:17.0

    var는 타이핑을 줄여줍니다. 이거 하나만으로도 충분히 이득입니다.

    컬렉션 타입이 겹칠때 예를들면 Map<String, List<Integer>> 같은 선언을 전부 안쓰고 var로 대체한다고 생각해보면

    충분히 타이핑 적인 면에서 시간이 단축될겁니다.


    그리고 var같은 문법이 추가된다 하더라도 기존처럼 타입선언을 쓰지 못하는것도 아닙니다. 

    필요하다 생각하면 쓰고 별론거 같다 싶음 그냥 예전처럼 쓰시면 됩니다.

    이게 나쁘다 좋다는 실제 써보고 판단해도 늦지 않을것 같습니다.

    저는 참고로 var, val같은 정적 타입추론 언어를 써봤고 매우 만족스러웠습니다.

     


    0
  • 앙앙이
    1k
    2017-10-12 22:35:19.0 작성 2017-10-13 00:14:08.0 수정됨

    // iops

    var 는 확실히 타이핑을 줄여줍니다. 이 사실을 부정할 사람 있을까요.

    var 를 옹호하는 주장들중에는  var stream = list.stream();      처럼 컴파일러 즉 기계나 쉽게 타입을 아는거지

    어찌 사람이 쉽게 알 수 있겠습니까?

    이 문제는 IDE 도움으로 하면 된다는 주장이 있습니다.

    그렇다면 마찬가지 논리로 IDE 에서 Map<String, List<Integer>> 를 단축키로 제공해서 만들어 주면 어떻습니까? 

    왜 var 만 IDE 도움으로 하면 되고 none-var 는 IDE 도움을 받으면 안됩니까?

    요즘 개발환경에서 IDE 없이 하는 경우 거의 없으니 IDE 단축키로 Map<String, List<Integer>> 만들어 주면 무슨 문제가 있나요?


    자바는 unsinged 와 singed 혼재 될경우 사람이 예측하는 결과랑 그 결과가 달라 생기는 부작용을 중시하여 unsigned 를 지원하지 않습니다.

    또한 연산자 오버로딩 역시 위와 비슷한 맥략으로 빼 버렸습니다.

    이것은 어디까지나 자바의 선택일뿐이지 이것이 언어의 좋고 나쁨을 판단할 잣대는 아니지요.

    그렇지만 저는 이 2가지 생각에 동의하기에 자바를 선택하였습니다.

    타 언어 특히 요즘 나오는 신생아 언어들 모두 연산자 오버로딩을 지원하더군요.

    새로운 언어 좋다고 해서 가장 먼저 확인하는것이 이 연산자 오버로딩 여부인데

    실망스럽게 연산자 오버로딩을 빼 버린 자바의 선택을 존중해 주는 언어가 없더군요.

    그래서 아직도 자바하고 있습니다.

    iops 님 연산자 오버로딩은 장점은 없고 단점만 있는걸까요?

    아니지요. 장점도 있습니다.

    그런데 자바는 말이지요. 사용자 한테 혼선을 주는것을 아에 차단을 하고자 빼 버린겁니다.

    이것은 은행에서 줄서는데 새치기 많아서 번호표 도입하는 그것과 유사한겁니다.

    새치기 하는 인간이 나쁘다고 벌을 주고 새치기 말라고 윽박 지르는 방식이 아니라

    번호표 라는 시스템  도입을 통해서 자연스럽게 질서를 갖는 그런 방식으로 해결하는 방법론을 추구한다 말입니다.

    여기 var 가 있습니다. 예 타이핑 면에서 분명한 이득이지요.

    그렇지만 var stream = list.stream();   에서 보여지슷이 IDE 도움 없다면 타입을 알수 없는 사용자 혼선을 주는 여지를 줍니다. 

    사용자 혼선을 준다고 unsigned 를 빼 버린 자바에서 이런 var 를 추가한다고 합니다.

    이런 var 를 보는 저는 매우 슬픕니다.


    마지막으로 iops 님 필요하면 쓰고 안쓰는것은 혼자하는 개인 프로젝트에서나 통하는거지

    남의 소스 봐야 하는 환경에서 통할 이야기인가요?

    기본전제가 남의 소스 봐야하는 환경 아니던가요. 그런곳에서 통할 이야기를 해 주셔야지 왜 하나 마나한 말씀을 하시는지 모르겠네요.


    ------- simple language 언급 참고 주소

    "The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling" 참고 주소 : http://www.gotw.ca/publications/c_family_interview.htm


    "잘 모르겠으면 unsigned 타입은 쓰지 말지어다." 참고 주소 : http://egloos.zum.com/minjang/v/2697619

    0
  • boostraping
    14
    2017-10-16 08:35:31.0

    그루비, 스칼라 ,코틀린 특성을 자바가 내려 받내요

    0
  • 김동욱2
    440
    2017-10-16 11:04:06.0

    컴파일 타임에.. 로컬 변수 추론이 그렇게 큰문젠가요? JAVA에 대한 사랑이 과하신듯.. 그냥 하시던대로 var 안쓰시면 되죠ㅋ

    0
  • 앙앙이
    1k
    2017-10-16 11:17:23.0

      그루비, 스칼라, 코틀린 모두 연산자오버로딩을 지원하는 최근에 나온 신생아 언어들이지요.

    "JEP 286: Local-Variable Type Inference" 에서 var 를 사용해야하는 이유가 최근 언어들 다 지원하는데 자바만 지원안한다 이런 논리이지요.

    그 논리 그대로면 자바에 연산자오버로딩도 못 도입할것 없지요.

    자바 만든 제임스 고스링 같은 분들의 철학이 이렇게 무너지고 있는겁니다.


    자바 초창기 c++ 사용자들이랑 대박 피터지게 싸웠지요.

    속도 논쟁부터 unsigned/연산자 오버로딩 논쟁까지요.

    그때에도 못난 자바 추종자들중 신생이면 무조건 좋다고 생각하는 부류에서 못쓸 말 하고 다녔는데

    요즘 신생언어 추종자들중 일부가 자바한테도 또 그러고 있네요.

    인생은 돌고 도는것 같습니다.


    --- "JEP 286: Local-Variable Type Inference" 에서 var 를 사용해야하는 이유 부분 인용

    참고 주소 : http://openjdk.java.net/jeps/286

    Java is nearly the only popular statically typed language that has not embraced local-variable type inference; at this point, this should no longer be a controversial feature.


    ------ 자바에서 연산자 오버로딩과 unsigned 배제한것에 대해서 언급된 "The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling" 참고 주소 : http://www.gotw.ca/publications/c_family_interview.htm

    0
  • 앙앙이
    1k
    2017-10-16 11:26:54.0

    // 김동욱2

      남의 소스 봐야 한다면 나만 var 안쓰면 되는건가요.

    남의 소스 봐야하는것이 기본이지요.  기본 전제로 말씀을 하셔야지 하나 마나한 말은 해 하시는겁니까?


    인생은 돌고 돌거니 언제가 님도 그대로 돌려 받으실겁니다.

    0
  • 앙앙이
    1k
    2017-10-16 12:27:07.0

      var 에 대해서 몇가지 의문이 드네요.


    var stream = list.stream();          // infers MyStream<String> 에서 MyStream 클래스 이름을 MyStream2 로 바꿔 변경 완료했지만 MyStream 일때 컴파일한 .class 를 동적 클래스 로더에서 로딩할 경우 문제는 없는가?

    개인적으로 컴파일시 타입을 정하는 방식이라 문제가 생길거라고 생각합니다.

    뭐 이건 테스트를 안 해 봤으니 그냥 문제가 없다고 퉁 치고 넘거가도

    클래스 이름 변경은 비지니스 로직 변경이 아니기에 상세한 테스트를 할 필요 없지만

    구동이 된다는것 정도는 확인을 해 주어야 합니다.

    하여 MyStream2 으로 변경시 영향 받은 목록에 var stream = list.stream(); 를 사용한 모든 파일들을 추적해야 합니다. var 없을때에는 선언문에 타입이 있어자 문자열 찾기로 찾을 수 있는데 과연 var 적용 세상에서는 문자열 찾기로는 매우 아주 번거롭게 됩니다.

    var 를 지지하시는 분들 이거 스마트하게 추적할려면 어떻게 해야 하나요?

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.