"Chào, Amigo! Tôi có một chủ đề nhỏ và thú vị khác dành cho bạn. Loại Hư Không."

"Và tại sao bạn lại cần một kiểu như vậy? Ý tôi là, tôi hiểu void: đó là đưa các hàm và thủ tục vào sự liên kết. Chúng tôi không có thủ tục, nhưng chúng tôi có các hàm trả về void (không có gì)."

"Đúng, nhưng bạn có nhớ rằng Ellie gần đây đã nói với bạn về giao diện Callable không?"

"Đúng."

"Và bạn có nhớ những gì bạn cần chuyển dưới dạng đối số kiểu không?"

Java university

"Có, loại giá trị trả về:"

Ví dụ về một tác vụ không làm gì cả: 
class EmptyJob implements Callable
{
 public String call() throws Exception
 {
  return null;
 }
}

"Đúng. Và nếu bạn muốn phương thức gọi trả về một int thì sao? Sau đó thì sao?"

"Bây giờ tôi biết rằng có hộp thư tự động cho việc này. Tôi chỉ cần chuyển một Số nguyên và mọi thứ sẽ diễn ra như kim đồng hồ:"

Ví dụ về một tác vụ không làm gì cả: 
class EmptyJob implements Callable
{
 public Integer call() throws Exception
 {
  return null;
 }
}

"Tuyệt vời. Và nếu phương thức không trả về gì thì sao?"

"Tôi hiểu ý của bạn. Vậy thì chúng ta sử dụng Void làm đối trọng của void?"

"Chuẩn rồi."

"Sẽ không dễ dàng hơn nếu chỉ biến giá trị trả về thành Đối tượng và sau đó trả về giá trị rỗng?"

"Đôi khi, nhưng không phải luôn luôn."

"Bạn biết rằng bạn thực sự muốn trả về khoảng trống ở đây khi bạn viết Object, nhưng một lập trình viên khác có thể không biết điều này và sẽ nghĩ tại sao bạn lại trả về null."

"Hoặc mã gọi phương thức sẽ mong đợi giá trị trả về."

"Nhưng khi bạn viết Void, mọi người hiểu ngay đây là một lớp bao bọc cho void, mặc dù bạn vẫn phải trả về null."

Ví dụ về một tác vụ không làm gì cả: 
class EmptyJob implements Callable
{
 public Void call() throws Exception
 {
  return null;
 }
}

"Hmm. Bạn nói đúng. Một phương thức luôn trả về null sẽ đặt ra câu hỏi. Nhưng phương thức được khai báo là Void có thể làm điều này mà không cần giải thích thêm."

"Khả năng đọc mã được đặt lên hàng đầu. Tôi thích Java!"

"Tuyệt. Tôi rất vui vì bạn thích nó. Hôm nay chúng ta xong việc rồi."