Is it common to write File Parsers in higher languages like Java?

Question

I work with an older framework (15 years+) at work which is fully built on Perl. Its main tasks are calling external programs via command-line calls, parsing their output and presenting some of the parsed information alongside the general output.

Now if I would create a structure like this in something like Java, I was wondering if it is acceptable to write things like the parsers in this language too. In other areas I have seen other scripting languages like Python or even rarely Bash being used but never a fully compiled language.

Is this just "bad luck" on my end or is there a bigger problem with this and that is the reason I don't find anything like it?

The only thing I could think of is stuff like slight speed differences and that languages like Perl are specifically made for parsing. But I would not write Perl parsers for my otherwise Java-based platform and then call them as external scripts via something like the Runtime class in Java, would I?

Answer 1

Programmers write programs in the languages they feel most comfortable with. Me being a Java programmer would be inclined to use Java to write a file parser, though Java is certainly not the most adept language to use for the task, not because it is inefficient but because it tends to require a lot of boilerplate code. Most, but not all of this boilerplate code centers around OOP design, and since the task at hand is very much functional in nature, the need for classes may at best come from representing a single line in the file or header information.

For what concerns file parsing/handling, python would be better suited from an efficiency perspective, outperforming Java's streams. However, depending on the complexity of your program, you may prefer using Java for what comes after the actual parsing of the file, especially if you're using Java 8, whose streams could make multithreaded work a relatively simple task.

That said, when you're holding a hammer, everything looks like a nail. Try not to write programs to do tasks that can already be performed at least in part by programs like awk and grep that can reduce the actual program to a far more simple one that takes a fourth of the time to write. Higher languages don't necessarily produce better programs, just more complex ones.

Answer 2

Just a few weeks ago, I transformed a GeoJson file to a custom binary format and wrote a JavaScript parser to replace the original JavaScript GeoJson parser. Around the same time, I also transformed a custom binary format to a more compact binary format and wrote a JavaScript parser to replace the C++ parser that was used for the original binary format. So, basically, I wrote two parsers in JavaScript for reading different binary formats.

I can't say this is something I do all the time, but it's not something I thought about twice either. If I need to parse a certain file type, I first look for open source projects in whichever language I'm using to do the hard work for me. If I can't find any for whatever reason, I just write one myself.

Sure, C++ and Perl are going to be faster than a language like Java or JavaScript, but for most use cases the performance impact is simply too small to bother adding a language you're not really familiar with to your stack or that would be used only for parsing. So if your language of preference is Java, just write your parser in Java. Period!

Whatever reason there may be for you not being able to find a suitable open source Java library to do the parsing for you, it's not because it's something that you're not supposed to do.

Answer 3

I'm going to give you an entirely different perspective on this question to the other answers. The point is that while there is no specific reason not to write a program that parses the output of another program in Java, as a rule, Java programs are substantially less likely to do this than so-called "scripting" languages like perl and Python. While there are technical reasons (Java's process control libraries have historically been pretty poor, making it difficult to handle external processes cleanly without multiple threads and/or external native libraries - which are widely discouraged in Java culture as not "pure Java" - and the lack of a dedicated syntax for regular expressions certainly adds a bit of overhead to such a system) the primary reasons are cultural.

Java culture emphasizes platform portability. Relying on external programs makes it difficult to be portable.

Java culture prefers object oriented solutions. A stream of text data is not a good fit to OO.

Java culture likes libraries that package up features and that can be installed by adding a maven dependency. External programs don't fit that model.

In a situation where a perl program would usually call an external process and parse the results, it would be most likely that a Java program will import a Java library that performs the action of the external process and returns the result already encapsulated in a neat object-oriented representation.

If the external process cannot be integrated directly into the Java system like this (perhaps because it must run on a remote system, or perhaps must be integrated with non-java software) the next most likely approach is to call it as a service using a network protocol, preferably based on a standardized data format (so the parser already exists), eg using JSONP or similar.

Answer 4

There's a simple answer to "Is it common to write File Parsers in higher languages like Java?" and that answer is yes, it's very common. As to whether this is good idea, a lot of factors matter. As Jules points out, calling other programs from Java tends to be somewhat challenging. Another question is whether these formats are custom. If they are standard formats, parsing libraries for Java will often already exist. If they are custom, you'd probably want to look at something like ANTLR.