New in Java 13: Text Blocks (oracle.com) 57
The October issue of Oracle's Java magazine includes an article reminding us that Java 13 includes a long-awaited new features: text blocks.
With text blocks, Java 13 is making it easier for you to work with multiline string literals. You no longer need to escape the special characters in string literals or use concatenation operators for values that span multiple lines. You can also control how to format your strings. Text blocks -- Java's term for multiline strings -- immensely improve the readability of your code...
A text block is defined using three double quotes (""") as the opening and closing delimiters. The opening delimiter can be followed by zero or more white spaces and a line terminator. A text block value begins after this line terminator.
A text block is defined using three double quotes (""") as the opening and closing delimiters. The opening delimiter can be followed by zero or more white spaces and a line terminator. A text block value begins after this line terminator.
Re: (Score:2)
Re: (Score:1)
You might. Long after .NET and your other faggot tools are over.
Re: It's cool I tried and it works great! (Score:2)
Re: (Score:2)
"Alright, Mr. Wiseguy, if you're so clever, you tell us what colour it should be".
I must say I'm absolutely thrilled to bits that Java now has multiline literals. I fully expect it to top every most-popular-programming language list next year because of this. Definitely worth a Slashdot article just to let the world know of this astonishing new breakthrough.
Re: (Score:1)
Cool I guess (Score:5, Insightful)
I mean, yeah that will probably come in handy occasionally I guess.
Realistically though, any time I have a block of string more than a few lines long, it's usually coming from a config file or database. I associate "big block of text" as more of a scripting thing than a proper application thing. But it does no harm to have it supported so what the hell.
Re: (Score:2)
Sometimes you need a bunch of bulk text in one place in the code, and it's a nuisance, but I'm not convinced this is much of an improvement.
Re:Cool I guess (Score:4, Insightful)
From the description in the summary, it works exactly like text blocks in Python. It is a handy feature. It makes code both easier to write and easier to read.
Re: (Score:2)
From the description in the summary, it works exactly like text blocks in Python. It is a handy feature. It makes code both easier to write and easier to read.
Serves the same purpose as "here docs" in Perl.
I was wondering the same thing (Score:1)
Realistically though, any time I have a block of string more than a few lines long, it's usually coming from a config file or database.
I had the same thought, there have been very few times I've had extended blocks of text, and none that I can think of the text wouldn't have been better off in a file that was loaded at runtime.
I was wondering what Java people would end up using this for (and I ask that as someone who has done a lot of Java server development before in the past).
Re: (Score:3)
This seems like the kind of feature you would use in a really simple application that is never going to be translated into another language and where setting up a configuration system and template engine and dealing with having to deploy more than just a single file becomes more bother than its worth.
That is, this feels more like a convenient cop-out that may occasionally be justified than something that really adds anything to the language. I won't claim I've never had a big blob of text in a message to th
Re:I was wondering the same thing (Score:4, Informative)
It is an extremely useful feature that should be present in every language. It is long overdue.
You don't need to have large text blobs in source. I start wishing for it when I have like 3 lines, like a bit of formatted SQL in code.
Java + SQL looks so ugly that everyone reaches for an ORM right away, even for simple use. No one does that in Python or similar language. This is so basic that even C++ 11 has it (raw string literals). As usual, Java is late to the game in modernizing the language, even compared to C++. This should have been introduced in Java 8.
Re: (Score:1)
So...most applications, then.
Re: I was wondering the same thing (Score:1)
Re: Cool I guess (Score:1)
I'm one of those weirdos who still hasnt adoped orm persistance frameworks.. i see a big win for things like complex sql queries.
This is mostly an issue in my mind where say wanting to copy the query to test or modify in the database management/dev tools.
Basic quality of life improvment in my humble opinion :)
Multi-line is a staple of modern coding (Score:3, Insightful)
I write proper applications with literally millions of users for a multi-billion dollar company. Because I am writing proper applications, I need to write templates for XML and JSON interfaces as well as na
Re: Multi-line is a staple of modern coding (Score:4, Insightful)
Re: Multi-line is a staple of modern coding (Score:2)
Securely. I guess the GP's production code is only run in enterprise environments where people with names like Bobby ';DROP * from *;' Tables mysteriously never made it through the hiring process due to system outages whenever they submitted their resume.
Re: (Score:2)
Re: (Score:2)
Your timeline is off. Quake came out in 1996, before both Firestarter and Java 1.1 (the first version with java.sql).
Re: (Score:2)
You do know that ORM frameworks ultimately just write sql code and run it, right? Sure sometimes you will be able to hand craft a better query but that won't be the norm. And decent ORMs allow you to do that when you need to.
I am very well aware. It is my daily job to write Java, DB, and JPA code. One of the banes of my existence is showing bad developers how to get results in queries instead of loading giant datasets into memory and manipulating them in Java.
JPA is fine for basic CRUD. Once you have to join lots of tables or do analysis on data, it often just doesn't cut it and you have to write a direct SQL query, which you can pass to Hibernate. I often replace 1000 line blocks of slow, bloated code from people who s
Re: Cool I guess (Score:2)
Comment removed (Score:3)
Re:Yay (Score:4, Interesting)
I feel like while this has its legit uses, it's more of an anti-feature.
Some obvious exceptions, but generally I think if you have a wall of text, it aught to be in a separate file and not just hammered into the code. If substitutions are required, you should be using a template engine. Big blobs of static text make it harder to translate a program into another language, and couple presentation logic to business logic. Both of these are at best irrelevant but never good.
Re: (Score:2)
The template engine would usually be 100 times slower than the compiler, why the funk would I bother with that and learn the template engine API?
Most languages have multi line texts.
And it cant be so hard to do a search and replace in proper text editor and convert a multi line string into a concatanated list of single line strings.
Re: (Score:3)
Legit not sure if trolling or serious, so will give benefit of doubt.
The template engine would usually be 100 times slower than the compiler, why the funk would I bother with that and learn the template engine API?
Substitutions pretty much have to be a runtime thing, because the compiler isn't going to know the user input to be interpolating in. Regardless most good template engines actually compile the templates, and even then resolving a template to output is happening at the presentation layer where it's unlikely to be the performance bottleneck.
Most languages have multi line texts.
And it cant be so hard to do a search and replace in proper text editor and convert a multi line string into a concatanated list of single line strings.
It took me awhile to figure out what you were on about here.. but I meant spoken languages, not progra
Re: (Score:2)
Substitutions pretty much have to be a runtime thing, because the compiler isn't going to know the user input to be interpolating in.
The compiler will transform something like this:
"""
first line ${firsVar}
${topicVar} about the topic
"""
into code like this:
Regardless most good template engines actually compile the templates,
Yes, a template could be compiled
Re: (Score:2)
SQL queries. That I think is the big use case for multiline text blocks. A 50 line query no longer requires StringBuilder line by line concatenation. That will improve readability.
Re: (Score:2)
Yeah, that's certainly valid, though having things broken up does let you commentate on the relationships as you build the query.
Re: (Score:1)
Re: (Score:2)
SQL injection is negated nowadays by parametrized queries. The entire statement is not built dynamically, just the shell, like this: "Select col1, col2, col3 from myTable where col1 = ? and col2 like ?;" Then, from incoming data, you extract the parameters (which the first and second question marks represent, and are automagically identified as parameter 1 and parameter 2 by the java interpreter/compiler), and via a java statement, load them into the query. Very simple.
ANY language, Java, C#, PHP, etc, whe
Thief! Thief! (Score:4, Funny)
Stop Thief!
You stole that idea from Python. It is a copyright infringement for you to be using it.
Oracle, hoisted by their own petard.
Re: (Score:2)
C# has also had them for the last 17 years. Really, nothing to see here.
Re: (Score:2)
Whoosh!
The point flew in one ear and right out the other meeting no resistance in between ...
Re: (Score:2)
Re: (Score:2)
Congrats (Score:4, Informative)
Congratulations, Java, for finally catching up to the bourne shell. Well, almost. In the shell you can use whatever delimiter you want.
Comment removed (Score:3, Funny)
Re: (Score:2, Interesting)
I'll bite, what is so special about 1.8 (or I guess so special about later versions).
Re: (Score:2)
Seriously? (Score:2)
Re: Seriously? (Score:2)
Java already has multiline strings (Score:2)
http://www.adrianwalker.org/20... [adrianwalker.org]
package org.adrianwalker.multilinestring;
public final class MultilineStringUsage { /**
Hello
Multiline
World
*/
@Multiline
private static String html;
public static void
Re: (Score:2)
Well, that's what one calls "a solution".
Comment removed (Score:4, Funny)
Why emphasize Text Blocks? (Score:1)
The approach chosen for Java 13 is not even particularly feature-rich. It doesn't allow for compiler-checked string interpolation or producing anything other than java.lang.String values (e.g. generating lazy CharSequences or parsing Text Blocks into completely different types doesn't seem to be possible). At least they seem to be getting indentation right, so you can produce any amount of indentation in the text while staying flexible regarding coding style. Seems to me like an quite conservative, although
Finally modern language? (Score:1)
I don't understand the numbering. (Score:2)
Re: (Score:1)
The "leap" from JDK 8 to JDP 9 took about 3.5 years. I think this was because of some silly "community arguments" or something similar. After this, they seem to be on a twice-a-year release schedule. So every half a year you now get a new Java version. One year from now it will be JDK 15 already. If you look at the features introduced, it does not seem very exciting, but whatever. Almost looks like an Oracle business model with all the support times and licenses.
https://en.wikipedia.org/wiki/... [wikipedia.org]
JDK8 I belie
Barney approves (Score:2)
Wow Oracle/Java13 devs, I can see your MIT education really pays for itself!
- Barney Calhoun