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?

  • 5
    Your question is a matter of opinion. "Is it acceptable?" - Sure, why not? There are a number of libraries to help you write parsers in Java, for example ANTLR and JavaCC. If your whole system is in Java then it doesn't make a lot of sense to especially write the parser in something entirely different such as Perl and then call that from your Java code.
    – Jesper
    Jul 26, 2017 at 7:24
  • Sure you can write parsers in Java, but it's comparatively inconvenient: immutable strings, no pointers, no language-level regex integration, …. You'll probably need 3× the amount of code for Java compared to Perl for this kind of task. You'll have to decide whether an unified Java platform is worth more than the cost of porting all the code to Java. Alternatively you could get a copy of the Modern Perl book and clean up your Perl code to become more maintainable, which would be a lower-risk move.
    – amon
    Jul 26, 2017 at 8:44
  • Furthermore those libraries are already very optimized even in Java, unless you want to parse multiple Tera-octet of data every day, performance is not a probem there.
    – Walfrat
    Jul 26, 2017 at 8:44
  • 2
    @Walfrat OP mentions they are parsing the output of command line programs to extract some data. These often have an informal textual output format. Using parser generators or lexers is absolute overkill for this and would need even more code.
    – amon
    Jul 26, 2017 at 9:47
  • 1
    @amon That would depends on the number of possibilities, but yes just for some commands with little parameters that would be overkill.
    – Walfrat
    Jul 26, 2017 at 10:56

4 Answers 4


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.

  • Do you have any stats / benchmarks on Python outperforming Java Streams? Given that I/O is involved and rate limiting, I doubt that one language would be significantly faster.
    – user949300
    Jul 27, 2017 at 1:25
  • @user949300 I distinctly recall an article pitting pros and cons of various aspects of Java and Python. While Python certainly didn't win in every category, in IO operations it was slightly improved. I can't find the article (I checked when I wrote my answer and again now in fact), but I did find this with benchmarking results. patmch:1t and patmch:2t both use IO operations.
    – Neil
    Jul 27, 2017 at 6:23
  • Thanks. Interesting chart on the lower left of that page - might be the Regex implementation that affects the timing.
    – user949300
    Jul 27, 2017 at 15:55

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.

  • @JimmyJames : Java is to JavaScript what ham is to hamster. I get that. I'm a JavaScript programmer who doesn't like Java, so there's no need to point out the obvious. I mentioned both in the same breath because the OP used the term "higher languages". Both Java & JavaScript are examples of what I'd consider "higher languages" and therefore can be mentioned in the same breath in this particular context. Jul 27, 2017 at 17:30
  • Java is more similar to C++ and Javascript is more similar to Perl, in my mind. So the statement is a little provocative and could probably use some clarification. For one, in a number of use cases, Java's performance is often similar to C++.
    – JimmyJames
    Jul 27, 2017 at 17:33
  • 1
    @JimmyJames : Java and C++ have static typing whereas JavaScript has dynamic typing. In that sense, Java and C++ are more similar indeed. However, C++ has explicit pointers and no automatic garbage collection, whereas Java and JavaScript both don't have explicit pointers but do have automatic garbage collection. In this context, JavaScript & Java have more in common with each other... and the lack of explicit pointers & automatic garbage collection are some of the reasons why both Java & JavaScript are typically considered "higher" languages than C++! Jul 27, 2017 at 17:39
  • C++ is an extremely feature-rich language. Many of these are much more 'high-level' than anything that Java provides. Are you suggesting that Perl is a low-level language?
    – JimmyJames
    Jul 27, 2017 at 18:00
  • 1
    @JimmyJames : I know little to nothing about Perl, so I can't comment on that. Anyway, a language being labeled as "high level" or "low level" is not a matter of how many features that language has. It's a matter of how many layers of abstraction there are between the code you write and the machine code it produces. See eg. this Quora question for more details on why C and C++ are consider low level languages when compared with eg. Java... Jul 27, 2017 at 18:06

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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