我很想知道其他 Java 程序员觉得他们最喜欢这门语言的什么部分,为什么他们会有这种感觉,以及为什么其他程序员也应该对它有深入的了解。我正在寻找简单、性能等原因。谢谢。
15 回答
我最喜欢的 Java API 是Collections Framework。我发现自己一直在使用它,而不是滚动自己的实现,而且它非常有趣且易于使用。它由高性能数据结构和算法的几个有用且可互换的实现以及用于围绕它们包装附加功能的几种便捷方法组成。
可以在此处找到 Josh Bloch 的教程:http: //java.sun.com/docs/books/tutorial/collections/index.html
我最喜欢的 API 部分绝对是java.lang。它有一个名为 的类String
,它允许您轻松地操作字符数组。任何认真编写好的 Java 代码的程序员都应该检查一下。
java.util.concurrent对我的生活至关重要。我们做了很多多核编程,尝试使用旧式原始线程来实现我们所有任务的想法让我感到恶心。
并发包真正让我们的生活更轻松的一个很好的例子是它提供的专用数据结构池。我个人最喜欢的是CopyOnWriteArrayList。在显示任务正在从数据缓存中读取数据以更新屏幕而另一个任务正在从网络获取信息以更新缓存的情况下,我们使用了很多。通常,这将是碰撞、ConcurrentModificationExceptions和类似恐怖的邀请。使用 CopyOnWriteArrayList,写入任务将在需要添加数据时创建数据的新副本,从而确保读取器始终拥有有效(尽管可能已过时)数据集来显示。
正如javadoc所说,
这通常成本太高,但当遍历操作的数量大大超过突变时,它可能比替代方法更有效,并且在您不能或不想同步遍历但需要排除并发线程之间的干扰时很有用。
Java 消除了我通常会引入来解决这个问题的整个类的错误,使我能够专注于我需要解决的实际问题。
绝对是集合框架。无论您是在做服务器端 Java 还是客户端,无论是否图形化,它都会一直使用。它很容易使用。大多数数据结构类都有非泛型和泛型版本(最好使用第二个,但有大量使用第一个的遗留代码),但除了类参数之外,它们在 API 方面几乎相同。在 .NET 中,这两个版本可以有不同的名称/API,并且会变得非常混乱。我也喜欢 Java 集合框架如何将算法作为静态方法(例如 Collections.sort(collectionVar))而不是作为实例方法。在 .NET 中,他们使用实例方法,并且由于某种原因,并非每个数据结构都有排序...集合框架也非常丰富,您可以找到简单和专门的数据结构(例如
我听说的一个缺点是该框架表现不佳,有些人自己编写。我无法验证它,因为我不处理对性能至关重要的东西。
javax.命名
http://java.sun.com/javase/6/docs/api/javax/naming/package-summary.html
Java 是一种出色的系统集成技术,因为它具有可移植性,而 JNDI 在抽象出首次接触远程系统的复杂性方面做得很好。
反射。其中一些在java.lang.reflect中,一些在java.lang中(主要是 Class 和 ClassLoader)。
流。Java 中的流比 C++ 中的流更容易掌握和实现(观点),并且根据 API 附带的流的名称,通常很容易看出流将为您做什么。
我是Java EE 中 JPA 的忠实粉丝。它减少了我需要为大型应用程序(将使用 EJB)和小型应用程序做的工作量。
紧随其后的是安全 API JAAS,这里是 Java SE JAAS 的链接:http: //java.sun.com/javase/technologies/security/
到目前为止,java.util.regex API 包是我最喜欢的,因为它使我不必为了各种目的搜索和利用字符串片段而在很多场合重新发明轮子。
java.util 非常实用。为什么?
- 收藏品。其中很多!
- 日期和时间类
- 文本扫描仪
- 依赖注入实用程序(Java 6 起)
- 定时器线程
- 随机数
- 观察者模式就在那里
- Java 属性
java.util.jar - 帮助将 .jar 文件加载到我的应用程序插件的类加载器中!我喜欢它。
java.util.regex
还有其他一些我不能没有的包,但是 regex 包必须位于“java 的最大补充”的顶层——绝对就在 Collections 那里。
我同意反思评论。迄今为止,Java API 中最有用/最强大的部分
回想我的 Java 时代,最有趣的 API 是java.util.concurrent,因为它为并行处理提供了经过深思熟虑且易于使用的构建块。
InheritableThreadLocal
一路!!!这么多编写混淆代码的机会和绞死自己的绳索似乎永远不会用完。