Đây là thời điểm tuyệt vời để đăng bài này, ngay trên bản phát hành của Java 19. Vâng, một bài đăng khác "ngôn ngữ của tôi tốt hơn". Không, tôi không muốn viết nó. Nhưng đôi khi cái nhìn   của mọi người lại tốt hơn cho tôi. Trong trường hợp này, bài đăng bắt đầu dưới dạng nhận xét và cuối cùng tôi quyết định chuyển nó thành một bài đăng. Điều này được củng cố với   này chủ yếu phàn nàn về Quarkus (hơi bất công nếu tôi có thể thêm vào). xấu bài đăng  Bài viết đầu tiên chủ yếu là clickbait vô nghĩa và lỗi thời. Tôi sẽ tóm tắt nó cho bạn trong các tuyên bố sau:  Người nhận / Người định cư  Thiếu toán tử nạp chồng cụ thể cho   trên bộ sưu tập và   trên bất kỳ thứ gì [] +  Đã kiểm tra ngoại lệ  Quản lý sự phụ thuộc  Bài báo thứ hai có những phàn nàn liên quan nhiều hơn đến Jakarta EE và tính thẩm mỹ của lập trình viên nói chung trong JVM. Cụ thể là việc sử dụng các chú thích để xác thực và các tuyên bố tương tự. Đây là một bài báo đầy đủ thông tin hơn nhưng có một vài sai sót mà tôi sẽ giải quyết ở phần cuối.  Người nhận và người định cư  Getters và setters không cần thiết cho Java hiện đại. Chúng tôi có hồ sơ kể từ Java 14 và Lombok vẫn tốt mặc dù một số tuyên bố ngược lại. Điểm duy nhất mà chúng ta cần getter / setters là trong các cài đặt rất cụ thể (ví dụ như JPA), nơi một lần nữa, Lombok giải quyết vấn đề một cách hoàn hảo.  Bài viết xây dựng thành một bài báo về việc thiếu các tính năng cú pháp của đường trong Java. Đây là cố ý. Bạn có thể xem Kotlin nếu bạn quan tâm đến các sắc thái cú pháp mới nhất. Java là về "chậm và ổn định". Đó là một điều tốt và là lý do chính đằng sau tuổi thọ của Java.  Cú pháp Sugar và quá tải toán tử  Java hiện đại bao gồm các mẫu trong chuỗi switch, var, multiline và hơn thế nữa. Một số tính năng sắp tới bao gồm các mẫu chuỗi. Việc hỗ trợ mẫu chuỗi mất một khoảng thời gian vì Java muốn "làm đúng". Có một số hỗ trợ cho điều đó trong cấp API (và đã có một thời gian). Đây không phải là hiệu suất. Mục tiêu của các mẫu chuỗi là tạo ra một cú pháp có   những thứ như: thể ghi đè triệt để cho phép   ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}";    kể từ khi xuất bản bài đăng này, các nhà phát triển đã nhầm tưởng rằng đoạn mã trên là một lỗ hổng SQL injection. Nó không phải. Điều này trông giống như thay thế chuỗi nhưng đó là mã sử dụng cú pháp đó để tạo ra một lệnh gọi SQL được tham số hóa. Cập nhật:  Lưu ý rằng   là một biến mà trình biên dịch sẽ kiểm tra và lấy động từ phạm vi! name    có thể được nhà phát triển triển khai tùy chỉnh và không cần phải "tích hợp sẵn" để bạn có thể tạo các mẫu phức tạp ngay tại chỗ. DB  Nhưng hãy nói về Java mà chúng ta có ngày hôm nay, không phải là Java sẽ ra mắt sau 6 tháng nữa. Sử dụng append không phải là khuyến nghị cho   trong một thập kỷ trở lên. Sử dụng   cái nào hiệu quả nhất và dễ đọc hơn. Về bộ sưu tập, sự khác biệt giữa   và   theo nghĩa đen là bốn ký tự. Những nhân vật đó quan trọng rất nhiều. Chúng tôi có thể dễ dàng ghi đè điều này. Chúng ta cũng có thể hiểu sự khác biệt về ngữ nghĩa. Mảng Java RẤT nhanh, trong nhiều trường hợp, tốc độ gốc nhanh. Bộ sưu tập không thể nhanh như vậy, thực tế là chúng ta có thể thấy điều này ngay lập tức ở đây là rất có giá trị. String + get() []  Thực tế là các toán tử   thể bị quá tải là một lợi ích LỚN. Nếu tôi thấy   , tôi biết rằng đây là một chuỗi hoặc một số không phải là một số phương thức ẩn. Đó là một trong những điểm mạnh nhất của Java và một trong những lý do khiến nó trở nên phổ biến trong gần 30 năm trong khi các ngôn ngữ khác bị bỏ lại. Cú pháp của Java được thiết kế để đọc trên quy mô lớn. Khi bạn có một dự án với 1 triệu dòng mã hoặc thậm chí 100k, các vấn đề sẽ thay đổi. Tại thời điểm này, việc phát hiện ra rằng lập trình viên X trong mô-đun Y đã ghi đè một toán tử không chính xác khi bạn đang gỡ lỗi một vấn đề thật khó. Tại thời điểm đó, cú pháp phải đơn giản và bất kỳ khoản chi phí nhỏ nào bạn tiết kiệm được ban đầu sẽ được trả với lãi suất gấp 10 lần. Định nghĩa của các lần lật đơn giản khi mã trở nên phức tạp hơn và có tuổi đời. Thêm vào đó là sức mạnh của công cụ để phân tích mã đơn giản nghiêm ngặt ở quy mô lớn và điều này trở thành một lợi ích thậm chí còn lớn hơn. không a + b  Đã kiểm tra ngoại lệ  Các ngoại lệ được kiểm tra là tùy chọn. Nhưng chúng là một trong những tính năng TỐT NHẤT trong Java. Rất nhiều mã bị lỗi bất ngờ. Khi bạn xây dựng công cụ như một sở thích, điều đó có thể ổn. Khi bạn muốn xây dựng một ứng dụng chuyên nghiệp, bạn cần phải xử lý mọi lỗi. Các trường hợp ngoại lệ được kiểm tra giúp bạn tránh điều vô nghĩa đó. Mọi người ghét những trường hợp ngoại lệ đã được kiểm tra vì sự lười biếng. Java bảo vệ bạn chống lại chính bạn.  Sẽ không có trường hợp tôi thực hiện kết nối mạng, kết nối DB, mở tệp, v.v. và không cần xử lý lỗi tiềm ẩn. Tôi có thể punt nó nhưng sau đó các ngoại lệ đã được kiểm tra buộc tôi phải tiếp tục punting nó ở đâu đó. Đó là một tính năng tuyệt vời.  Sự phụ thuộc  Tôi có rất nhiều vấn đề với Maven và Gradle. Nhưng khi bạn so sánh nó với bất kỳ hệ thống phụ thuộc nào khác với một số phần trăm trên đó thì chúng đang hoạt động rất tốt. Chúng có vấn đề nhưng bạn không thể so sánh chúng với một thứ gì đó non trẻ như hàng hóa hầu như không có gói hàng để so sánh. Trung tâm Maven là   với 27 terabyte lọ và 496 tỷ yêu cầu. Nó hoạt động hoàn hảo và hầu như không có thời gian chết. MASSIVE  Các công cụ khác như NPM thể hiện điểm mạnh của maven một cách hoàn hảo. Nếu sự phụ thuộc trong maven là một vấn đề thì NPM có vấn đề gấp 100 lần và không có sự giám sát. Khi những thứ này phát triển sẽ có những phức tạp. Đặc biệt là với nhiều phiên bản maven trên thị trường. Tuy nhiên, một trong những thứ mà maven và gradle phải làm cho họ là công cụ. Trong nhiều trường hợp, IDE giúp giải quyết các vấn đề và tìm ra bản sửa lỗi ngay lập tức.  Các vấn đề văn hóa trong Java  Bài báo thứ hai là một bài báo thú vị hơn và tôi đồng ý ở một mức độ nào đó. Các nhà phát triển Java có xu hướng biến mọi vấn đề thành một vấn đề phức tạp hơn. Trong một số trường hợp, điều này là cần thiết, Java là con khỉ đột nặng 800 pound của các nền tảng lập trình và các giải pháp của nó thường được thiết kế quá mức. Điều này có xu hướng tốt hơn so với nguồn cung cấp thấp hơn, nhưng nó có một cái giá.  Tại sao chú thích để xác thực  Bài báo đã đưa ra một ví dụ thú vị có vẻ như là "điều đúng đắn" đối với người quan sát bình thường nhưng lại có vấn đề.   @NotNull @Email String noReplyEmailAddress  Tác giả tuyên bố rằng điều này là xấu và người ta nên triển khai nhập tùy chỉnh, ví dụ:   public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); } }  Điều này hoàn toàn có thể xảy ra trong Java vì đoạn mã trên là mã Java hợp lệ. Nhưng nó có một số vấn đề, đó là lý do tại sao chúng ta có xác nhận bean.  Điều này không thể được tối ưu hóa - Xác thực Bean có thể được chuyển lên chuỗi xác thực bằng khung. Nó thậm chí có thể được xác thực trong mã phía máy khách một cách liền mạch vì nó là một API khai báo. Ở đây chúng ta cần thực thi phương thức khởi tạo để thực hiện xác nhận.  Các chú thích khai báo có thể được di chuyển xuống chuỗi để áp dụng các ràng buộc cơ sở dữ liệu một cách liền mạch, v.v.  Chúng tôi có thể áp dụng nhiều chú thích cùng một lúc  Cú pháp ngắn gọn hơn  Do đó, các chú thích có thể cảm thấy kỳ lạ và không bắt buộc nhập. Đúng. Nhưng chúng làm tăng hiệu suất và sức mạnh. Có rất nhiều suy nghĩ và nhận thức chung đằng sau việc sử dụng chúng. Tôi hiểu ý của các tác giả, tôi cũng không phải là một fan cuồng nhiệt của IoC, nhưng trong trường hợp cụ thể này thì anh ấy không chính xác.  Cuối cùng  Bài viết này đã dành quá nhiều thời gian cho việc phòng thủ. Đã đến lúc chuyển bánh răng. Java đã tồn tại gần 30 năm và hầu như vẫn tương thích với Java 1.0. Điều đó thật tuyệt vời và không gì sánh được!  Một trong những sức mạnh của cách tiếp cận bảo thủ của nó là nó có thể thực hiện những tối ưu hóa "bí mật" đáng kinh ngạc mà không ai trong số các bạn nhận ra điều gì đã xảy ra. Java 9 đã   một cách liền mạch và cắt giảm đáng kể việc sử dụng RAM. Tương tự như vậy, Loom sẽ thúc đẩy thông lượng của các ứng dụng đồng bộ Java. Valhalla sẽ cải thiện hơn nữa hiệu suất thu thập và thống nhất phân chia Đối tượng / Nguyên thủy. Panama cuối cùng sẽ loại bỏ JNI và làm cho quá trình tích hợp với mã gốc trở nên dễ chịu hơn rất nhiều. thay thế hoàn toàn cách các chuỗi được biểu diễn trong bộ nhớ  Điều tốt đẹp là JVM là một cái lều lớn. Nếu bạn không phải là fan của Java, Kotlin hoặc Scala có thể phù hợp với sở thích của bạn. Lợi ích của JVM được áp dụng trên toàn cầu và hầu hết các tính năng mà tôi đề cập ở đây sẽ mang lại lợi ích cho toàn bộ hệ sinh thái chung của chúng ta.  Câu chuyện này lần đầu tiên  được xuất bản ở đây.

Chain

Instantly

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Tại sao Java vẫn phổ biến

Tại sao Java vẫn phổ biến

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

94 Stories To Learn About John Locke

287 Stories To Learn About Blockchain Development

145 Stories To Learn About Book

309 Stories To Learn About Smart Contracts

94 Stories To Learn About John Locke

287 Stories To Learn About Blockchain Development

145 Stories To Learn About Book

309 Stories To Learn About Smart Contracts

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps