current community

your communities

more stack exchange communities

Stack Exchange
tour help
stack overflow careers
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 220 down vote favorite
34

Coming from Perl, I sure am missing the "here-document" means of creating a multi-line string in source code:

$string = <<"EOF"  # create a three line string
text
text
text
EOF

In Java I have to have cumbersome quotes and plus signs on every line as I concatenate my multiline string from scratch.

What are some better alternatives? Define my string in a properties file?

Edit: Two answers say StringBuilder.append() is preferable to the plus notation. Could anyone elaborate as to why they think so? It doesn't look more preferable to me at all. I'm looking for away around the fact that multiline strings are not a first-class language construct, which means I definitely don't want to replace a first-class language construct (string concatenation with plus) with method calls.

Edit: To clarify my question further, I'm not concerned about performance at all. I'm concerned about maintainability and design issues.

share|improve this question
7  
StringBuilder.append() is preferable to plus when repeatedly adding to a string because every time you do string1 + string2 you're allocating a new string object and copying the characters from both of the input strings. If you're adding n Strings together you'd be doing n-1 allocations and approximately (n^2)/2 character copies. StringBuilder, on the other hand, copies and reallocates less frequently (though it still does both when you exceed the size of its internal buffer). Theoretically, there are cases where the compiler could convert + to use StringBuilder but in practice who knows. –  Laurence Gonsalves May 18 '09 at 17:18
3  
Every time I jump into the debugger, + is converted to a StringBuilder.append() call, on Java 1.5. I've had colleagues confusedly tell me StringBuilder has a bug since they debug into code that does not appear to call it and wind up there. –  skiphoppy May 18 '09 at 17:34
3  
See also: stackoverflow.com/questions/782810/… –  Michael Myers♦ May 18 '09 at 17:55
34  
Note that a string literal made up of "abc\n" + "def\n" etc. does not use StringBuilder: the compiler glues them together and puts them into the .class file as a single literal, same as with other types of constant folding. –  araqnid May 18 '09 at 18:00
4  
Most IDEs support entering multi-line strings. ie. you just type or paste what you want into a "" string and it will add the \n and " + " as required. e.g. I can paste a 40 lines of text into a String and teh IDE sorts it out for you. –  Peter Lawrey Oct 24 '10 at 12:19

33 Answers 33

1 2
up vote 58 down vote accepted

Stephen Colebourne has created a proposal for adding multi-line strings in Java 7.

Also, Groovy already has support for multi-line strings.

share|improve this answer
10  
The Project Coin process for enhancements to Java included multi line strings mail.openjdk.java.net/pipermail/coin-dev/2009-February/…. It was rejected by Oracle blogs.sun.com/darcy/entry/project_coin_final_five. –  JodaStephen Mar 25 '11 at 11:12
7  
any change in 2012? –  Ilia G Jul 9 '12 at 19:22
7  
Unfortunately this doesn't appear to have made it into the spec. –  namuol Jan 18 '13 at 4:07
1  
The blogs.sun.com link is broken, but I think the content is at blogs.oracle.com/darcy/entry/project_coin_final_five now. –  Donal Fellows Feb 12 '14 at 7:53
up vote 203 down vote

It sounds like you want to do a multiline literal, in which case your best option (IMHO) is going to be strings that are +'d together. The other options (StringBuilder and String.format) would only be preferable if you already had your string in an array.

Consider this:

String s = "It was the best of times, it was the worst of times,\n"
         + "it was the age of wisdom, it was the age of foolishness,\n"
         + "it was the epoch of belief, it was the epoch of incredulity,\n"
         + "it was the season of Light, it was the season of Darkness,\n"
         + "it was the spring of hope, it was the winter of despair,\n"
         + "we had everything before us, we had nothing before us";

Versus String Builder:

String s = new StringBuilder()
           .append("It was the best of times, it was the worst of times,\n")
           .append("it was the age of wisdom, it was the age of foolishness,\n")
           .append("it was the epoch of belief, it was the epoch of incredulity,\n")
           .append("it was the season of Light, it was the season of Darkness,\n")
           .append("it was the spring of hope, it was the winter of despair,\n")
           .append("we had everything before us, we had nothing before us")
           .toString();

Versus String.format:

String s = String.format("%s\n%s\n%s\n%s\n%s\n%s", 
               "It was the best of times, it was the worst of times,",
               "it was the age of wisdom, it was the age of foolishness,",
               "it was the epoch of belief, it was the epoch of incredulity,",
               "it was the season of Light, it was the season of Darkness,",
               "it was the spring of hope, it was the winter of despair,",
               "we had everything before us, we had nothing before us"
           );

If you want the newline for your particular system, you either need to use System.getProperty("line.separator"), or you can use %n in String.format.

share|improve this answer
131  
Furthermore, the first version will be automatically concatenated by the compiler, since all the strings are known at compile time. Even if the strings are not known at compile time, it's no slower than StringBuilder or String.format(). The only reason to avoid concatenation with +'s is if you're doing it in a loop. –  Michael Myers♦ May 18 '09 at 17:06
13  
+1 for the example text :) –  Michael Borgwardt May 18 '09 at 23:05
7  
The problem with the String.format version is that you have to keep the format in sync with the number of lines. –  Bart van Heukelom Dec 14 '10 at 12:05
2  
String.format is not efficient compared to other two examples –  Casey Dec 30 '10 at 0:50
2  
This answer is a very inappropriate solution to the question at hand. We have 2000 line SAS macros or bunches of 200 line SQL queries which we wish to copy and paste. To suggest that we use +"" concat to transform those multiline text into StringBuffer appends is ridiculous. –  Blessed Geek Sep 24 '12 at 19:44
up vote 95 down vote

In Eclipse if you turn on the option "Escape text when pasting into a string literal" (in Preferences > Java > Editor > Typing) and paste a multi-lined string whithin quotes, it will automatically add " and \n" + for all your lines.

String str = "paste your text here";
share|improve this answer
1  
thank you - this helped! –  necromancer May 4 '13 at 5:44
up vote 36 down vote

This is an old thread, but a new quite elegant solution (with only one drawback) is to use a custom annotation.

Check : http://www.adrianwalker.org/2011/12/java-multiline-string.html

Edit: The above URL seems to be broken. A project inspired from that work is hosted on GitHub:

https://github.com/benelog/multiline 

public final class MultilineStringUsage {

  /**
  <html>
    <head/>
    <body>
      <p>
        Hello<br/>
        Multiline<br/>
        World<br/>
      </p>
    </body>
  </html>
  */
  @Multiline
  private static String html;

  public static void main(final String[] args) {
    System.out.println(html);
  }
}

The drawback is that you have to activate the corresponding (provided) annotation processor.

And you probably have to configure Eclipse to not reformat automatically your javadoc comments.

One may find this weird (javadoc comments are not designed to embed anything other than comments), but as this lack of multiline string in Java is really annoying in the end, i find this to be the least worst solution.

share|improve this answer
2  
You can do this entirely in eclipse. The link that @SRG posted above points you to this link. If you are using eclipse, then a minute of setup and it is working. –  Michael Plautz Sep 18 '14 at 19:22
up vote 31 down vote

Another option may be to store long strings in an external file and read the file into a string.

share|improve this answer
5  
Exactly. Large amounts of text don't belong in Java source; use a resource file of an appropriate format instead, loaded via a call to Class.getResource(String). –  erickson May 18 '09 at 16:51
3  
Right! You can use Locale + ResourceBundle's also to easily load the I18N text, and then the String.format() call will parse the "\n"'s as newlines :) Example: String readyStr = String.parse(resourceBundle.getString("introduction")); –  ATorras May 18 '09 at 17:13
35  
You shouldn't have to externalize a String just because it's multi-line. What if I have a regex that I want to break up into multiple lines with comments? It looks ugly in Java. The @ syntax for C# is much cleaner. –  Jeremy Stein Oct 16 '09 at 20:45
5  
Skiphoppy doesn't want to bother with the overhead of dealing with files just to use a paragraph length string constant. I use multiline strings all the time in C++, embedded in my source code, where I want them. –  Tim Cooper Nov 6 '09 at 5:35
6  
Wow. I can't believe C++ is actually better than Java on this issue! I love multi-line string constants and they DO belong in source in some cases. –  User1 Jan 25 '11 at 22:14
up vote 17 down vote

This is something that you should never use without thinking about what it's doing. But for one-off scripts I've used this with great success:

Example:

    System.out.println(S(/*
This is a CRAZY " ' ' " multiline string with all sorts of strange 
   characters!
*/));

Code:

// From: http://blog.efftinge.de/2008/10/multi-line-string-literals-in-java.html
// Takes a comment (/**/) and turns everything inside the comment to a string that is returned from S()
public static String S() {
	StackTraceElement element = new RuntimeException().getStackTrace()[1];
	String name = element.getClassName().replace('.', '/') + ".java";
	StringBuilder sb = new StringBuilder();
	String line = null;
	InputStream in = classLoader.getResourceAsStream(name);
	String s = convertStreamToString(in, element.getLineNumber());
	return s.substring(s.indexOf("/*")+2, s.indexOf("*/"));
}

// From http://www.kodejava.org/examples/266.html
private static String convertStreamToString(InputStream is, int lineNum) {
    /*
     * To convert the InputStream to String we use the BufferedReader.readLine()
     * method. We iterate until the BufferedReader return null which means
     * there's no more data to read. Each line will appended to a StringBuilder
     * and returned as String.
     */
    BufferedReader reader = new BufferedReader(new InputStreamReader(is));
    StringBuilder sb = new StringBuilder();

    String line = null; int i = 1;
    try {
        while ((line = reader.readLine()) != null) {
            if (i++ >= lineNum) {
                sb.append(line + "\n");
			}
        }
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        try {
            is.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    return sb.toString();
}
share|improve this answer
4  
Requires shipping the Java code for the class with the final binary. Hmm. –  Thorbjørn Ravn Andersen May 18 '10 at 6:13
4  
+1. Some lack of imagination by persons voting down. This is a useful construct for writing small utilities, test cases, and even in controlled prod environments. This is a difference maker between dropping out of java into ruby/python/etc or staying here. –  javadba May 26 '13 at 18:55
up vote 15 down vote

If you define your strings in a properties file it'll look much worse. IIRC, it'll look like:

string:text\u000atext\u000atext\u000a

Generally it's a reasonable idea to not embed large strings in to source. You might want to load them as resources, perhaps in XML or a readable text format. The text files can be either read at runtime or compiled into Java source. If you end up placing them in the source, I suggest putting the + at the front and omitting unnecessary new lines:

final String text = ""
    +"text "
    +"text "
    +"text"
;

If you do have new lines, you might want some of join or formatting method:

final String text = join("\r\n"
    ,"text"
    ,"text"
    ,"text"
);
share|improve this answer
3  
+1 I like the join look the best. –  Blindy Nov 3 '09 at 15:59
up vote 15 down vote

Pluses are converted to StringBuilder.append, except when both strings are constants so the compiler can combine them at compile time. At least, that's how it is in Sun's compiler, and I would suspect most if not all other compilers would do the same.

So:

String a="Hello";
String b="Goodbye";
String c=a+b;

normally generates exactly the same code as:

String a="Hello";
String b="Goodbye":
StringBuilder temp=new StringBuilder();
temp.append(a).append(b);
String c=temp.toString();

On the other hand:

String c="Hello"+"Goodbye";

is the same as:

String c="HelloGoodbye";

That is, there's no penalty in breaking your string literals across multiple lines with plus signs for readability.

share|improve this answer
2  
to be technical, in your first example it generates something more like: String c = new StringBuilder().append(a).append(b).toString(); The difference being that the temporary string builder is out of scope and eligible for garbage collection immediately after the String c=... line, whereas the "temp" string builder would stay around a little longer. –  Kip Jun 4 '09 at 16:24
up vote 7 down vote 
String newline = System.getProperty ("line.separator");
string1 + newline + string2 + newline + string3

But, the best alternative is to use String.format

String multilineString = String.format("%s\n%s\n%s\n",line1,line2,line3);
share|improve this answer
9  
How is StringBuilder less annoying and unreadable? –  Michael Myers♦ May 18 '09 at 16:41
1  
Stringbuilder example is at least as unreadable. Also, don't forget that "\n" isn't always a newline, but it's fine for linux and unix machines. –  Stefan Thyberg May 18 '09 at 16:45
2  
Replacing one plus sign with a six-character method name and parentheses doesn't look more readable to me, although apparently you're not the only one who thinks that way. It doesn't remove the quotes, though. They are still there. –  skiphoppy May 18 '09 at 16:50
up vote 7 down vote

See Java Stringfier. Turns your text into a StringBuilder java block escaping if needed.

share|improve this answer
1  
it's not preserving newlines... –  Janus Troelsen May 15 '12 at 10:16
up vote 6 down vote

Since Java does not (yet) native support multi-line strings, the only way for now is to hack around it using one of the aforementioned techniques. I built the following Python script using some of the tricks mentioned above:

import sys
import string
import os

print 'new String('
for line in sys.stdin:
    one = string.replace(line, '"', '\\"').rstrip(os.linesep)
    print '  + "' + one + ' "'
print ')'

Put that in a file named javastringify.py and your string in a file mystring.txt and run it as follows:

cat mystring.txt | python javastringify.py

You can then copy the output and paste it into your editor.

Modify this as needed to handle any special cases but this works for my needs. Hope this helps!

share|improve this answer
up vote 5 down vote

Sadly, Java does not have multi-line string literals. You either have to concatenate string literals (using + or StringBuilder being the two most common approaches to this) or read the string in from a separate file.

For large multi-line string literals I'd be inclined to use a separate file and read it in using getResourceAsStream() (a method of the Class class). This makes it easy to find the file as you don't have to worry about the current directory versus where your code was installed. It also makes packaging easier, because you can actually store the file in your jar file.

Suppose you're in a class called Foo. Just do something like this:

Reader r = new InputStreamReader(Foo.class.getResourceAsStream("filename"), "UTF-8");
String s = Utils.readAll(r);

The one other annoyance is that Java doesn't have a standard "read all of the text from this Reader into a String" method. It's pretty easy to write though:

public static String readAll(Reader input) {
    StringBuilder sb = new StringBuilder();
    char[] buffer = new char[4096];
    int charsRead;
    while ((charsRead = input.read(buffer)) >= 0) {
        sb.append(buffer, 0, charsRead);
    }
    input.close();
    return sb.toString();
}
share|improve this answer
up vote 5 down vote

You may use scala-code, which is compatible to java, and allows multiline-Strings enclosed with """: 

package foobar
object SWrap {
  def bar = """John said: "This is
  a test
  a bloody test,
  my dear." and closed the door.""" 
}

(note the quotes inside the string) and from java:

String s2 = foobar.SWrap.bar ();

Whether this is more comfortable ...?

Another approach, if you often handle long text, which should be placed in your sourcecode, might be a script, which takes the text from an external file, and wrappes it as a multiline-java-String like this: 

sed '1s/^/String s = \"/;2,$s/^/\t+ "/;2,$s/$/"/' file > file.java

so that you may cut-and-paste it easily into your source.

share|improve this answer
up vote 5 down vote

If you like google's guava as much as I do, it can give a fairly clean representation and a nice, easy way to not hardcode your newline characters too:

String out = Joiner.on(newline).join(ImmutableList.of(
    "line1",
    "line2",
    "line3"));
share|improve this answer
up vote 3 down vote

you can concatenate your appends in a separate method like

public static String multilineString(String... lines){
   StringBuilder sb = new StringBuilder();
   for(String s : lines){
     sb.append(s);
     sb.append ('\n');
   }
   return sb.toStirng();
}

either way, prefer StringBuilder to the plus notation.

share|improve this answer
3  
Why do I prefer StringBuilder to the plus notation? –  skiphoppy May 18 '09 at 16:44
6  
Efficiency, or rather an often-misguided attempt at it. –  Michael Myers♦ May 18 '09 at 16:55
2  
The attempt at efficiency is based, I think, on the fact that the Java compiler implements the string concatenation operator using StringBuilder (StringBuffer in pre-1.5 compilers). There is an old, but well-known article stating that there are performance benefits in certain situations to using StringBuffer (or StringBuilder, now). Here's the link: java.sun.com/developer/JDCTechTips/2002/tt0305.html –  Paul Morie May 18 '09 at 17:32
up vote 3 down vote

Define my string in a properties file?

Multiline strings aren't allowed in properties files. You can use \n in properties files, but I don't think that is much of a solution in your case.

share|improve this answer
up vote 3 down vote

An alternative I haven't seen as answer yet is the java.io.PrintWriter.

StringWriter stringWriter = new StringWriter();
PrintWriter writer = new PrintWriter(stringWriter);
writer.println("It was the best of times, it was the worst of times");
writer.println("it was the age of wisdom, it was the age of foolishness,");
writer.println("it was the epoch of belief, it was the epoch of incredulity,");
writer.println("it was the season of Light, it was the season of Darkness,");
writer.println("it was the spring of hope, it was the winter of despair,");
writer.println("we had everything before us, we had nothing before us");
String string = stringWriter.toString();

Also the fact that java.io.BufferedWriter has a newLine() method is unmentioned.

share|improve this answer
up vote 3 down vote 
    import org.apache.commons.lang3.StringUtils;

    String multiline = StringUtils.join(new String[] {
        "It was the best of times, it was the worst of times ", 
        "it was the age of wisdom, it was the age of foolishness",
        "it was the epoch of belief, it was the epoch of incredulity",
        "it was the season of Light, it was the season of Darkness",
        "it was the spring of hope, it was the winter of despair",
        "we had everything before us, we had nothing before us"
    }, "\n");
share|improve this answer
up vote 2 down vote

When a long series of + are used, only one StringBuilder is created, unless the String is determined at compile time in which case no StringBuilder is used!

The only time StringBuilder is more efficient is when multiple statements are used to construct the String.

String a = "a\n";
String b = "b\n";
String c = "c\n";
String d = "d\n";

String abcd = a + b + c + d;
System.out.println(abcd);

String abcd2 = "a\n" +
        "b\n" +
        "c\n" +
        "d\n";
System.out.println(abcd2);

Note: Only one StringBuilder is created.

  Code:
   0:   ldc     #2; //String a\n
   2:   astore_1
   3:   ldc     #3; //String b\n
   5:   astore_2
   6:   ldc     #4; //String c\n
   8:   astore_3
   9:   ldc     #5; //String d\n
   11:  astore  4
   13:  new     #6; //class java/lang/StringBuilder
   16:  dup
   17:  invokespecial   #7; //Method java/lang/StringBuilder."<init>":()V
   20:  aload_1
   21:  invokevirtual   #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   24:  aload_2
   25:  invokevirtual   #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   28:  aload_3
   29:  invokevirtual   #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   32:  aload   4
   34:  invokevirtual   #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
   37:  invokevirtual   #9; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
   40:  astore  5
   42:  getstatic       #10; //Field java/lang/System.out:Ljava/io/PrintStream;
   45:  aload   5
   47:  invokevirtual   #11; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   50:  ldc     #12; //String a\nb\nc\nd\n
   52:  astore  6
   54:  getstatic       #10; //Field java/lang/System.out:Ljava/io/PrintStream;
   57:  aload   6
   59:  invokevirtual   #11; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   62:  return

To clarify my question further, I'm not concerned about performance at all. I'm concerned about maintainability and design issues.

Make it as clear and simple as you can.

share|improve this answer
up vote 2 down vote

I suggest using a utility as suggested by ThomasP; and then link that into your build process. An external file is still present to contain the text, but the file is not read at runtime. The workflow is then:

  1. build a 'textfile to java code' utility & check into version control
  2. on each build, run the utility against the resource file to create revised java source
  3. the java source contains a header like class TextBlock {... followed by a static string which is auto-generated from the resource file
  4. build the generated java file with the rest of your code
share|improve this answer
up vote 2 down vote

One small trick. Using this I inject javascritp in a dynamically created HTML page 

StringBuilder builder = new StringBuilder();

public String getString()
{
    return builder.toString();
}
private DropdownContent _(String a)
{
    builder.append(a);
    return this;
}

public String funct_showhide()
{
   return
    _("function slidedown_showHide(boxId)").
    _("{").
    _("if(!slidedown_direction[boxId])slidedown_direction[boxId] = 1;").
    _("if(!slideDownInitHeight[boxId])slideDownInitHeight[boxId] = 0;").
    _("if(slideDownInitHeight[boxId]==0)slidedown_direction[boxId]=slidedownSpeed; ").
    _("else slidedown_direction[boxId] = slidedownSpeed*-1;").
    _("slidedownContentBox = document.getElementById(boxId);").
    _("var subDivs = slidedownContentBox.getElementsByTagName('DIV');").
    _("for(var no=0;no<subDivs.length;no++){").
    _(" if(subDivs[no].className=='dhtmlgoodies_content')slidedownContent = subDivs[no];").
    _("}").
    _("contentHeight = slidedownContent.offsetHeight;").
    _("slidedownContentBox.style.visibility='visible';").
    _("slidedownActive = true;").
    _("slidedown_showHide_start(slidedownContentBox,slidedownContent);").
    _("}").getString();

}
share|improve this answer
2  
A poor choice. Use plus signs. Other, higher-rated answers explain why and how. –  Ian May 21 '11 at 3:59
up vote 2 down vote

Java 8 added a new static method to java.lang.String which offers a slightly better alternative:

public static String join(CharSequence delimeter, CharSequence... elements);

Using it:

String s = String.join(System.getProperty("line.separator"),
    "First line.",
    "Second line.",
    "The rest.",
    "And the last!"
);
share|improve this answer
up vote 1 down vote

The only way I know of is to concatenate multiple lines with plus signs

share|improve this answer
up vote 1 down vote

It may seem a little crazy, but since heredocs are syntactic sugar over one-line declarations with linebreaks escaped, one could write pre-processor for Java files that would change heredocs into single-liners during preprocessing.

It would require writing proper plugins for preprocessing files before compilation phase (for ant/maven build) and a plugin to IDE.

From ideological point of view, it differs nothing from f.g. "generics", that are also a kind of pre-processed syntactic sugar over casting.

It's, however, a lot of work, so I would at your place just use .properties files.

share|improve this answer
up vote 1 down vote

A quite efficient and platform independent solution would be using the system property for line separators and the StringBuilder class to build strings:

String separator = System.getProperty("line.separator");
String[] lines = {"Line 1", "Line 2" /*, ... */};

StringBuilder builder = new StringBuilder(lines[0]);
for (int i = 1; i < lines.length(); i++) {
    builder.append(separator).append(lines[i]);
}
String multiLine = builder.toString();
share|improve this answer
1  
+1 for mentioning the line.separator property :-) –  Stefan Thyberg May 18 '09 at 16:54
up vote 1 down vote

Actually, the following is the cleanest implementation I have seen so far. It uses an annotation to convert a comment into a string variable...

/**
  <html>
    <head/>
    <body>
      <p>
        Hello<br/>
        Multiline<br/>
        World<br/>
      </p>
    </body>
  </html>
  */
  @Multiline
  private static String html;

So, the end result is that the variable html contains the multiline string. No quotes, no pluses, no commas, just pure string.

This solution is available at the following URL... http://www.adrianwalker.org/2011/12/java-multiline-string.html

Hope that helps!

share|improve this answer
up vote 0 down vote

A simple option is to edit your java-code with an editor like SciTE (http://www.scintilla.org/SciTEDownload.html), which allows you to WRAP the text so that long strings are easily viewed and edited. If you need escape characters you just put them in. By flipping the wrap-option off you can check that your string indeed is still just a long single-line string. But of course, the compiler will tell you too if it isn't.

Whether Eclipse or NetBeans support text-wrapping in an editor I don't know, because they have so many options. But if not, that would be a good thing to add.

share|improve this answer
up vote 0 down vote

I got a bit annoyed with reading that multiline syntax is indeed been planned for jdk7 (after about how many decades of java existence?). Funnily, there is not even yet a readAll() function for reading the complete contents of a file (from jdk7 only, huhh), so the code below reads single lines. 

/*
  MakeMultiline v1.0 (2010) - Free to use and copy.

  Small gadget to turn text blobs into one java string literal
  (doing the split in lines, adding \n at each end and enclosing
  in double quotes). Does escape quotes encountered in the text blob.

  Useful for working around missing multiline string syntax in java
  prior jdk7. Use with:

     java MakeMultiline "    "
  or
     java MakeMultiline "    " mytextfile.txt
*/

import java.io.*;

class MakeMultiline {
  public static void main(String[] args) {
    try {
      // args[0]: indent
      // args[1]: filename to read (optional; stdin if not given)
      // Beware the nmb of newlines at the end when using stdin!

      String indent = (args.length > 0 ? args[0] : "");
      FileReader fr = null; BufferedReader br;
      if (args.length > 1)
        { fr =  new FileReader(args[1]); br = new BufferedReader(fr); }
      else
        { br = new BufferedReader(new InputStreamReader(System.in)); }
      String s; String res = "";
      while((s = br.readLine()) != null) {
        if (res.length() > 0) res += " +\n";
        res += indent + "\"" + s.replace("\"", "\\\"") + "\\n\"";
      }
      br.close(); if (fr != null) fr.close();
      System.out.println(res + ";");
    }
    catch(Exception e) {
      System.out.println("Exception: " + e);
    }
  }
}

This was the quickest solution for me. (2010-01-27)

share|improve this answer
up vote 0 down vote

I see at least one case where it should be avoided to use external files for long strings : if these long string are expected values in an unit-test file, because I think the tests should always be written in a way that they don't rely on any external resource.

share|improve this answer
up vote 0 down vote

Use Properties.loadFromXML(InputStream). There's no need for external libs.

Better than a messy code (since maintainability and design are your concern), it is preferable not to use long strings.

Start by reading xml properties:

    InputStream fileIS = YourClass.class.getResourceAsStream("MultiLine.xml");
    Properties prop = new Properies();
    prop.loadFromXML(fileIS);


then you can use your multiline string in a more maintainable way...

    static final String UNIQUE_MEANINGFUL_KEY = "Super Duper UNIQUE Key";

    prop.getProperty(UNIQUE_MEANINGFUL_KEY) // "\n    MEGA\n   LONG\n..."




MultiLine.xml gets located in the same folder YourClass:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">

<properties>
    <entry key="Super Duper UNIQUE Key">
       MEGA
       LONG
       MULTILINE
    </entry>
</properties>

PS.: You can use <![CDATA[" ... "]]> for xml-like string.

share|improve this answer
1 2

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.