我遇到了这个类java.io.FileSystem
,并注意到它有很多我目前在我的项目中需要的方法。但是该类是包私有的,因此我正在使用反射访问所需的方法。
问题:
- 这个类被标记为包私有有什么特别的原因吗?
- 通过反射访问它有什么危险吗?(也就是说,除了性能受到影响。)
我遇到了这个类java.io.FileSystem
,并注意到它有很多我目前在我的项目中需要的方法。但是该类是包私有的,因此我正在使用反射访问所需的方法。
问题:
这个类是包私有的,因为 SUN(以及扩展,Oracle)相信这个依赖于平台的类的方法将来可能会发生重大变化,因此不能直接访问。这个抽象类的所有实现都在本机代码中;Java 程序员不应该能够创建自己的。
通过反射使用隐藏类的最大危险不是性能,而是它的方法甚至整个类在JDK的下一次升级中消失的非常现实的可能性,无论多么小。非公开 API 是非公开的;即使在维护版本中更改它们也是公平的游戏,因此如果您的程序在看似例行的 JDK 更新后停止工作,您只能责怪自己。
这个类被标记为包私有有什么特别的原因吗?
总的来说,将 Java SE 类声明为包私有的目的是告诉您它不是您应该使用的 API。
一般来说,原因如下:
隐藏使 API 不适合一般使用的限制/限制。例如:
在这种情况下,我怀疑设计师认为这两个原因都适用。但请注意,辩论他们(假设的)原始想法的“正确性”是没有实际意义的。(题外话:StackOverflow 不是讨论网站。)
现在,Java 团队对文件系统访问和可移植性的思考随着时间的推移而发展。在 Java 7 中,他们引入了一些新的 API(例如java.nio.file.Path
和),它们比旧APIjava.nio.file.FileSystem
更好地处理文件系统特定行为的问题。java.io.File
但是,这并不意味着他们可以或应该追溯更改或删除旧 API。如果他们这样做,它将破坏“数百万”现有的 Java 应用程序。
通过反射访问它有什么危险吗?
如果您反思地使用这些方法,我上面列出的原因也将适用。
Is there any particular reason why this class is marked package private?
Yes. java.io.FileSystem
is not part of the Java API. There is no guarantee how and if it will work. It might be removed or changed in next versions. In fact it's most likely missing in every Java implementation other than Oracle's.
java.io.File
uses this class internally, so it should expose most of its functionality in one way or another.
Are there any dangers of accessing it via reflection? (Other than performance hit, that is.)
You are avoiding SecurityManager
so it won't work with that.