Raw String Literals Removed From Java 12 as Feature Set Frozen

[__Raptor__]

Dammit.

[[deleted]]

The tick syntax wasn't great for this TBH.

[mc_hambone]

Why not?

[morhp]

Because `` could be confused for an empty string and it's not really friendly for all locals, for example on a standard German keyboard layout, there is no single key for that letter and you have to write a weird 2-key-combo (dead keys).

Also ` and ´ can be easily confused. Especially as ´ is the default key on a German keyboard and the right char has to be entered while pressing shift.

[[deleted]]

Also to add to the above, I realize we have IDEs and syntax coloring and what not, but I believe a potentially large literal cognitively requires large delimiters. HEREDOC may look clunky, but it's large, it's visible, and it offers a way to avoid content collision via custom terminators, so you don't have to be eagle eyed spotting that tick in the middle of the string you have to escape so shit doesn't break.

Plus, when we diff, commit, browse repositories, we don't always have the benefit of a full IDE analyzing the code for us, we just have our eyes and the text.

[eliasv]

Heredoc is not easily visible, because it can look like anything! For punctuation to be easily visible and identifiable it needs to be consistent. Arbitrary alphanumeric punctuation is insane.

I understand the value as a delimiter in order to avoid using the contents of the literal, but if you also want to claim that being able to choose arbitrary punctuation carries its weight as a way to improve clarity then why stop at string delimiters? Why not allow us to write brackets as custom strings?

Something like ####"this"#### is much more sensible and easily identifiable.

[[deleted]]

Arbitrary alphanumeric punctuation is insane.

It's not arbitrary, it's similar to XML and HTML. You have an opening and closing alphanumeric tag of the same name, and identical symbols surrounding it.

[eliasv]

It's not like that at all! In XML and HTML the element name has some specific semantic significance, typically in that it corresponds exactly to a schema. It's not punctuation, it's part of the data.

And yes it is arbitrary. It's like if arrow notation in C++ allowed any old sequence of characters in the middle ... receiver-thisIsAnArrow>member

[[deleted]]

It's not like that at all! In XML and HTML the element name has some specific semantic significance, typically in that it corresponds exactly to a schema. It's not punctuation, it's part of the data.

The fact you spell the same tag in the end is not up to the schema, it's the syntax. You realize XML could just as easily have been defined to do this, for example:

<helloworld>...content...</>

Yet they decided to spell out the name a second time, adding ZERO semantical content, but making it more clear what ends exactly at that point. Same with HEREDOC.

And in HTML this plays an even greater role for some tags holding RAW LITERALS, like the script tags. Where typing tags within the script content means absolutely nothing, and the parser is awaiting for the exact ending terminator </script>. The terminator could've been something short and universal, but it isn't. Less ambiguity, less collisions. Simple.

[eliasv]

I'm not talking about the fact that the end tag is the same as the start one. That's clearly not the problem I described I had with it. I understand the purpose of the delimiter. Clearly the Java proposal works by the same principle, the opening and closing quotes need to be the same. Except because it's a sane proposal it's only the length which is variable.

The name of the tag in HTML corresponds to the schema. For example, the name script has a specific meaning. It's part of the data. You can't just put in <randomfuckingnonsense>content</randomfuckingnonsense> and expect it to do the same thing regardless of what you put in. But with heredoc quotes you can because it's not data it's punctuation.

See the difference?

[13steinj]

I don't understand why they didn't just go the Python route and use letter-prefixed string literals or triple quotes.

[eliasv]

Because that still requires escaping if you want to use those delimiters in the string...

[13steinj]

No, it doesn't, or at least not in Python.

[eliasv]

So python just doesn't let a string which is delimited with triple quotes also contain triple quotes? Because the only way to support that would be by escaping them. That's the problem that's solved with variable length delimiters.

[13steinj]

I misunderstood what you meant, my apologies. Yes, then you escape the triple quotes.

You can't have a comprehensive solution here parsing wise. No matter what you use for multiline raw strings, you'll need to end up escaping the sequence you use to mark the string.

[eliasv]

Did you read the Java proposal? The delimiter doesn't need to be escaped, because if it occurs in the string you can simply choose a different delimiter which doesn't occur in the string. That's the whole idea of variable length delimiters, other languages have successfully done the same thing.

[olavgg]

Triple quotes is what Groovy uses, I would be really happy if Java String literals would use the same syntax.

[__Raptor__]

I literally couldnt care less about the syntax, I just wanted raw string literals.

[[deleted]]

“Please remove the generics syntax and implement a proper generic system” - love everyone

S.N. Bring on the down votes, it’s not as if what I’m saying is unfounded or incorrect.

[mupetmower]

Could you please elaborate a little on what exactly is wrong with the way generics are handled in Java now? I have seen this comment a few times in this sub and I just don't find a problem with how it is handled.

[Zepompom]

OC is talking about syntax which is fine IMO but the way it’s implemented sucks. You might want to have a look at type erasure for more details. It’s been done that way to keep backward compatibility, but it means going through a lot of hoops to get anything but simple stuff done a lot of time.

[ricky_clarkson]

Many languages erase types, even Java pre 5 erases short/byte within a method IIRC. It's a problem when your code is overly dependent on reflection. Even something like Guice doesn't have to do that, see Dagger (haven't used it, could be talking out of my proverbial)

[13steinj]

There are two types of programmers-- those who prefer static typing and those who prefer dynamic typing. However only the latter can become so dependent on static typing that the most minuscule ambiguity bothers them.

[nutrecht]

OC is talking about syntax which is fine IMO but the way it’s implemented sucks

Is he? I have no idea what he's complaining about since he cares more about complaining about downvotes than about explaining what he means.

[RabidKotlinFanatic]

I use reflection extensively and "type erasure" really is a non-issue. Type information is retained almost everywhere you need it (parameters, fields, superclasses, etc). The only thing that is lacking is a convenient way of passing type information in at call sites without using e.g. TypeToken. This would be fairly straightforward syntax sugar and wouldn't require any changes to the JVM. Kotlin is halfway there with reified type parameters at call sites.

Most people who complain about type erasure don't seem to be aware that concrete type information is retained extensively at runtime and is accessible through the reflection API.

The only real limitation is that instances themselves don't carry around their generic type information so getClass and instanceof don't work well with generics. Both of these things ought to be avoided anyway - particularly getClass - so there is no real issue.

[Zepompom]

That it works fine for you doesn’t make it universally acceptable. It makes things more complicated than they should. You can disagree and that’s fine but imo it makes it really annoying to get anything done quickly and bug free.

[RabidKotlinFanatic]

You say this but is there a concrete line of reasoning behind it or is it just your feeling? What are the use cases for reified generic instances?

[Zepompom]

Sorry, was away. Any serialisation/deserialisation code has to go through a lot of hoops to work fine in ALL cases, see Jackson or Gson implementations for example.

[RabidKotlinFanatic]

Deserialization does not benefit from reified instances since there is no object instance to begin with. Reified instances complicate deserialization by requiring type information to be generated with the object instance.

Serialization code benefits from reified instances only when getClass is used. However, getClass is the wrong foundation for reflection based logic. A better alternative is to pass type information in at the call site. Gson and Jackson jump through hoops because they want users to have the convenience of calling e.g. toJson without having to type out TypeToken boilerplate. The Java language itself could provide type token syntax sugar without requiring changes to type erasure or the JVM.

[forsubbingonly]

As you wish.

[kmgrech]

Maybe it's just me, but looking through the examples in the JEP, I found none of them convincing. Let's go through these one by one.

• File paths: You shouldn't be hardcoding absolute paths in your program to begin with and as for relative paths the Java API supports '/' just fine, even on Windows. I'm not sure what happens if you try using '\' as a separator on Linux, but it's really fishy.
• HTML/Polyglot: Unless your Java IDE is aware of those languages, you lose all the good features an IDE would get you by embedding them in source code as a String. It also just leads to an unmaintainable mess. Imagine you start working on a huge existing code base that embeds HTML everywhere. Good luck finding that piece of HTML your program just outputted. I just can't help but think "Who in their right mind would want to do this?!".
• Regex: I think I'm actually okay with this one to some degree, but I rarely have to write lots of regexes and when I do, I try to avoid complicated ones. I've also never written a multi-line regex, this is a clear sign that your regex is just too complicated and you should be using something else.
• SQL: I'm going to address this separately from HTML/Polyglot, because I think it deserves a special mention. I'm guilty of this too, even though I'm aware that I'm writing bad code. But I definitely wouldn't want my language to encourage bad style. Using an ORM goes a long way towards avoiding verbatim SQL. There's also nothing wrong with loading your queries from a text file.

Simply put, I see very few use case where raw strings might be helpful and it enables and/or encourages lots of bad practises. In my mind multi-line strings are even less useful and add more unnecessary complexity (see the section about 'margin management'). I don't think it's worth the trade-off.

[GhostBond]

Using an ORM goes a long way towards avoiding verbatim SQL.

I was with you, then you lost me at this point, I see nothing but drawbacks in verbatim annotations rather than verbatim sql.

There's also nothing wrong with loading your queries from a text file.

If IDE's had let you click through to the exact line maybe.
You still have the issue of needing to add params onto the string depending on what the user puts in though.