TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Raw String Literals Removed From Java 12 as Feature Set Frozen

87 点作者 javinpaul超过 6 年前

9 条评论

moefh超过 6 年前
Java Unicode escapes are kind of a mess, and the raw string literals proposal only makes it worse.<p>Unicode escapes are processed in Java not just inside string literals, but <i>everywhere</i> in the source code. So, for example, the following program prints &quot;Hello, world!&quot; even though that line of code seems to be commented (\u000a is new line, so it ends the comment):<p><pre><code> public class Test { public static void main(String[] args) { &#x2F;&#x2F; \u000a System.out.println(&quot;Hello, world!&quot;); } } </code></pre> Moreover, a \u000a inside a string literal is the same as an actual newline, so the compiler doesn&#x27;t accept it:<p><pre><code> Test2.java:3: error: unclosed string literal String s = &quot;\u000a&quot;; ^ </code></pre> But now with the raw string literal proposal, JEP 326[1], Unicode escape processing is disabled inside raw string literals, and \u0060 escapes (backticks) aren&#x27;t considered backticks for the purposes of starting raw string literals.<p>So, with this proposal, Unicode escapes are in a worst-of-two-worlds middle way:<p>1) They can&#x27;t be handled uniformly at a low level anymore, so a Java parser can&#x27;t naively convert escapes while reading the source file, but<p>2) They must <i>still</i> be naively interpreted in unexpected places like comments and normal string literals, as shown in my examples.<p>What a mess.<p>[1] <a href="https:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;326" rel="nofollow">https:&#x2F;&#x2F;openjdk.java.net&#x2F;jeps&#x2F;326</a>
评论 #18741992 未加载
评论 #18741808 未加载
评论 #18741690 未加载
评论 #18741634 未加载
mabbo超过 6 年前
JEP325 seems like a nice little improvement. Just a linguistic trick but still lovely.<p><pre><code> int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -&gt; 6; case TUESDAY -&gt; 7; case THURSDAY, SATURDAY -&gt; 8; case WEDNESDAY -&gt; 9; }; </code></pre> Switches can return values, and can have multiple cases on the same line.<p>I&#x27;m sure in 2 years when my organization gets around to switching to Java 12, I&#x27;ll enjoy using it.
评论 #18740957 未加载
评论 #18743036 未加载
评论 #18741197 未加载
评论 #18742115 未加载
ccleve超过 6 年前
I&#x27;m glad they&#x27;re going to try to get multi-line strings right, but seriously, I (and many other people) have wanted this feature for 19 years.<p>This is not an exaggeration. I was writing code in Java to access SQL databases in 1999 and needed it to express long SQL strings.<p>One would think they could move a little faster.
评论 #18741359 未加载
hyperpape超过 6 年前
Since Java 12 isn’t an LTS, isn’t the effective delay for slipping a release just 6 months? Many shops are going to use 8, 11 and 17 (assuming it’s the next LTS), so it won’t even matter to them.<p>If that’s right, it’s exactly how the new release cadence is supposed to work—there’s no longer such a hard decision between delaying the release, leaving a feature to languish for several years, or releasing a feature without time to validate it.
jorblumesea超过 6 年前
Can someone explain to me why java has never considered as &quot;import com.package.foo.bar as bar&quot; feature? I really think fully qualified names can be disgusting when you have two classes of the same name.
评论 #18741902 未加载
评论 #18742589 未加载
评论 #18741872 未加载
vmsp超过 6 年前
Can anyone recommend a good resource to get up to speed with Java&#x27;s new features since 1.8?
评论 #18742097 未加载
beders超过 6 年前
Adding new syntax to Java is tricky (unless certain other JVM languages starting with C ;) but I was really disappointed in the string proposal.<p>At the very least, have a default, optional string substitution feature. It ain&#x27;t that hard and it&#x27;s something users of raw strings will NEED anyways. What good is it to have snippets of raw strings that then need to be parsed again and split and re-glued again?<p>JavaScript backticks are much more useful out of the box. But that isn&#x27;t the Java way... In Java, everyone gets to write their own string substitution library, littering the heap with completely unnecessary substrings.<p>After the disasters with generics and enums, do it right, for once, please?
评论 #18743056 未加载
评论 #18741845 未加载
mruts超过 6 年前
If Java were to support to scale&#x2F;fp-like match statements with case objects and unapply methods, it would probably be good enough to obviate Scala (It would still be distinctly worse though).<p>Pattern matching is such a powerful feature. I wish more languages (like python) would realize it’s value and add it.
评论 #18745235 未加载
评论 #18741507 未加载
评论 #18741502 未加载
评论 #18741601 未加载
f1nch3r超过 6 年前
I&#x27;m bummed that the raw string literals are delayed, but the new switch statement does look nice.