귀사는 Java에서 다른 기술로의 전환을 생각하고 있습니까? [닫은]


9

모든 Java 개발자가 알고 있듯이 Oracle은 Sun을 인수했으며 Java의 미래는 확실하지 않습니다. 특히 Oracle이 JVM 을 통해 수익창출 하고자하기 때문 입니다. 지난 몇 년간 언어로서 Java가 오래되었다. 클로저를 포함하지 않는 것이 하나의 예이다 (Java 1.8에 포함될 수 있음) 동시에 Ruby, Scala 및 Groovy와 같은 일부 새로운 기술이 사용되고있다 복잡한 사이트를 제공합니다.

15 년 전 회사가 C ++ 양식을 마이그레이션 한 것과 같은 방식으로 그린 ​​필드 프로젝트에 Java 사용을 중단하려는 아이디어로 말을하거나 스파이크를하거나 다른 기술을 사용하기 시작한 회사 나 조직이 있는지 궁금합니다. Java에 대한 기타 기술. 또한 2 년 후에 다른 기술로 마이그레이션 할 계획을 세우는 등의 일이 어떤 영향을 받는지 알고 싶습니다.

분명히, 나는 어떤 기술이 더 나은지 묻지 않습니다. 조직에서 다른 기술을 위해 Java를 떠날 생각인지 묻고 있습니다.


1
Groovy와 Scala가 JVM에 의존하지 않습니까? 그렇다면 오라클은 JVM을 통해 수익을 창출하기를 원합니다.
POSIX_ME_HARDER

네가 옳아. 이는 오픈 jvm 대신 상업용 jvm을 원하는 회사에서 Scala, Groovy 또는 JRUby 채택에 영향을 미칩니다. 다른 언어를 사용하기 위해 상용 JVM에 대한 비용을 지불 할 수 있다고 생각하는 원래 질문은 그대로 두겠습니다.
Augusto

Java 개발자로서 "모든 Java 개발자가 알고 있듯이"문에 문제가 있습니다. Java의 미래는 a) Clear와 b) Bright라고 생각합니다. 필자는 일부 사람들이 오라클의 "프리미엄"지원 패키지에 대해 추가 비용을 지불하고 싶을 것이라고 생각하지만 무료 오픈 소스 버전의 Java (고장 나지 않을 것임)를 고수하고자하는 사람들에게는 그렇게 할 것이다. 다소 관련이 없습니다.
mikera

Mikera는 오픈 소스에 대해 언급했지만 오픈 소스 프로젝트를 이끌었던 영향력있는 Java 개발자 중 일부는 현재 다른 언어로 프로젝트를 주도하고 있으므로 "에너지"가 Java에서 멀어졌습니다. Scala, Groovy 또는 Ruby를위한 놀라운 프레임 워크를 모두 확인하십시오. 나는 이것을 뒷받침 할 숫자가 없지만, 다른 주류 언어와 경향으로 오픈 소스 저장소를 만들기 위해 얼마나 많은 "코드 라인"이 사용되었는지 확인하는 것이 흥미로울 수있다.
Augusto

답변:


9

사실은 아닙니다. 사실 저는 회사의 플랫폼 (데이터 마이닝을위한 SaaS 애플리케이션 및 도구를 개발하는 스타트 업)으로서 Java에 많은 투자를하고 있습니다.

이유는 다음과 같습니다.

  • Java를 플랫폼으로 선택 한다고해서 Java를 언어로 사용해야한다는 의미는 아닙니다. 우리는 Clojure 를 기본 애플리케이션 개발 언어로 사용하고 때로는 필요한 경우 Java로 넘어갑니다. 그러나 Scala 및 Groovy와 같은 다른 JVM 언어도 훌륭합니다.

  • 개인적으로 오라클에 대해 걱정하지 않습니다 . Java의 주요 구현은 거의 확실히 오픈 소스 ( OpenJDK )이며 무료로 제공 될 것입니다. 오라클이 어리석은 짓을했다면 다른 대기업들 (특히 IBM과 Google이 생각합니다)이 Java에 너무 많은 투자를해서 그 문제를 해결할 수 없었으며, 오라클의 도움 없이도 Java를 쉽게 계속 개발할 수있었습니다.

  • JVM은 훌륭한 실행 환경입니다 . 크로스 플랫폼, 고성능, 매우 최적화 된 JIT 기술. C / C ++보다 느린 소수 부분에 대해서는 신경 쓰지 않을 정도로 기본 속도에 가깝습니다.이 오버 헤드는 적절한 가비지 수집 및 관리되는 바이트 코드 실행 환경 등으로 보완됩니다.

  • 자바는 훌륭한 오픈 소스 라이브러리 생태계를 가지고있다 . 사실, 나는 그것이 모든 언어 중에서 가장 좋은 생태계라고 말하고 싶습니다. 이는 인프라 측면에서 대부분의 "무거운 리프팅"이 이미 매우 높은 품질로 수행되었음을 의미합니다. 그리고 필요한 대부분의 것이 오픈 소스라는 사실은 라이센스를 얻는 데 드는 비용 (비용 및 관리 시간 모두)이 없다는 것을 의미합니다.

  • Eclipse 는 훌륭한 IDE이며 강력한 엔터프라이즈 애플리케이션 개발을위한 환상적인 툴체인 을 제공합니다 . 우리는 Maven, JUnit, Git / SVN 통합 및 Eclipse 플러그인으로 사용할 수있는 다양한 도구를 사용합니다. 그것은 모두 "그냥 작동합니다".

마지막으로 다른 옵션은 무엇입니까?

  • .NET은 필적 할만한 기능을 갖춘 유일한 플랫폼이며 개인적으로 C #을 좋아하지만, Oracle / IBM IMHO보다 나쁜 Microsoft 기술에 얽매이지 않으며 광범위한 오픈 소스 에코 시스템이 없습니다. Microsoft 상점에는 적합하지만 자신의 기술적 운명을 통제하려는 경우에는 적합하지 않습니다. 그렇습니다. 모노는 귀엽지 만 .NET 메인 스트림과의 호환성을 유지하거나 유지할 수없는 플랫폼에서 비즈니스에 베팅 할 여유가 없습니다.

  • 그런 다음 자신이하는 일에 능숙하지만 (예 : Ruby, Python, PHP, Javascript) 다른 모든 훌륭한 언어가 있지만 Java 플랫폼과 강력하고 포괄적 인 기능을 제공하지는 않습니다. 위험은 당신이 아름다운 것보다 약간 적은 아키텍처로 많은 것들을 함께 붙이기 시작해야한다는 것입니다. 웹 사이트 구축, 빠르고 더러운 앱 제작에는 문제가되지 않지만 장기적인 제품 개발에 대한 매력은 떨어집니다.

  • C / C ++는 시스템 프로그래밍 및 게임에는 적합하지만 최신 웹 응용 프로그램 개발에는 너무 복잡하고 비용이 많이 들고 융통성이 없습니다.

  • 그리고 학문적 관점에서 환상적이지만 신뢰할 수있는 플랫폼을 선택하는 데 필요한 업계 채택 / 생태계가없는 Haskell과 같은 내가 좋아하는 아름다운 언어가 있습니다. 또한 JVM에서 Clojure를 실행하여 최신 기능 프로그래밍의 이점을 대부분 얻을 수 있습니다 .....

그렇습니다. 복잡한 결정입니다. 그러나 많은 연구와 고려 끝에 Java를 다른 모든 옵션보다 먼저 결정했습니다. 나는 오늘도 여전히 같은 결정을 내릴 것입니다.

최신 정보

JVM에서 언어 선택으로 Clojure를 선택하는 것에 대한 몇 마디. 이에 대한 주요 동기는 다음과 같습니다.

  • 동시성-Clojure에는 고유 한 동시성 스토리 가 있으며 핵심 개념 중 일부를 설명하는 이 비디오 를 시청 하는 것이 좋습니다. Software Transactional Memory 를 사용하여 대규모 멀티 코어 아키텍처로 안정적으로 확장 할 수 있습니다 . 그리고 많은 오버 헤드 (lock-free!)없이이 작업을 수행 할 수 있습니다.
  • 함수형 프로그래밍-Clojure는 불변성과 고차 함수를 강조하는 함수형 언어입니다. 하스켈만큼 순수하게 기능하지는 않지만 가장 먼저 FP 언어입니다. 어떤 사람들은 이것이 더 좋은 프로그램을 작성하는 데 도움이된다고 말합니다.
  • 프로그래머 생산성-Clojure는 Lisp 코드 데이터 철학의 모든 생산성 이점을 얻습니다. 실제로 이것은 엄청나게 강력한 매크로 기능과 처리하는 모든 문제에 대해 고유 한 DSL을 정의하는 데 사용할 수있는 단순하지만 매우 유연한 구문을 의미합니다.
  • 신속한 개발 및 스크립팅에 적합한 동적 언어가 필요합니다. Clojure는 표준 빌드 테스트 배포주기에서 사용할 수 있지만 실제로 REPL을 사용하여 대화식으로 개발하여 실행중인 코드 환경을 수정하는 것이 더 자연 스럽습니다. 예를 들어, Incanter 를 사용 하여 배치 실행 결과를 볼 수 있도록 개발하면서 그래프를 작성하고 데이터를 즉시 시각화 할 수 있습니다.
  • Java 상호 운용성-Clojure의 Java interop은 매우 효과적입니다. Clojure 객체는 Java 객체이며 그 반대도 가능하므로 필요할 때마다 Java API 및 라이브러리를 호출하는 것은 쉽지 않습니다. 이는 전체 Java 에코 시스템 라이브러리 및 도구의 모든 이점을 제공합니다.
  • 좋은 커뮤니티 – Clojure의 커뮤니티는 작지만 역동적이고 친근하며 빠르게 성장합니다. 같은 이미 훌륭한 오픈 소스 프로젝트, 많은 주문 술사 (통계 컴퓨팅) 또는 / Compojure (웹 서버 프레임 워크) 또는 반 시계 (이클립스 IDE 플러그인)

Mikera, 이것이 바로 내가 요구 한 것입니다. 귀사에서는 Java를 애플리케이션 개발의 기본 언어로두고 대신 Clojure를 사용하고 있습니다. 특히 JVM 위에서 실행되는 다른 언어에 투자하는 일부 회사 에서는 JVM이 사라지지 않을 것에 동의합니다 . 클로저를 주요 개발 언어로 사용하기로 결정한 이유에 대해 조금 더 이야기 해 주시겠습니까?
Augusto

물론, 나는 Clojure가 왜 특히 유망한 지에 대한 논평을 추가했습니다 (또한 매우 유망한 Scala를 고려했지만 Clojure는 Lisp-ness 때문에 좁은 마진으로 이겼습니다)
mikera

귀사가 클로저를 사용하기로 결정한 이유에 대한 설명에 감사드립니다!
Augusto

7

그것은 모두 고객에 달려 있습니다.

Java는 사람들이 .php 또는 .net에 끌리는 것과 같은 이유로 사람들이 어떤 이유로 든 Java에 끌리는 자체 틈새 시장을 가지고 있지만 궁극적으로 고객의 요구 사항과 선호도에 달려 있습니다.

고객이 다음과 같이 말하면 ...이 응용 프로그램이 Java로 작성되기를 원합니다 ... 아니오라고 말할 것입니까? 아마도 ... 그들이 정말로 신경 쓰지 않는다고 말하면 .... 우리는 그것을 자바로 쓸 것입니까? 아마 아닙니다, 그러나 그것은 단지 추측입니다.

우리는 오랜 역사를 가진 Java로 작성된 응용 프로그램을 가지고 있지만 고객은 모든 것을 Windows 브랜드로 세 심하게 대체하는 것으로 보입니다 .... Oracle to SQL Server ... Unix / Linux with Server 2008 ... .net과 자바.

만약 그렇다면 새로운 고객이 들어 와서이 말을하지 않으면 ... 우리는 이것을 자바로 작성하기를 원합니다. 우리는 .net을 사용할 것입니다.


미국의 한 대형 자동차 소매 업체는 비슷한 일을하고 있으며 대부분의 그린 필드 프로젝트를 Java가 아닌 루비로 구축하기 시작했습니다.
Augusto

1

우선 전제로 저는 소프트웨어 회사에서 일하지 않습니다.

우리는 Oracle을 주요 데이터베이스로 사용하고 모든 중요한 정보를 저장했습니다. 이 때문에 Oracle과 관련하여 Java를 계속 사용할 계획입니다. Oracle의 Sun 인수는 Oracle과 관련된 모든 작업에 Java를 계속 사용하는 데 도움이됩니다.

그러나 모든 데스크톱 응용 프로그램은 Windows 기반이기 때문에 C #으로 작성됩니다.


0

귀사는 Java에서 다른 기술로의 전환을 생각하고 있습니까?

당신에게 질문에 대답합니다. 아니.

모든 Java 개발자가 알고 있듯이 ...

규모가 큰 회사에서는 일반적으로 회사가 Java에서 다른쪽으로 이동해야하는지 여부와 같은 문제를 결정하는 개발자가 아닙니다. 그리고 이러한 결정을 내리는 유형의 경우 귀하가 기재 한 것 이외의 다른 요소가 중요합니다.

... 오라클이 JVM으로 수익을 창출하기를 원하기 때문에 자바의 미래는 분명하지 않습니다.

오히려 미래는 분명하다고 생각합니다. Java 발전은 느리지 만 꾸준한 속도로 계속 될 것이며 핵심 SE 및 EE 기술은 계속 무료입니다. 저에게있어 불확실성의 유일한 영역은 Oracle vs Google bunfight에서 일어날 일입니다. 그러나 어떤 식 으로든 안드로이드 / Davlik은 Java ME의 대안으로 번영 할 것으로 기대하지만 모바일 플랫폼에서만 가능합니다.

Java로서 언어는 지난 몇 년 동안 오래되었다. 클로저를 포함하지 않는 것이 하나의 예이다 (Java 1.8에 포함될 수 있음).

이것은 개발자에게 자극을 줄 수 있지만 "정말 성"은 실제로 비즈니스가 원하는 것에주의를 기울인 결과로 장기적으로 안정된 언어 / 플랫폼 인 Sun / Oracle의 결과입니다.

동시에 Ruby, Scala 및 Groovy와 같은 일부 새로운 기술이 복잡한 사이트를 제공하는 데 사용되고 있습니다.

다시 한번, 경영 관점에서 배심원은 이러한 기술이 전반적으로 더 나은지 여부에 대해 판단합니다.

  • 주장 된 생산성 향상 장기적으로 증명할 수 있습니까?
  • 아직 성능이 있습니까? 확장 성? 타사 도구 및 라이브러리?
  • 숙련 된 직원을 채용 할 수 있습니까?

새 언어로 전환하려는 회사 수준의 결정에는 특히 "레거시"언어로 기존 코드가 상당량있는 경우 상당한 비용과 위험이 따릅니다.


@Augusto-귀하의 질문에 답변했습니다. 첫 문장을 보라. 지금 행복하니?
Stephen C
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.