Công ty của bạn có nghĩ đến việc chuyển đổi từ java sang công nghệ khác không? [đóng cửa]


9

Như mọi nhà phát triển Java đều biết, Oracle đã mua Sun và tương lai của java có vẻ không rõ ràng, đặc biệt vì Oracle muốn kiếm tiền từ JVM. Java như một ngôn ngữ cũng đã trở nên cũ kỹ trong vài năm qua, việc không bao gồm các bao đóng là một ví dụ (có thể có trong java 1.8) Đồng thời, một số công nghệ mới như Ruby, Scala và Groovy đang được sử dụng để cung cấp các trang web phức tạp.

Tôi tự hỏi liệu có công ty hay tổ chức nào đang nói chuyện, làm đột biến hoặc bắt đầu sử dụng một công nghệ khác, với ý tưởng ngừng sử dụng java cho các dự án lĩnh vực xanh, giống như cách mà 15 năm trước các công ty đã di chuyển từ C ++, perl và các công nghệ khác cho Java. Tôi cũng muốn biết những ấn tượng của việc này xảy ra là gì, ví dụ: dự định chuyển sang một công nghệ khác trong 2 năm.

Để rõ ràng, tôi không hỏi công nghệ nào là tốt hơn. Tôi đang hỏi liệu tổ chức của bạn có nghĩ sẽ rời Java để lấy công nghệ khác không.


1
Không phải Groovy và Scala phụ thuộc vào JVM? Nếu vậy, họ cũng lo ngại bởi Oracle muốn kiếm tiền từ JVM.
POSIX_ME_HARDER

Bạn đúng. Điều đó sẽ có tác động đến việc áp dụng Scala, Groovy hoặc JRUby trong các công ty muốn jvm thương mại thay vì jvm mở. Tôi sẽ không để lại câu hỏi ban đầu vì tôi nghĩ rằng một số công ty có thể vui lòng trả tiền cho JVM thương mại để sử dụng một ngôn ngữ khác
Augusto

Là một nhà phát triển Java, tôi gặp vấn đề với câu lệnh "như mọi nhà phát triển Java đều biết". Tôi nghĩ rằng tương lai của Java là cả a) Rõ ràng và b) Sáng sủa. Tôi chắc rằng một số người có thể muốn trả thêm tiền cho gói hỗ trợ "cao cấp" của Oracles, nhưng đối với những người trong chúng ta chỉ có kế hoạch gắn bó với phiên bản Java miễn phí, nguồn mở (sẽ không biến mất!) Thì đó hơi không liên quan.
mikera

Mikera, bạn đề cập đến nguồn mở, nhưng một số nhà phát triển java có ảnh hưởng đã từng dẫn dắt các dự án nguồn mở, hiện đang dẫn đầu các dự án bằng các Ngôn ngữ khác, vì vậy "năng lượng" của họ bị chuyển hướng khỏi java. Kiểm tra tất cả các khung tuyệt vời hiện có cho Scala, Groovy hoặc Ruby. Tôi không có số để sao lưu điều này, nhưng thật thú vị khi kiểm tra xem có bao nhiêu "dòng mã" đã được cam kết để lưu trữ nguồn mở trong các ngôn ngữ chính và xu hướng khác nhau.
Augusto

Câu trả lời:


9

Hoàn toàn không - thực tế tôi đang đầu tư rất nhiều vào Java như một nền tảng tại công ty của tôi (một công ty khởi nghiệp phát triển các ứng dụng và công cụ SaaS để khai thác dữ liệu).

Dưới đây là những lý do:

  • Chọn Java làm nền tảng không có nghĩa là bạn phải sử dụng Java làm ngôn ngữ. Chúng tôi sử dụng Clojure làm ngôn ngữ phát triển ứng dụng chính, thỉnh thoảng thả vào Java khi cần thiết. Nhưng các ngôn ngữ JVM khác như Scala và Groovy cũng rất tuyệt.

  • Cá nhân tôi không lo lắng về Oracle . Việc triển khai chính của Java gần như chắc chắn sẽ tiếp tục là nguồn mở ( OpenJDK ) và có sẵn miễn phí. Nếu Oracle làm bất cứ điều gì ngu ngốc thì các công ty lớn khác (đặc biệt là tôi nghĩ IBM và Google) đã đầu tư quá nhiều vào Java để cho phép họ thoát khỏi nó và họ có thể dễ dàng tiếp tục phát triển Java mà không cần sự trợ giúp của Oracle.

  • Các JVM là một môi trường thực thi lớn . Đa nền tảng, hiệu năng rất cao, tối ưu hóa công nghệ JIT cực kỳ tốt. Nó đủ gần với tốc độ bản địa mà tôi không quan tâm đến số lượng phân đoạn mà nó chậm hơn C / C ++ và chi phí này được bù đắp nhiều hơn bởi bộ sưu tập rác thích hợp và môi trường thực thi mã byte được quản lý, v.v.

  • Java có một hệ sinh thái tuyệt vời của các thư viện nguồn mở . Trên thực tế, tôi muốn nói rằng đó là hệ sinh thái tốt nhất trong mọi ngôn ngữ. Điều này có nghĩa là hầu hết các "việc nặng" về cơ sở hạ tầng đã được thực hiện, với chất lượng cực kỳ cao. Và thực tế là hầu hết những thứ bạn cần là nguồn mở có nghĩa là bạn không có chi phí (về cả tiền bạc và thời gian quản lý) để có được giấy phép.

  • Eclipse là một IDE tuyệt vời và cung cấp một chuỗi công cụ tuyệt vời để phát triển các ứng dụng doanh nghiệp mạnh mẽ. Chúng tôi sử dụng tích hợp Maven, JUnit, Git / SVN và một loạt các công cụ khác có sẵn dưới dạng các trình cắm thêm của Eclipse. Tất cả "chỉ hoạt động".

Cuối cùng, các tùy chọn khác là gì?

  • .NET là nền tảng duy nhất có khả năng tương đương và cá nhân tôi thích C #, nhưng nó khóa bạn vào các công nghệ của Microsoft (tệ hơn cả Oracle / IBM IMHO) và không có cùng chiều rộng của hệ sinh thái nguồn mở. Tốt cho các cửa hàng Microsoft, nhưng không phải nếu bạn muốn kiểm soát vận mệnh công nghệ của riêng bạn. Và vâng, Mono rất dễ thương, nhưng tôi không đủ khả năng đặt cược doanh nghiệp của mình vào một nền tảng có thể hoặc không thể duy trì mức độ tương thích làm việc với dòng chính .NET.

  • Sau đó, có tất cả các ngôn ngữ tuyệt vời khác rất giỏi trong những gì họ làm (ví dụ: Ruby, Python, PHP, Javascript) nhưng không cung cấp một nền tảng toàn diện, hấp dẫn tương đương với nền tảng Java. Rủi ro là bạn phải bắt đầu dán nhiều thứ lại với nhau trong một kiến ​​trúc hơi kém đẹp. Không phải là một vấn đề để xây dựng trang web, ứng dụng nhanh và bẩn, nhưng ít hấp dẫn hơn để phát triển sản phẩm lâu dài.

  • C / C ++ rất tốt cho lập trình hệ thống và trò chơi, nhưng quá phức tạp / tốn kém / không linh hoạt để phát triển ứng dụng web hiện đại.

  • Và sau đó, có những ngôn ngữ đẹp mà tôi yêu thích như Haskell, vốn tuyệt vời từ góc độ học thuật nhưng chỉ cần không có sự chấp nhận ngành / hệ sinh thái cần thiết để biến chúng thành một lựa chọn nền tảng đáng tin cậy. Ngoài ra tôi có thể nhận được hầu hết các lợi ích của lập trình chức năng hiện đại bằng cách chạy Clojure trên JVM .....

Vì vậy, có, đó là một quyết định phức tạp. Nhưng tôi đã đưa ra quyết định Java trên tất cả các tùy chọn khác sau rất nhiều nghiên cứu và xem xét đáng kể. Tôi vẫn sẽ đưa ra quyết định tương tự ngày hôm nay.

CẬP NHẬT

Một vài từ về việc lựa chọn Clojure trên JVM làm lựa chọn ngôn ngữ. Động lực chính cho việc này là:

  • Đồng thời - Clojure có một câu chuyện đồng thời độc đáo, hoạt động tốt khi xem video này mô tả một số khái niệm cốt lõi. Nó có thể mở rộng đáng tin cậy cho các kiến ​​trúc đa lõi ồ ạt bằng cách sử dụng Bộ nhớ giao dịch phần mềm . Và nó quản lý để làm điều này mà không cần nhiều chi phí (không khóa!), Đó là một kỳ công đáng chú ý của kỹ thuật.
  • Lập trình chức năng - Clojure là một ngôn ngữ chức năng nhấn mạnh tính bất biến và các hàm bậc cao hơn. Nó không hoàn toàn có chức năng như Haskell, nhưng trước hết nó là ngôn ngữ FP. Một số người nói điều này giúp bạn viết chương trình tốt hơn.
  • Năng suất lập trình viên - Clojure nhận được tất cả các lợi ích năng suất của triết lý mã-dữ liệu Lisp. Trong thực tế, điều này có nghĩa là các khả năng macro cực kỳ mạnh mẽ và cú pháp đơn giản nhưng cực kỳ linh hoạt mà bạn có thể sử dụng để xác định DSL của riêng mình cho bất kỳ vấn đề nào bạn đang giải quyết.
  • Cần một ngôn ngữ động phù hợp để phát triển và viết kịch bản nhanh chóng - Clojure có thể được sử dụng trong chu trình triển khai thử nghiệm xây dựng tiêu chuẩn nhưng thực sự tự nhiên hơn khi sử dụng REPL để phát triển tương tác, sửa đổi môi trường mã đang chạy khi bạn đi. Ví dụ, tôi sử dụng Incanter để có thể vẽ đồ thị và trực quan hóa dữ liệu khi tôi phát triển để xem kết quả của các đợt chạy.
  • Khả năng tương tác Java - Tương tác Java của Clojure rất hiệu quả. Các đối tượng Clojure là các đối tượng Java và ngược lại, vì vậy việc gọi các API và thư viện Java bất cứ khi nào bạn cần là chuyện nhỏ. Điều này cung cấp cho bạn tất cả các lợi ích của toàn bộ hệ sinh thái của các thư viện và công cụ Java.
  • Cộng đồng tốt - Cộng đồng của Clojure tuy nhỏ nhưng năng động, thân thiện và phát triển nhanh. Đã có rất nhiều dự án nguồn mở tuyệt vời, như Incanter (tính toán thống kê) hoặc Ring / Compojure (khung máy chủ web) hoặc Ngược chiều kim đồng hồ (plugin IDE Eclipse)

Mikera, đây chính xác là những gì tôi đã hỏi. Công ty của bạn đang để Java làm ngôn ngữ chính để phát triển ứng dụng và sử dụng Clojure thay thế. Tôi đồng ý với bạn, rằng JVM sẽ không biến mất, đặc biệt với một số công ty đầu tư vào các ngôn ngữ khác chạy trên JVM. Bạn có thể chia sẻ thêm một chút về những gì đằng sau quyết định sử dụng clojure làm ngôn ngữ phát triển chính?
Augusto

Chắc chắn, tôi đã thêm một số bình luận về lý do tại sao Clojure nói riêng (tôi cũng coi Scala cũng rất hứa hẹn, nhưng Clojure đã giành chiến thắng trong một biên độ hẹp vì Lisp-ness của nó)
mikera

Cảm ơn lời giải thích về lý do tại sao công ty của bạn quyết định sử dụng clojure!
Augusto

7

Tất cả phụ thuộc vào khách hàng.

Java sẽ luôn có một phân khúc nhỏ của riêng mình, nơi mọi người sẽ thu hút nó vì lý do này hay lý do khác, chỉ vì những lý do tương tự mà mọi người hấp dẫn .php hoặc .net, nhưng cuối cùng nó phụ thuộc vào yêu cầu và sở thích của khách hàng.

Nếu một khách hàng nói ... Tôi muốn ứng dụng này có trong java ... chúng ta sẽ nói không? có lẽ không ... nếu họ nói rằng chúng ta không thực sự quan tâm .... chúng ta sẽ viết nó bằng java chứ? có lẽ là không, nhưng đó chỉ là suy đoán.

Chúng tôi có các ứng dụng được viết bằng java có lịch sử lâu đời, nhưng có vẻ như khách hàng đang thay thế một cách tỉ mỉ MỌI THỨ bằng nhãn hiệu windows .... oracle to sql server ... unix / linux với server 2008 ... và php và java với .net.

Nếu điều đó xảy ra thì có ... trừ khi một khách hàng mới đến và nói rằng ... chúng tôi muốn điều này được viết bằng java ... chúng tôi sẽ sử dụng .net.


Một nhà bán lẻ xe hơi lớn của Mỹ đang làm một cái gì đó tương tự, nó bắt đầu xây dựng hầu hết các dự án sân xanh bằng ruby ​​thay vì ở Java.
Augusto

1

Đầu tiên là tiền đề, tôi không làm việc tại một công ty phần mềm.

Ok, chúng tôi sử dụng Oracle làm cơ sở dữ liệu chính với tất cả các thông tin quan trọng của chúng tôi được lưu trữ trên đó. Vì điều này, chúng tôi dự định tiếp tục sử dụng Java cho bất cứ điều gì để làm với Oracle. Việc mua lại Sun của Oracle là một động lực để chúng tôi tiếp tục sử dụng Java cho bất kỳ điều gì liên quan đến Oracle.

Nhưng, bất kỳ ứng dụng máy tính để bàn nào cũng được viết bằng C # vì mọi thứ đều dựa trên Windows.


0

Công ty của bạn có nghĩ đến việc chuyển đổi từ java sang công nghệ khác không?

Để trả lời câu hỏi của bạn. Không.

Như mọi nhà phát triển Java đều biết ...

Trong các công ty có quy mô đáng kể, nhìn chung không phải là nhà phát triển quyết định các vấn đề như liệu công ty có nên rời khỏi Java và hướng tới điều gì khác không. Và đối với những người thực hiện các quyết định này, các yếu tố khác ngoài những yếu tố bạn liệt kê là quan trọng.

... Tương lai của java có vẻ không rõ ràng, đặc biệt vì Oracle muốn kiếm tiền từ JVM.

Trái lại, tôi nghĩ rằng tương lai là rõ ràng. Sự phát triển của Java sẽ tiếp tục với tốc độ chậm nhưng ổn định và các công nghệ SE và EE cốt lõi sẽ tiếp tục miễn phí. Đối với tôi, khu vực thực sự không chắc chắn duy nhất là những gì sẽ xảy ra với trận đấu giữa Oracle và Google. Nhưng bằng cách này hay cách khác, tôi hy vọng rằng Android / Davlik sẽ phát triển thịnh vượng như một giải pháp thay thế cho Java ME ... nhưng chỉ dành cho các nền tảng di động.

Java là một ngôn ngữ cũng đã cũ trong vài năm qua, việc không bao gồm các bao đóng là một ví dụ (có thể được bao gồm trong java 1.8).

Điều này có thể gây khó chịu cho các nhà phát triển, nhưng "sự ổn định" thực sự là hậu quả của việc Sun / Oracle chú ý đến những gì doanh nghiệp muốn ... một ngôn ngữ / nền tảng với sự ổn định lâu dài.

Đồng thời, một số công nghệ mới như Ruby, Scala và Groovy đang được sử dụng để cung cấp các trang web phức tạp.

Một lần nữa, từ góc độ quản lý, bồi thẩm đoàn đưa ra liệu các công nghệ này có tốt hơn không.

  • Có phải năng suất được tuyên bố tăng thực sự có thể chứng minh được trong dài hạn?
  • Có hiệu suất ở đó chưa? Khả năng mở rộng? Công cụ và thư viện của bên thứ ba?
  • Họ có thể tuyển dụng nhân viên có kinh nghiệm?

Một quyết định cấp công ty để chuyển sang một ngôn ngữ mới có chi phí và rủi ro đáng kể, đặc biệt là nếu có một lượng đáng kể mã hiện có trong ngôn ngữ "di sản".


@Augusto - Tôi đã trả lời câu hỏi của bạn; xem câu đầu tiên. Bây giờ bạn có vui không
Stephen C
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.