<div><p style="font-size:50px;margin-top:0;margin-bottom:0">❤️</p><p style="margin-top:10px;margin-bottom:0">David Alayachew reacted via <a href="https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app">Gmail</a></p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Oct 27, 2025 at 6:53 PM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com">pavel.rappo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Oct 27, 2025 at 9:19 PM David Alayachew<br>
<<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br>
><br>
> Woah, thanks.<br>
><br>
> So, in your second example, it's literally complaining because, as far as the Java compiler is concerned, I typed in a literal new line in between the single quotes, right? Like this?<br>
><br>
> System.out.println('<br>
> ');<br>
><br>
> Correct?<br>
<br>
Yes.<br>
<br>
> Very important context, ty vm.<br>
><br>
> So, \7 is fine because that actually is an escape sequence. Much like \n and friends.<br>
<br>
Yes. BTW, another way to write down \n would be \12:<br>
<br>
jshell> Integer.toOctalString('\n')<br>
$1 ==> "12"<br>
<br>
jshell> '\n' == '\12'<br>
$2 ==> true<br>
<br>
> But \uXXXX gets turned into the literal bytes, which means that something like a new line gets treated as if I literally pressed the new line button on my keyboard, which means that it's treated not as a new line character in my string, but as a new line character in my source file itself lol.<br>
><br>
> Ty vm.<br>
<br>
Like I said, escape sequences are only recognised in certain context.<br>
But unicode escapes are recognised everywhere. For example, \n does<br>
not mean anything in a javadoc comment, On the other hand, \u000A<br>
means the same thing wherever it appears: source, javadoc, or your<br>
copyright header. Still, \n and \u000A are not the same:<br>
<br>
jshell> '\n' == '\u000A'<br>
<br>
| Error:<br>
| illegal line end in character literal<br>
| '\n' == '\u000A'<br>
| ^<br>
<br>
-Pavel<br>
<br>
<br>
-Pavel<br>
<br>
> On Mon, Oct 27, 2025, 9:44 AM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>> wrote:<br>
>><br>
>> Correcting a typo*:<br>
>><br>
>> jshell> System.out.println('\u000A')<br>
>> | Error:<br>
>> | illegal line end in character literal<br>
>> | System.out.println('\u000A')<br>
>> |<br>
>><br>
>><br>
>> On Mon, Oct 27, 2025 at 1:32 PM Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>> wrote:<br>
>> ><br>
>> > A word of caution. While in this use case the difference is probably<br>
>> > non-essential, Unicode escapes (e.g. \u0007) are __not__ a kind of<br>
>> > escape sequences (e.g. \7). The former are translated into raw bytes<br>
>> > __before__ the compiler goes any further. The latter are recognised by<br>
>> > the compiler only in context of character literals, strings, or text<br>
>> > blocks.<br>
>> ><br>
>> > To illustrate the difference, let's consider "line feed" (0xA):<br>
>> ><br>
>> > jshell> System.out.println('\n')<br>
>> ><br>
>> ><br>
>> ><br>
>> > jshell> System.out.println('\000A')<br>
>> > | Error:<br>
>> > | unclosed character literal<br>
>> > | System.out.println('\000A')<br>
>> > | ^<br>
>> ><br>
>> > While the former is recognised within the context of a character<br>
>> > literal, the latter just breaks the source code in a similar way as if<br>
>> > the source code had the actual line feed in it.<br>
>> ><br>
>> > Unicode escapes allow you to simply input a Unicode character "by<br>
>> > reference". This is convenient in some cases, such as when your<br>
>> > environment cannot output these characters conveniently or display<br>
>> > them properly.<br>
>> ><br>
>> > -Pavel<br>
>> ><br>
>> > On Mon, Oct 27, 2025 at 12:56 PM David Alayachew<br>
>> > <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br>
>> > ><br>
>> > > Ah, I misread the JLS Language Grammar!<br>
>> > ><br>
>> > > I was aware of \u0007, but not \7. I see now that that works. Then nevermind, that meets my needs just fine. No need for my suggestion.<br>
>> > ><br>
>> > > The 4 digit unicode is fine, a good escape hatch, but also easy to forget, since my brain interprets all 4 digits as significant. And char bell = 7; is also unideal. But a 1 digit escape works perfectly for me. Would have preferred \a, but \7 is more explicit and easier to look up.<br>
>> > ><br>
>> > > Ty vm!<br>
>> > ><br>
>> > > On Mon, Oct 27, 2025, 6:15 AM Andrew Dinn <<a href="mailto:adinn@redhat.com" target="_blank">adinn@redhat.com</a>> wrote:<br>
>> > >><br>
>> > >><br>
>> > >><br>
>> > >> On 26/10/2025 17:26, David Alayachew wrote:<br>
>> > >> > Also, here is the JLS 25 entry about escape sequences -- https://<br>
>> > >> > <a href="http://docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7" rel="noreferrer" target="_blank">docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7</a><br>
>> > >> > <<a href="https://docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7" rel="noreferrer" target="_blank">https://docs.oracle.com/javase/specs/jls/se25/html/jls-3.html#jls-3.10.7</a>><br>
>> > >> ><br>
>> > >> > All I really want is for that to be added to the list, so that I can do<br>
>> > >> > it the same as I would in other languages. It sounds like an in-place<br>
>> > >> > replacement done by the compiler.<br>
>> > >><br>
>> > >> What is wrong with using \u0007 or \7? (as documented in the html page<br>
>> > >> you cited).<br>
>> > >><br>
>> > >> regards,<br>
>> > >><br>
>> > >><br>
>> > >> Andrew Dinn<br>
>> > >> -----------<br>
>> > >> Red Hat Distinguished Engineer<br>
>> > >> He/Him/His<br>
>> > >> IBM UK Limited<br>
>> > >> Registered in England and Wales with number 741598<br>
>> > >> Registered office: Building C, IBM Hursley Office, Hursley Park Road,<br>
>> > >> Winchester, Hampshire SO21 2JN<br>
>> > >><br>
>><br>
</blockquote></div>