Đối với các ứng dụng mới được viết bằng Java 7, có lý do nào để sử dụng một java.io.Fileđối tượng nữa không hoặc chúng ta có thể xem xét nó không dùng nữa không?
Tôi tin rằng a java.nio.file.Pathcó thể làm mọi thứ a java.io.Filecó thể làm và hơn thế nữa.
Câu trả lời:
Mẩu chuyện dài:
java.io.Filerất có thể sẽ không bao giờ bị phản đối / không được hỗ trợ. Điều đó nói rằng, java.nio.file.Pathlà một phần của java.nio.filelib hiện đại hơn , và làm mọi thứ java.io.Filecó thể, nhưng nói chung là theo cách tốt hơn, và nhiều hơn nữa.
Đối với các dự án mới, sử dụng Path.
Và nếu bạn cần một Fileđối tượng để kế thừa, chỉ cần gọi Đường dẫn # toFile ()
Di chuyển từ tệp sang đường dẫn
Filethay vì Path?
Pathcó thể dễ dàng sửa đổi hơn để "thêm trẻ em" với resolve(...)hoặc "di chuyển lên một cấp" với getParent(), v.v. trong khi Filekhông thể. Về cơ bản một khi bạn đã hoàn thành sửa đổi Đường dẫn, bạn sẽ thường chuyển đổi nó toFile()để có thể gửi nó thành các phương thức cũ, chẳng hạn như hàm FileInputStreamtạo.
chúng ta có thể xem xét nó không dùng nữa?
Không, bạn không thể xem xét nó không được chấp nhận trừ khi và cho đến khi nó được đánh dấu trong FileJavadoc.
java.io.Filevẫn không bị loại bỏ hay thậm chí không được phản đối, và vẫn không có gì trong Javadoc cho rằng một trong những điều này sẽ xảy ra.
Kiểm tra bài viết này về thông tin thêm - http://www.oracle.com/technetwork/articles/javase/nio-139333.html
Về cơ bản file.Path sẽ là cách để đi từ bây giờ nhưng như Java được biết đến rộng rãi, mọi người có xu hướng giữ tính tương thích trở lại vì vậy tôi đoán đó là lý do tại sao họ đã rời bỏ nó.
Tôi sẽ hoàn thành câu trả lời rất tốt của @mmcrae.
Có bất kỳ lý do để sử dụng một đối tượng java.io.File nữa hay chúng ta có thể xem xét nó không dùng nữa?
Các lớp JDK rất hiếm khi bị phản đối.
Bạn có thể thấy trên API JDK 8 không dùng nữa liệt kê tất cả các lớp không dùng nữa kể từ JDK đầu tiên.
Nó chỉ chứa một phần nhỏ các lớp mà tài liệu Oracle và cộng đồng Java không khuyến khích sử dụng.
java.util.Date, java.util.Vector, java.util.Hashtable... đó là lớp học với rất nhiều khiếm khuyết không phản đối.
Nhưng tại sao ?
Bởi vì về mặt khái niệm một cái gì đó deprecatedcó nghĩa là vẫn còn nhưng không khuyến khích sử dụng vì nó chắc chắn sẽ bị loại bỏ.
Hàng ngàn chương trình dựa vào các lớp được thiết kế xấu này.
Đối với các lớp như vậy, các nhà phát triển API Java sẽ không đưa ra tín hiệu như vậy.
Câu trả lời @EJPlà rất đúng:
Không trừ khi và cho đến khi nó được đánh dấu như vậy trong Javadoc.
Vì vậy, tôi nghĩ rằng câu hỏi của bạn sẽ có ý nghĩa hơn trong các điều khoản của nó:
"Khi chúng ta có sự lựa chọn, chúng ta nên sử dụng java.io.Filehoặc java.nio.file.Pathcho các phát triển mới và nếu câu trả lời là java.nio.file.Path, bạn có thể dễ dàng tận dụng java.io.Filecác dự án cũ java.io.Filekhông?"
Tôi tin rằng một java.nio.file.Path có thể làm mọi thứ mà java.io.File có thể làm và hơn thế nữa.
Bạn có câu trả lời.
Hướng dẫn tiên tri này về di sản IO xác nhận suy nghĩ của bạn.
Trước khi phát hành Java SE 7,
java.io.Filelớp là cơ chế được sử dụng cho tệp I / O, nhưng nó có một số nhược điểm.Nhiều phương pháp đã không đưa ra ngoại lệ khi chúng thất bại, vì vậy không thể có được thông báo lỗi hữu ích. Ví dụ: nếu xóa tệp không thành công, chương trình sẽ nhận được "xóa thất bại" nhưng sẽ không biết có phải do tệp không tồn tại hay không, người dùng không có quyền hoặc có một số vấn đề khác.
Phương thức đổi tên không hoạt động nhất quán trên các nền tảng. Không có hỗ trợ thực sự cho các liên kết tượng trưng.
Cần hỗ trợ thêm cho siêu dữ liệu, như quyền tệp, chủ sở hữu tệp và các thuộc tính bảo mật khác.
Truy cập siêu dữ liệu tập tin là không hiệu quả.
Nhiều phương thức File không mở rộng được. Yêu cầu một danh sách thư mục lớn trên một máy chủ có thể dẫn đến treo. Các thư mục lớn cũng có thể gây ra sự cố tài nguyên bộ nhớ, dẫn đến việc từ chối dịch vụ.
Không thể viết mã đáng tin cậy có thể đệ quy một cây tập tin và trả lời thích hợp nếu có các liên kết tượng trưng tròn.
Với rất nhiều nhược điểm java.io.File, chúng tôi thực sự không cần lý do để sử dụng lớp này cho các phát triển mới.
Và ngay cả đối với mã kế thừa sử dụng java.io.File, Oracle đưa ra gợi ý để sử dụng Path.
Có lẽ bạn có mã kế thừa sử dụng java.io.File và muốn tận dụng chức năng java.nio.file.Path với tác động tối thiểu đến mã của bạn.
Lớp java.io.File cung cấp phương thức toPath, nó chuyển đổi một thể hiện tệp kiểu cũ thành một thể hiện java.nio.file.Path, như sau:
Path input = file.toPath();Sau đó, bạn có thể tận dụng bộ tính năng phong phú có sẵn cho lớp Đường dẫn.
Ví dụ: giả sử bạn có một số mã đã xóa một tệp:
file.delete();Bạn có thể sửa đổi mã này để sử dụng phương thức Files.delete, như sau:
Path fp = file.toPath();
Files.delete(fp);Có, nhưng nhiều API hiện có, bao gồm các API tiêu chuẩn của riêng Java7, vẫn chỉ hoạt động với Fileloại.
Java.io.File không được dùng nữa. Có java.nio.file.Path tốt hơn, nhưng miễn là vẫn còn nhiều chương trình và sách văn bản sử dụng Java.io.File, nếu chỉ vì lý do di sản, nó không nên bị coi là phản đối, nó quá quan trọng. Làm như vậy sẽ chỉ là ném một cờ lê trong công việc mà không vượt quá tất cả. Ví dụ, khung Android sử dụng Tệp cho một số tính năng xử lý tệp cơ bản của nó, nhiều việc khác phải làm.
Pathtốt hơn không. Anh hỏi có Filebị phản đối không.
Đối với các ứng dụng mới được viết bằng Java 7, có lý do nào để sử dụng đối tượng java.io.File nữa hay chúng ta có thể xem xét nó không dùng nữa không?
Điều này hơi giống như nói: "Napoleon nên xâm chiếm Nga, hay những mầm Brussels này thực sự ngon?"
Đối với phần thứ hai của câu hỏi, bạn thực sự có thể xem xét nó không được chấp nhận. Kể từ tháng 1 năm 2018, nó không bị phản đối. Nhưng không có gì ngăn cản bạn xem xét nó như vậy. Cho dù điều đó sẽ mua cho bạn bất kỳ lợi thế trong cuộc sống này hoặc tiếp theo là không thể nói.
File. Tôi nên, có hay không?"
File. Nó sẽ không chết bất cứ lúc nào sớm.
it isn't deprecated. But there's nothing to stop you *considering* it soCƯỜI LỚN.