Một khía cạnh khác:
Java là một ngôn ngữ tĩnh với các tính năng khá nghiêm ngặt. Điều này có nghĩa là nhiều điều sẽ khá cởi mở hoặc năng động trong các ngôn ngữ khác (c / f Ruby, Lisp, v.v.) được xác định nghiêm ngặt.
Đây là một quyết định thiết kế chung. "Tại sao" rất khó trả lời (tốt, bởi vì các nhà thiết kế ngôn ngữ nghĩ rằng nó sẽ tốt!). "What for" khá rõ ràng: nó cho phép trình biên dịch phát hiện rất nhiều lỗi, nói chung là một tính năng khá tốt cho bất kỳ ngôn ngữ nào. Thứ hai, nó làm cho nó tương đối dễ dàng để lý luận về ngôn ngữ. Ví dụ, tương đối dễ dàng để tạo ra tính chính xác chứng minh trong (tập hợp con) ngôn ngữ Java; để so sánh, điều đó hầu như không thể trong một ngôn ngữ động như Ruby et al.
Suy nghĩ này thấm vào ngôn ngữ, ví dụ, tuyên bố có hiệu lực của các ngoại lệ có thể xảy ra mà một phương thức có thể đưa ra, loại interfaceso với riêng biệt classđể tránh nhiều kế thừa mơ hồ, v.v. Đối với những gì nó là (một ngôn ngữ trong thế giới thực OOP bắt buộc tĩnh tập trung mạnh vào xử lý lỗi thời gian biên dịch) những điều đó thực sự khá thanh lịch và mạnh mẽ. Họ đến gần hơn với các ngôn ngữ lý thuyết (khoa học) được tạo ra nhằm mục đích khám phá một số vấn đề này hơn bất kỳ ngôn ngữ trong thế giới thực nào khác trước đây (tại thời điểm đó, làm phiền bạn).
Vì thế. Có một voidloại nghiêm ngặt là một thông điệp rõ ràng: phương pháp này không trả lại bất cứ điều gì, thời gian. Đó là những gì nó được. Việc thay thế nó bằng việc thực thi để luôn trả lại một cái gì đó sẽ dẫn đến hành vi năng động hơn nhiều (như trong Ruby khi mọi def đều có giá trị trả về rõ ràng hoặc ẩn), điều này sẽ không tốt cho khả năng chứng minh và lý luận; hoặc phình to bằng cách sử dụng một số cơ chế khác ở đây.
(Và NB, Ruby (ví dụ) xử lý việc này khác nhau và giải pháp của nó vẫn hoàn toàn có thể chấp nhận được như Java, bởi vì nó có một triết lý hoàn toàn khác. Ví dụ, nó ném hoàn toàn khả năng chứng minh và tính hợp lý ra khỏi cửa sổ trong khi tập trung lớn vào tính biểu cảm cực cao của ngôn ngữ.)