如果您可以大幅改变 Java 的类路径库，您会做出哪些不同的决定？
如果您有机会显着更改/更新 Java 的类路径库，您会添加/更新/更改/弃用/删除哪些内容？
If you had the chance to significantly change/update Java's classpath libraries, which things would you add/update/change/deprecate/remove?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将当前远非单一类库的所有各个方面重组为相互依赖性较低的单独模块。这需要将接口分离并提供默认实现到独特的类层次结构中（类似于 SAX API 已经存在的内容）。基本原理：允许使用精简的类库进行部署，并另外启用某些核心方面（加密、网络协议、i18n 等）的第三方替换和扩展。
将所有集合类和一些 java.lang 类重新设计为更小的构建块，这些构建块可以组装成更灵活、更强大的数据结构（沿着 Google Collections 类的理念）。这将提供更多与上下文无关的行为接口，例如 CharSequence 或 Comparable。
提供更多特定于平台的（扩展）API 和实现，涵盖尽可能合理的受支持平台（并与它们一起成长），并接受使用这些类的代码在没有开发人员额外努力的情况下将无法移植。这是为了允许创建能够在可用性、有用性和总体感知质量方面与本机软件竞争的重要软件。例如，这些 API 允许访问块设备、vt100 终端、Windows 注册表等。
以多层方式重新设计 Swing（即图形基元 API 之上的基本构建块之上的控件）并使其更加丰富多态性。即具有单个方法
perform的单个 Action 接口，而不是许多特殊的 Listener 接口。另外，我会提供一个封装本机 GUI 组件的包装框架（本着我之前提案的精神）。尝试找到一种更好的方法来处理沙箱环境中与安全相关的访问限制，并且不会限制许多重要基础类的整体灵活性。目前，最初用于设计目的的语言功能被严重滥用于安全目的，这导致了相当静态和非多态的类和 API，因为如果它们更加开放，它们可能会在沙箱内被利用（并且该方法仍然不够安全）尝试
提供一个不太幼稚的序列化系统，它支持弱引用、具有错误检测并支持类演化。
提供
Restructure all the various aspects of the currently far to monolithic class library into seperate modules with lower interdependencies. This would require to seperate interfaces and provided default implementations into distinctive class hierachies (similar to what exists for the SAX API already). Rationale: allow deployments with stripped down class libraries and additionally enable third party replacementes and extensions of certain central aspects (crypto, network protocols, i18n, ...).
Redesign all collection classes and some of the java.lang classes into much smaller building blocks that can be assembled into more flexible and more powerfull data structures (along the philosophy of the Google Collections classes). This would offer far more context independant behavioural interfaces, like i.e. CharSequence or Comparable.
Provide more platform specific (Extension-)APIs and implementations that cover as much as is reasonable of the supported platforms (and grow with them) and accept that code that is using these classes will not be portable without extra effort from the developer. This is meant to allow the creation of non trivial software that is able to compete with native software in terms of usability, usefullness and general perceived quality. These APIs would for example allow access to block devices, vt100 terminals, the Windows registry etc.
Redesign Swing in a multilayered way (i.e. controls on top of basic building blocks on top of a graphics primitives API) and make it far more polymorphic. I.e a single Action interface with a single method
performinstead of lots of special Listener interfaces. Additionally I'd offer a wrapper framework that encapsulates native GUI components (in the spirit of my previous proposal).Try to find a better way to handle security related access restrictions for sandbox environments that doesn't limit the overall flexibilty of many imporatant fundamental classes. Currently language features originaly intended for design purposes are heavily abused for security purposes which has led to rather static and nonpolymorphic classes and APIs because they could be expoited from within a sandbox if they were more open (and the approach still failed to be secure enough many many times).
Provide a less naive serialization system that supports weak references, has error detection and supports class evolution.
我将 CheckedException 添加到与 RuntimeException 相同的级别（使人们“不得不”捕获异常的频率降低）
我将删除所有已弃用的 API。
我会删除旧的集合类，例如 Vector 和 Dictionary。
我会在 IOException 下创建大量异常类。
我会替换尽可能多的 public static final int X;常量，就像我可以用枚举一样。
I'd add CheckedException at the same level as RuntimeException (make it less often that people "have" to catch Exception)
I'd remove all the deprecated APIs.
I'd remove the old collection classes, like Vector and Dictionary.
I'd make a boat load of exception classes under IOException.
I'd replace as many public static final int X; constants as I could with enums.
我将摆脱 Object.hashCode 并定义 Hashable / Hasher 接口。 （但我会保留 System.identityHashCode(Object)，因为尽管它有开销，但它做了一些非常有用的事情，这是任何其他方式都无法做到的。）
我会摆脱 Object.equals 并定义一个 Equatable / Equater 接口。 （但如果我能管理的话，可以使用更好的名称。）
我会摆脱 Object.clone。我可能会保留它作为数组类的方法。
我会摆脱 Object.finalize 并将其替换为天真的 C/C++ 程序员不会注意到的东西，直到他们有足够的经验知道终结几乎总是错误的解决方案。
我会摆脱 System.gc();
我会将笨重的全局 System.in/out/err 内容替换为使用 Readers/PrintWriters 的内容，并且可以轻松地通过线程或线程组“确定范围”。
我将删除对任何对象进行原始锁定的能力（...好吧，不是严格意义上的库更改）。
我会尝试找出如何实现 thread.stop/suspend/resume 的安全版本...即使这意味着在 J2SE JVM 中实现 Isolates。
I'd get rid of Object.hashCode and define a Hashable / Hasher interfaces instead. (But I'd retain System.identityHashCode(Object) because despite its overheads it does something very useful that is impossible to do any other way.)
I'd get rid of Object.equals and define an Equatable / Equater interfaces instead. (But with better names if I could manage it.)
I'd get rid of Object.clone. I might retain it as a method on the array classes.
I'd get rid of Object.finalize and replace it with something that naive C/C++ programmers won't notice until they are experienced enough to know that finalization is almost always the wrong solution.
I'd get rid of System.gc();
I'd replace the clunky global System.in/out/err stuff with something that used Readers/PrintWriters and that was / could easily be "scoped" by thread or threadgroup.
I'd remove the ability to take a primitive lock on any Object (... OK not strictly library change).
I'd try figure out how to implement safe versions of thread.stop/suspend/resume ... even if this meant implementing Isolates in J2SE JVMs.