首选System.lineSeparator（）以用Java编写系统相关的行分隔符字符串

JDK 7在java.lang.System类上引入了一个名为lineSeparator（）的新方法。该方法不期待任何参数，并返回一个String ，它表示“取决于系统的行分隔符字符串。” 此方法的Javadoc文档还指出System.lineSeparator() “始终返回相同的值– 系统属性 line.separator的初始值。” 进一步说明：“在UNIX系统上，它返回“ \n ”；在Microsoft Windows系统上，它返回“ \r\n ”。

既然Java开发人员长期以来一直能够使用System.getProperty（“ line.separator”）来获取该与系统相关的行分隔符值，那么为什么那个Java开发人员现在更喜欢使用System.lineSeparator ？ JDK-8198645 [“使用System.lineSeparator（）代替getProperty（“ line.separator”）”]提供了一些在其“描述”中偏爱System.lineSeparator()而不是System.getProperty（String）方法的原因：

基本模块中的许多类都使用System.getProperty（“ line.separator”），并且可以使用效率更高的System.lineSeparator（）简化代码并提高性能。

正如JDK-8198645中的“描述”所述，与System.getProperty("line.separator")相比，使用System.lineSeparator()更简单，更高效。 core-libs-dev邮件列表上的最近一条消息提供了更多详细信息，Roger Riggs在该消息中写道System.lineSeparator() “使用System中的行分隔符，而不是每次都在属性中查找它。”

在许多情况下，与使用System.getProperty("line.separator") ，使用System.lineSeparator()的性能优势可能并不那么重要。但是，鉴于其简单性，在编写更简单的代码时没有理由不获得性能上的好处（即使在许多情况下很小且很难测量）。 System.getProperty(String)方法的缺点之一是必须确保将完全匹配的属性名称提供给该方法。使用基于String的API时，总是存在将字符串拼写错误的风险（我见过“ sep a rator”多次拼写为“ sep e rator”），使用了错误的大小写，或者不小心引入了其他拼写错误，从而阻止了精确匹配被制造。

在JDK 7中引入了此功能的JDK问题JDK-6900043 （“添加方法返回line.separator属性”），在其“说明”中也阐明了一些好处：“查询line.separator值在以下情况中很常见。大型系统。正确执行此操作很冗长，并且可能会导致安全性失败；让方法返回该值将是有益的。” 重复的JDK-6264243 （“ File.lineSeparator（）以检索常用的'line.separator'系统属性的值”）详细说明了此方法的优点，并列出了“正确性”，“性能”和“易用性”。使用和跨平台开发”作为高级优势。另一个重复的问题， JDK-6529790 （“请将LINE_SEPARATOR常数添加到System或其他类中”）指出，应该以某种方式向“某些标准Java类（如String或System）中添加” constant”。与File.pathSeparator为文件分隔符提供的内容相似。

与JDK 7 System.lineSeparator()引入相关的消息之一用以下描述证明了其补充：

许多类都需要使用System.getProperty("line.separator") 。 许多做法不正确，因为每当读取系统属性时都需要使用doPrivileged块。 但这不是秘密-即使您对安全管理器不信任，也可以区分行分隔符。

与在JDK 7中添加System.lineSeparator()有关的一个有趣的旁注是，当时的Javadoc并未表明该方法是JDK 7的新功能。JDK-7082231 （“在System.lineSeparator上输入@since 1.7） ”）在JDK 8中解决了此问题，另外两个JDK问题（ JDK-8011796和JDK-7094275 ）表明，这是多个Java开发人员所希望的。

System.lineSeparator()的引入是一个很小的增强，但是它确实提高了相对常用的API的安全性和可读性，同时并没有降低（实际上是在提高）性能。