자바에 대한 현대적 리뷰

나는 몇 년 동안 프로그래밍을 해왔고 Java로 시작했으며, 제 시간에 Java가 어떤 식 으로든 열등한 언어라고 주장하는 많은 다른 소스를 발견했습니다. 나는 각 언어마다 강점과 약점이 있다는 것을 잘 알고 있지만 Java에 관해 읽은 많은 것들이 데이트 된 것 같습니다.

Java가 열등한 이유 중 가장 자주 인용되는 이유는 예를 들어 C ++와 같이 다른 네이티브 컴파일 언어보다 훨씬 느리기 때문입니다. 많은 사람들이 성능 부서의 명백한 부족으로 인해 Java를 사용하는 게임 디자이너 Notch (Minecraft를 개발 한)를 비판합니다. 나는 Java가 하루에 훨씬 느리다는 것을 알고 있지만, 특히 JIT 컴파일 이후 많은 개선이있었습니다.

저는 오늘 언어로서 Java에 대한 객관적인 의견을 얻고 싶습니다. 그래서 내 질문에는 4 부분이 있습니다.

1. 공연.

   에이. 오늘날 Java의 속도는 C ++과 어떻게 비교됩니까?

   비. Java를 사용하여 최신 AAA 타이틀을 만들 수 있습니까?

   씨. Java가 C ++보다 느린 영역은 무엇입니까? (예 : 숫자 처리, 그래픽 또는 그 밖의 모든 것)

2. Java는 이제 컴파일 된 언어 또는 해석 된 언어로 간주됩니까?

3. 초기부터 해결 된 Java의 주요 단점은 무엇입니까?

4. 아직 해결되지 않은 Java의 주요 단점은 무엇입니까?

편집하다:

명확히하기 위해이 Java와 C ++을 만들지 않습니다. 평균적으로 c ++은 Java보다 약간 빠릅니다. 이 시점에서 언어로서의 성숙도 측면에서 Java를 비교할 무언가가 필요합니다. c ++은 영원히 주변에 있었으므로 나는 좋은 비교 지점이 될 것이라고 생각했습니다.

에이. 오늘날 Java의 속도는 C ++과 어떻게 비교됩니까?

측정하기 어려움. 구현 속도의 주요 부분 인 메모리 할당자는 Java 및 C ++에서 매우 다른 알고리즘이라는 점에 주목할 가치가 있습니다. 콜렉터의 비 결정적 특성으로 인해 콜렉터의 상태를 확실하게 알 수 없기 때문에 C ++의 결정적 메모리 관리와 비교할 때 의미있는 성능 데이터를 얻는 것이 매우 어렵습니다. 이는 벤치 마크 작성이 매우 어렵다는 것을 의미합니다. 의미 적으로 비교할 수 있습니다. 일부 메모리 할당 패턴은 GC로 훨씬 빠르게 실행되고, 일부는 네이티브 할당기로 훨씬 빠르게 실행됩니다.

그러나 내가 말할 것은 모든 상황 에서 Java GC가 빠르게 실행되어야한다는 것 입니다. 그러나 기본 할당자는 더 적합한 할당기를 교체 할 수 있습니다. 나는 최근 C # 이 왜 내 컴퓨터에서 (0.45 ms)에서 동등한 것과 비교할 수 있는지에 대해 SO 에 대한 질문을했다.Dictionarystd::unordered_map내 컴퓨터에서 10ms 동안 실행되었습니다. 그러나 할당 자와 워셔를 더 적절한 것으로 교체하기 만하면 실행 시간을 원래 런타임의 30 분의 30으로 내 컴퓨터에서 0.34ms로 줄였습니다. Java를 사용하여 이러한 종류의 사용자 정의 최적화를 수행하기를 결코 기대할 수 없습니다. 이것이 실제로 차이를 만들 수있는 훌륭한 예는 스레딩입니다. TBB와 같은 기본 스레드 라이브러리는 많은 스레드에서 많은 할당을 처리 할 때 기존 할당 자보다 훨씬 빠른 스레드 캐싱 할당자를 제공합니다.

이제 많은 사람들이 JIT 개선에 대해 이야기하고 JIT가 더 많은 정보를 얻는 방법에 대해 이야기 할 것입니다. 물론입니다. 그러나 컴파일러는 최종 프로그램의 런타임 관점에서 비교할 때 무한한 시간과 공간이 있기 때문에 C ++ 컴파일러가 가져올 수있는 것과 여전히 가깝지 않습니다. JIT가 프로그램을 최적화하는 가장 좋은 방법에 대해 생각하는 모든 사이클과 모든 바이트는 프로그램이 실행하지 않고 자체 메모리 요구에 사용할 수없는 사이클입니다.

또한, 특히 이스케이프 분석과 같은 경우 컴파일러 및 JIT 최적화가 특정 최적화를 입증 할 수없는 경우가 있습니다. 값이 스택에로 C ++에서는 다음 어쨌든 , 컴파일러를 수행 할 필요가 없습니다. 또한 연속 메모리와 같은 간단한 것들이 있습니다. C ++로 배열을 할당하면 연속 된 단일 배열을 할당합니다. Java로 배열을 할당하면 배열이 아무 데나 가리킬 수있는 포인터로 채워지기 때문에 배열이 전혀 연속적이지 않습니다. 이는 이중 간접 메모리에 대한 메모리 및 시간 오버 헤드 일뿐만 아니라 캐시 오버 헤드이기도합니다. 이런 종류의 일은 Java의 언어 의미가 단순히 동등한 C ++ 코드보다 느려 야한다는 것을 강제하는 곳입니다.

궁극적으로 제 개인적인 경험은 Java가 평균적으로 C ++ 속도의 절반 정도가 될 수 있다는 것입니다. 그러나 기본적으로 다른 알고리즘이 포함되어 있기 때문에 매우 포괄적 인 벤치 마크 제품군 없이는 성능 설명을 백업 할 수있는 방법이 없습니다.

비. Java를 사용하여 최신 AAA 타이틀을 만들 수 있습니까?

나는 여기서 당신이 기회가 아니라 "게임"을 의미한다고 가정합니다. 먼저, 거의 모든 기존 라이브러리 및 인프라가 C ++을 대상으로하는 것처럼 모든 것을 처음부터 작성해야합니다. 그 자체로는 불가능하지는 않지만 실현 불가능한 방향으로 확실히 기여할 수 있습니다. 둘째, C ++ 엔진조차도 기존 콘솔의 작은 메모리 제약에 거의 맞지 않습니다 (해당 콘솔에 JVM이 존재하고 PC 게이머는 자신의 메모리에 조금 더 기대할 경우). C ++에서 퍼포먼스 AAA 게임을 만드는 것은 충분히 어렵지만 Java로 어떻게 달성 할 수 있는지 알 수 없습니다. 컴파일되지 않은 언어로 상당한 시간을 소비 한 AAA 게임을 만든 사람은 없습니다. 그 이상으로 오류가 발생하기 쉽습니다. 예를 들어 GPU 리소스와 Java를 다룰 때는 결정 론적 파괴가 필수적입니다.

씨. Java가 C ++보다 느린 영역은 무엇입니까? (예 : 숫자 처리, 그래픽 또는 그 밖의 모든 것)

나는 확실히 만능에 갈 것이다. 모든 Java 객체의 강제 참조 특성은 Java가 C ++보다 훨씬 더 많은 간접 참조와 참조를 가지고 있음을 의미합니다. C ++ 컴파일러가 일정한 시간에 멤버 변수를 찾을 수있는 경우 Java 런타임은 다른 포인터를 따라야합니다. 액세스가 많을수록 속도가 느려지고 JIT가 할 수있는 일은 없습니다.

C ++이 거의 즉시 메모리 조각을 비우고 재사용 할 수있는 곳에서는 Java에서 수집을 기다려야하며 조각이 캐시에서 떨어지지 않았으며 본질적으로 더 많은 메모리가 필요하면 캐시 및 페이징 성능이 저하되기를 바랍니다. 그런 다음 복싱 및 언 박싱과 같은 의미를 살펴보십시오. Java에서 int를 참조하려면 동적으로 할당해야합니다. 그것은 C ++ 의미와 비교할 때 고유 한 낭비입니다.

그런 다음 제네릭 문제가 있습니다. Java에서는 런타임 상속을 통해서만 일반 객체에서 작업 할 수 있습니다. C ++에서 템플릿은 문자 그대로 오버 헤드가 없으며 Java와는 비교할 수 없습니다. 이것은 Java의 모든 일반 코드가 본질적으로 C ++의 일반 코드보다 느리다는 것을 의미합니다.

그리고 당신은 정의되지 않은 행동에 온다. 프로그램에 UB가 표시되면 누구나 싫어하고, 존재하지 않기를 바랍니다. 그러나 UB는 근본적으로 Java에는 존재할 수없는 최적화를 가능하게합니다. UB를 기반으로 한 최적화를 설명하는 이 게시물을 살펴보십시오 . 동작을 정의하지 않으면 구현에서 더 많은 최적화를 수행하고 C ++에서 정의되지 않았지만 Java로 정의 된 조건을 확인하는 데 필요한 코드를 줄일 수 있습니다.

기본적으로 Java의 의미는 C ++보다 느린 언어임을 나타냅니다.

Java는 이제 컴파일 된 언어 또는 해석 된 언어로 간주됩니까?

이 두 그룹 중 어느 것도 적합하지 않습니다. 나는 매니지드가 실제로는 별도의 카테고리라고 말하고 싶지만 컴파일 된 언어보다 해석 된 언어와 더 비슷하다고 말하고 싶습니다. 더 중요한 것은 두 가지 주요 관리 시스템 인 JVM과 CLR 만 있고 "관리"라고 말하면 충분히 명시 적입니다.

초기부터 해결 된 Java의 주요 단점은 무엇입니까?

내가 아는 유일한 것은 자동 권투 및 언 박싱입니다. 제네릭은 몇 가지 문제를 해결 하지만 많은 문제와는 거리가 멀다.

아직 해결되지 않은 Java의 주요 단점은 무엇입니까?

그들의 제네릭은 매우 약합니다. C #의 제네릭은 상당히 강력하지만 물론 템플릿도 아닙니다. 결정 론적 파괴는 또 다른 주요 결점입니다. 모든 형태의 람다 / 클로저도 중요한 문제입니다. Java에서 기능적 API를 잊어 버릴 수 있습니다. 물론 성능이 필요한 영역에는 항상 성능 문제가 있습니다.

프로그래밍 언어에 대해 진정으로 중립적 인 의견을 제시하는 것은 거의 불가능하다는 조건으로 시작하겠습니다. 두 가지 언어를 모두 사용하여 의미있게 언급 할 수있을만큼 충분히 알고 있다면 다른 언어보다 선호하는 것이 거의 불가피합니다. 공정한 경고로서, Java보다 C ++을 선호하는데, 이는 의심의 여지없이 내 의견에 어느 정도 영향을 미칩니다.

1a. 속도 : C ++ 또는 Java에서 얻는 속도는 일반적으로이를 사용하는 프로그래머의 기술보다 언어 또는 구현에 덜 의존합니다. 궁극적으로 C ++ 은 속도보다 더 자주 이길 수 있지만 작성하는 코드의 차이는 실제로 중요합니다.
1b. 예, 아마도. 동시에 C ++은 이미 잘 확립되어 있으며 대부분의 게임 스튜디오가 Java 로의 전환을 귀찮게하는 데 충분한 이점을 보지 못할 것입니다.
1c. 이것에 대한 철저한 대답은 아마도 많은 양을 채울 수 있습니다. C ++은 일반적으로 제한된 리소스로 더 잘 수행됩니다. Java는 (예를 들어) 사용 가능한 "예비"메모리가 많을수록 더 많은 이점을 얻습니다.
2. 느린 실행과 느린 가비지 수집은 아마도 가장 명백한 두 가지 일 것입니다. 초기 윈도우 라이브러리 (AWT)는 매우 어색했습니다. 스윙은 크게 개선되었습니다.
3. 자세한 내용. 운영자 과부하 부족. 가비지 콜렉션 사용. 다중 상속 부족 Java Generics는 C ++ 템플릿에 비해 극히 제한적입니다.

이러한 단점 중 일부 (모두?) (특히 가비지 수집을 사용하지만 다른 것도 마찬가지)를 Java의 장점으로 볼 수 있다고 덧붙여 야합니다. 유일한 예외는 그 자세한 것입니다. 자세한 상황은 조금씩 조금씩 개선되고 있지만 Java 우승 코드 골프 대회는 자주 볼 수 없으며 일반적인 코드에서는 꽤 많은 코드를 사용하는 경향이 있습니다. 좀 더 읽기 쉽고 이해하기 쉬운 것으로 보이는 사람이 적어도 있다고 생각하므로 이점으로 볼 수도 있습니다.

1. 성능과 관련하여;
   1. 순수한 코드 실행 속도에서 Java는 간단한 C ++과 같습니다. 그러나 Java는 더 많은 메모리를 사용하는 경향이 있습니다. 부분적으로 GC 기반이기 때문에 부분적으로 디자인이 효율성보다 단순성과 안전에 더 중점을 둡니다. 캐시 문제로 인해 메모리가 많을수록 속도가 느려집니다. 많은 낮은 고도로 조정의 C ++에 비해.
   2. AAA 타이틀이 현재 하드웨어를 사용하여 가능한 것의 가장자리에서 작동해야한다고 가정한다면, 아닙니다. 적어도 클라이언트 측에는 없습니다. 일부 AAA 타이틀이 이미 백엔드 인프라의 일부에 Java를 사용하고 있다고 생각합니다.
   3. 큰 데이터 세트 및 C ++로 작업하는 모든 항목을 캐시 친화적 인 방식으로 액세스하도록 최적화 할 수 있습니다.
2. 바이트 코드로 컴파일되고 런타임에 JIT 컴파일됩니다. Compiled vs. Interpreted는 잘못된 오래된 이분법입니다.
3. & 4. 그것들을 모두 나열하기에는 너무 많은 것들이 있으며, 그들 대부분에 대해 의견이 맞지 않을 것입니다.

먼저 일부 컨텍스트에서 C ++은 매우 녹슨 것이므로 Java에 대한 대부분의 경험은 C #에 대한 최근 경험과 관련이 있습니다.

1. 속도

에이. 오늘날 Java의 속도는 C ++과 어떻게 비교됩니까?

나는 이것이 SO 질문에 가장 잘 대답한다고 생각합니다. 왜 java는 느리다는 평판을 얻었습니까? 그러나 나는 또한이 모든 질문이 Jeff Atwood의 블로그 게시물 Gorilla vs. Shark에 의해 채색되었다고 생각합니다 . ^{Péter & Christopher에게 감사합니다.}

비. Java를 사용하여 최신 AAA 타이틀을 만들 수 있습니까?

이는 개발자의 우선 순위와 개발자의 기술에 달려 있습니다. 또한 제목이 다르거 나 상황이 아니므로 제목의 다른 부분에 구현 된 언어의 다른 항목이 필요할 수 있으며 이기종 언어 환경으로 이어질 수 있습니다.

나는 최근에 그들이로드하는 동안 파이썬 환경을로드한다고 언급하는 많은 게임을 보았고 휴가 시즌에 맞춰 타이틀을 제 시간에 가져 가고 싶다면 코스 말이 강력한 동기가 될 것이라고 생각합니다 .

씨. Java가 C ++보다 느린 영역은 무엇입니까? (예 : 숫자 처리, 그래픽 또는 그 밖의 모든 것)

어떤 언어로도 성능이 저조한 코드를 작성할 수는 있지만 일부 언어는 더 나은 선택을 쉽게 해주는 반면 다른 언어는 자신 의 페타 드에 의해 호이스트 될 가능성이 높습니다 . Java는 전자의 범주에 속하고 C ++은 확실히 후자의 범주에 속합니다.

그들이 말한대로 큰 힘을 발휘하면 큰 책임 이 따릅니다 (힙을 완전히 망치는 능력은 말할 것도 없습니다 * 8 ').

2. Java가 이제 컴파일 된 언어 또는 해석 된 언어로 간주됩니까?

나는 대부분의 사람들이 그것을 생각 한다고 말할 수는 없지만 많은 사람들이 컴파일 된 언어와 해석 된 언어의 차이점을 알고 있으며 지난 20 년 동안 동굴에 살지 않았다면 JIT ( Just-in -Time ) 컴파일러는 Java 생태계의 중요한 부분이므로 요즘에는 컴파일 된 것으로 간주 될 가능성이 높습니다.

3. 초기부터 해결 된 Java의 주요 단점은 무엇입니까?

나는 꽤 최근에 Java로 변환했기 때문에 어떻게 진화했는지에 대한 맥락이 거의 없습니다. 그러나 Java 와 같은 책이 있다는 사실에 주목하는 것은 흥미 롭습니다 . 요즘 선호해야 할 언어 부분의 방향으로 사람들을 이끌고 사람들을 멀게하거나 더 이상 사용되지 않습니다.

4. 아직 해결되지 않은 Java의 주요 단점은 무엇입니까?

내 생각에 Java의 한 가지 문제는 새로운 기능의 느린 채택입니다.

C #에서 Java로 왔고 Wikipedia 비교 페이지를 살펴보면 다음과 같은 것들이 눈에 that니다.

C #과 비교하여 Java에서 놓친 것

• 속성 , 특히 자동 속성. 인터페이스를 보다 쉽게 구축하고 유지 관리 할 수 있습니다.
• 폐쇄 / 람 다리 . Java 지원이 다시 추진되고 있다는 소식을 들었을 때 정말 실망 했습니다 . ^{마지막으로 Java 8에는 Closures / lambdas가 있지만 느린 채택에 대한 진술을 증명하는 데 걸린 시간입니다.}
• 형식 유추 ( var)는 구문 설탕처럼 보일 수 있지만 복잡한 제네릭 형식 을 사용하는 경우 많은 중복을 제거하여 코드를 훨씬 더 명확하게 만들 수 있습니다 .
• 부분 클래스 는 자동으로 생성 된 코드 (예 : GUI 빌더 등)를 프로그래머가 작성한 코드와 별도로 유지하는 데 도움이됩니다.
• 값 유형 , 때로는 struct전체 클래스 에서 경량을 사용하는 것에 대한 논쟁이 있습니다.
• 확장 메서드 는 시스템을 과도하게 사용하면 복잡해 지지만 필요한 경우 클래스에 무언가를 구현하는 표준 방법을 나타내는 데 유용 합니다.
• 부호없는 유형 , 때로는 여분의 비트가 모든 차이를 만들 수 있습니다. * 8 ')

C #과 비교하여 Java에서 놓치지 않는 것들

• 연산자 오버로드 는 올바르게 사용될 때 좋지만 잘못 사용하면 버그를 찾기가 어려워지고 연산자가 분명히 해야하는 것과 실제로 하는 것 사이의 연결이 끊어 질 수 있습니다.
• 널 입력 가능한 값 유형은 항상 가치보다 더 많은 문제를 일으키는 것으로 보였습니다.
• unsafe코드에 액세스합니다 . 당신은해야 그래서 나는 거의 여분의 노력이 가치를 발견 한 것을이 조심.

따라서 사과를 사과와 비교할 때도 Java는 뒤쳐진 것으로 간주됩니다.

Java에서 볼 수있는 다른 두 가지 큰 문제는 엄청난 시작 지연과 (일부 JVM의 경우) 힙 및 영구 생성 힙 을 미세 관리해야 한다는 사실입니다 . C # 응용 프로그램을 사용하면 항상 즉시 시작되므로 가상 머신에 할당 된 사전 할당 풀이 아니라 시스템 메모리 풀에서 할당 되었기 때문에 힙에 대해 생각할 필요가 없었습니다.

질문의 첫 부분에 대한 답변을 제공 할 수있는 출처를 알려 드릴 수 있습니다. 프로그래밍 언어 는 http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php 는 언어가 서로 얼마나 빠른지 비교할 수있는 좋은 소스입니다. 언어가 다른 범주보다 더 나은 영역을 찾기 위해 다른 범주로 필터링 할 수도 있습니다. Java는 몇 년 전보다 훨씬 빠릅니다.

1) Java로 얻는 UX에 대해 엄격하게 이야기하면 느립니다. 왜 그런지 말할 수 없습니다. 느리게 느끼지 않고 더 빠른 비 Java 대안이 있는 Java 기반 데스크탑 응용 프로그램을 아직 보지 못했습니다 . 즉, Java는 순수한 계산 속도로 매우 빠를 수 있으며 인터넷에는이를 입증하는 벤치 마크가 가득합니다. 그러나 Java 앱의 부팅 시간과 GUI의 응답 성은 아직 IMHO를 개선하지 못했습니다. 어쩌면 당신은 그것을 할 수 있습니다;)
결국, 속도는별로 문제가되지 않습니다. 하드웨어가 점점 더 빨라질뿐만 아니라 소프트웨어가해야 할 일, 수행해야 할 작업 및 대기 시간 대 대기 시간의 비율이 합리적이라면 대부분의 사람들은 여전히 ​​놀라 울 정도로 작은 관심을 기울이고 있습니다.

2)이 차이는 최근에 너무 모호 해져서 가치가 거의 없습니다.

3 + 4) 실제로 Java에는 상당한 변화가있었습니다. 일부 사람들은 이러한 변화로 인해 외계인 기능을 강화함으로써 Java의 단순한 철학을 오염 시켰다고 주장합니다. 객관적으로 말하기, 단점이 무엇인지, 그리고 힘이 무엇인지 말하기는 정말 어렵습니다. 나에게 Java는 불필요하게 장황하고 제한적이며 기능이 열악한 반면 다른 사람들은 이러한 특성을 즐거운 모호성, 안전 및 선명도로 간주합니다.
따라서 개인적으로 Java를 사용하지 못하게하는 것은 Java에서 누락 된 것을 추가하는 것이 좋은 생각이라고 생각하지 않습니다. JVM에서 실행하고 Java에 더 가깝게 벤딩하는 것을 좋아하는 많은 언어가 Java의 목적을 무효화합니다.

그것은 선호의 문제입니다

Java의 장점은 사용자가 발에 쏠 수 없도록 설계되었다는 것입니다. 고귀한 원인이지만, 그것이 당신에게 묶는 모든 제한 사항으로, 당신이 안전한 발 중 하나를 넘어서 손을 등 뒤로 묶어 자신의 안전을 위해 자신을 묶을 수 없으며, 결국 죽을 가능성은 거의 없습니다. 당신이 당신의 두개골을 깰 때문입니다. : D
어떤면에서, Java는 C ++에 대한 응답으로, 자신뿐만 아니라 다른 세계에도 매달릴 수있는 충분한 밧줄을 제공합니다. 그것은 모든 밧줄이기 때문에 카우보이에게 매우 매력적입니다. 그 모든 자유와 모든 힘.

간단히 말해서, 이것은 실제로 선호의 문제입니다.

그러나 요점은 Java의 대안으로 C ++을 사용하면 자신의 제한을 자유롭게 선택할 수 있다는 것입니다. 또는 당신이 가진 모든 통제력을 제대로 이해하지 못하여 동료들을 완전히 혼동시킬 위험이 있습니다.

나는 'cout'이 "Hello world"로 왼쪽으로 이동하는 것을 보았습니다.
— 스티브 고네 데스

Java는 바로 그 이유로 운영자 과부하를 제공하지 않기로 결정했습니다. 물론 이것은 함수 포인터에 목록을 곱하여 사람들이 코드를 난독 화하는 것을 방지합니다. 그러나 동시에 다른 사람들이 일반적인 연산자로 기하학적 / 대수 계산을 수행하지 못하게합니다. (v1 * v2 / scale) + (v3 * m)정말 많은 것보다 명확 v1.multiply(v2).divide(scale).add(v3.multiply(m)). 이것이 왜 3D 그래픽과 계산을 다루는 사람들을 해치게 할 수 있는지 봅니다.

Java는 가비지 수집을 선택했지만 C ++에서는 선택할 수 있습니다. 실제로 모든 것을 파헤 치고 하드웨어에 가까이 갈 수 있습니다. 데이터를 밀도가 높은 구조체로 묶을 수 있습니다. 빠른 역 제곱근 과 같은 어두운 마법을 수행 할 수 있습니다 . 템플릿을 사용하여 지구상에서 가장 복잡하고 암호화 된 메타 프로그래밍을 수행 할 수 있습니다. 그러나 그것은 또한 당신이 잃어 버렸고 당신이 만든 모든 혼란을 디버깅하거나 절대적으로 도움이되지 않는 컴파일러 오류를 조사하는 데 몇 시간을 소비 할 수 있음을 의미합니다.
그러나 실제로 마스터하는 언어의 일부만 사용하는 규칙이 있다면 Java 코드와 마찬가지로 안전하게 C ++ 코드를 작성할 수 있지만 점차 발전 할 수 있습니다.

따라서 기술적으로 Java로 최첨단 소프트웨어를 작성하는 것을 막을 수있는 것은 없지만 많은 개발자들이 Java를 언어로 제공하는 것 이상으로 나아가면서 훌륭한 소프트웨어를 작성하고 재미 있고 발전하는 것에 열정을 가지고 있음을 알게 될 것입니다.

그러나 세상은 사람들이 다음 큰 것을 창조 하거나 그들에게 주어진 힘의 사용을 통제 할 수있는 한 제한 할 사람들로만 구성되어 있지는 않습니다 . IMHO Java는 편안한 방식으로 안정적인 결과를 생성하려는 사람들에게 완벽한 조화입니다.

가비지 콜렉션이 가장 중요합니다. 종종 GC는 힙 크기에 따라 수백 밀리 초 동안 다른 모든 것을 잠그고 주요 컬렉션을 수행합니다. 타이밍 제약 조건이없는 경우에는 문제가 없지만, 늦는 것이 실패를 의미하는 경우에는 쇼 스토퍼입니다. 실시간 Java 및 실시간 OS에 돈을 쓸 수 있지만 GCC 및 표준 Linux를 사용하면 이러한 문제가 발생하지 않습니다.

예측할 수없는 임의의 일시 정지가없는 경우 Java는 요즘 대부분의 경우에 충분히 빠릅니다. 그리고 GC 설정을 조정하는 데 몇 달을 소비한다면 어쩌면 아마도 고객이 수표를 깎을 수있을 정도로 오래 작동 할 수 있습니다.

3) 수정 된 단점.

몇 년 전에 자바에 대한 분노가 많았습니다. 대부분의 Java 프로그래머는 웹 / 서버 프로그래머이며 Java의 장황함에 열중했습니다. 그래서 Ruby와 같은 일부 언어가 인기를 얻었고 Java는 약해지기 시작했습니다. 그러나 최대 절전 모드 및 Spring과 같은 새로운 주석 및 프레임 워크로 사람들은 불만을 멈추고 Java로 돌아갔습니다.

4) 현재 결점

하드웨어는 모두 멀티 코어입니다. Java는 다중 스레드를 수행 할 수 있지만 순차적 언어 인 C를 기반으로하며 다중 스레드를 만드는 기능은 우아하지 않습니다. 그건 그렇고, 그것은 Java의 비판뿐만 아니라 거의 모든 언어입니다. 코드에 대한 완전히 다른 사고 방식이 필요합니다. 아마도 함수형 프로그래밍은 미래의 방법 일 것입니다.

나는이 질문에 오해의 소지가 있고 크게 관련이없는 답변을 줄 것이기 때문에 반응했습니다.

비. Java를 사용하여 최신 AAA 타이틀을 만들 수 있습니까?

누구나 AAA 타이틀이 Java를 사용하여 생산하기 어려울 것이며 내가 알고있는 실제 예가 없다는 것에 동의 할 수 있습니다. 그러나 AAA의 특성상 많은 것을 가정 할 것이므로 (실제로 마케팅에서 오는 혼란스러운 용어 이므로) 대신 다음을 묻는 것이 좋습니다.

Java를 사용하여 합리적인 성공으로 현대적인 타이틀을 만들 수 있습니까?

대답은 " 예, 가능합니다. "입니다. 그러나 방정식 의 실제 성공 부분 은 귀하의 끈기와 행운 (또는 Zeitgeist 준수)을 기반으로하지만이 사이트의 범위를 벗어납니다.

certian 속도 영역은 컴파일러와 컴파일러로 나옵니다. 언어 대 언어가 아닙니다. JIT 컴파일은 실행중인 머신의 스펙에 맞게 최적화 할 수 있으므로 이점이 있습니다. JIT 컴파일 된 C ++과 Java를 비교하여 "애플 대 사과"컴파일러 비교를 비교하십시오.

그러나 Java 언어 자체가 자체 성능을 제한하는 몇 가지 사항이 있습니다.

1. 스택에 할당. 자바는 이것을 할 수 없습니다. 비 재귀 솔루션의 작은 고정 크기 클래스의 경우 종종 이상적입니다. 힙 조각화를 피할 수도 있습니다.

2. 비가 상 기능. 자바는 이것을 할 수 없습니다. 재정의 될 계획이없는 경우에도 모든 메서드 호출은 영구 적중을받습니다.

아마도 다른 것들이지만, 그것이 내 머리 꼭대기에서 생각할 수있는 전부입니다.

1) 부적절하고 부팅에 대한 논쟁.
Java로 주요 소프트웨어를 생성 할 수있을뿐만 아니라 이러한 시스템은 매일 제공되며 현재 전세계 대부분의 주요 회사를 운영하고 있습니다.
2) 디토.
JVM 스펙을 읽으십시오. 자바는 결코 통역 된 언어가 아니었다.
3) ditto.
15 년 간의 릴리스 정보를 읽으십시오. "주요 결함"으로 간주되는 사항을 해결하는 것이 불가능합니다.
4) ditto.
해결해야 할 주요 결함은 JSR로 JSR에서 소모 네의 이름을 얻는 것 외에는 명백한 이유없이 핵심 언어 및 라이브러리와 혼동하기 쉬운 JCP입니다. JSR-666의 리더 " JCP에 대한 오라클의 구조 조정이이를 해결하기를 바랍니다.
여기서 언어 전쟁을 일으키고 Java에 대한 편견을 다른 사람들로부터 확인 받으려고합니다. 실제로 정당성을 찾을 수 없기 때문입니다.