lineseparator
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)中”与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的安全性和可读性,同时并没有降低(实际上是在提高)性能。
lineseparator