21

Are there any good ways to work with blocks of text (Strings) within Java source code? Many other languages have heredoc syntax available to them, but Java does not. This makes it pretty inconvenient to work with things like tag libraries which output a lot of static markup, and unit tests where you need to assert comparisons against blocks of XML.

How do other people work around this? Is it even possible? Or do I just have to put up with it?

Rob Hruska
  • 118,520
  • 32
  • 167
  • 192
  • See also: http://stackoverflow.com/questions/878573/java-multiline-string (same question; posted later, but with many OK answers) – Eirik W May 25 '12 at 11:56

3 Answers3

1

If the text is static, or can be parameterized, a possible solution would be to store it in an external file and then import it. However, this creates file I/O which may be unnecessary or have a performance impact. Using this solution would need to involve caching the file contents to reduce the number of file reads.

Rob Hruska
  • 118,520
  • 32
  • 167
  • 192
1

The closes option in Java to HereDoc is java.text.MessageFormat. You can not embed logic. It a simple value escape utility. There are no variables used. You have to use zero based indexing. Just follow the javadoc.

http://download.oracle.com/javase/1,5.0/docs/api/java/text/MessageFormat.html

Aris Bartee
  • 728
  • 8
  • 12
0

While you could use certain formatters to convert and embed any text file or long literal as a Java string (e.g., with newline breaks, the necessary escapes, etc.), I can't really think of frequent situations where you would need these capabilities.

The trend in software is generally to separate code from the data it operates on. Large text sections, even if meant just for display or comparison, are data, and are thus typically stored externally. The cost of reading a file (or even caching the result in memory) is fairly low. Internationalization is easier. Changing is easier. Version control is easier. Other tools (e.g., spell checkers) can easily be used.

I agree that in the case of unit tests where you want to compare things against a mock you would need large scale text comparisons. However, when you deal with such large files you will typically have tests that can work on several different large inputs to produce several large outputs, so why not just have your test load the appropriate files rather than inline it ?

Same goes with XML. In fact, for XML I would argue that in many cases you would want to read the XML and build a DOM tree which you would then compare rather than do a text compare that can be affected by whitespaces. And manually creating an XML tree in your unit test is ugly.

Uri
  • 88,451
  • 51
  • 221
  • 321
  • 7
    I think Rob might be describing large multi-line SQL strings in java apps that aren't leveraging an ORM, or doing lots of non-ORM supported SQL stuff. These are definitely part of the logic & code, and are a PITA to work with in java. I don't think I'd want to store them in the db either. – r00fus Aug 18 '10 at 20:51
  • 10
    -1 It's often easier to read test fixtures that have the XML or SQL scripts directly in the Java code. It's very annoying to switch back and forth with extra files or to build a DOM tree by hand when it's very large. You end up having to test the test code. – User1 Jan 25 '11 at 22:35