DEV Community: Bastien Helders

Think twice before using a Supplier

Bastien Helders — Fri, 17 Nov 2017 15:53:30 +0000

Supply and demand

At the end of my last article, we had this piece of non-functioning code, which tried to replace placeholder string from a first list with strings from a second list:

private static void populateTemplateFile(ArrayList<String> sKeys, ArrayList<String> sVals) {
    File file = new File(TEMPLATE_FILE);
    File trgFile = new File(TARGET_FILE);
    Stream<String> lines = null;

    try
    {
        lines = Files.lines(Paths.get(file.toURI()));

        //Newline for readability, this is only one line.
        Stream<String> replaced = lines
            .map(line -> {
                for(int iCtr=0; iCtr<sKeys.size(); iCtr++)
                    line.replaceAll(sKeys.get(iCtr), sVals.get(iCtr));
                    return line;});
        lines.close();
        Files.write(Paths.get(trgFile.toURI()), replaced.toString().getBytes());
    }
    catch (IOException e)
    {
       log.error("Exception while trying to create " + TARGET_FILE, e);
    }
    finally {
        lines.close();
    }
}

I concluded the article that although I tried to use Stream, the fact that it is a double loop would make this case a poor candidate for what I wanted to do.

But then it came to me that for my first example, I used a Supplier to access the stream twice, why not n time? It would enable me to extract the for loop out of the map call and instead, I would replace the value in the lines for each of the element of the keys list.

It sounded so simple until I realized it wouldn't work. You see, when the Supplier supplies you the line of the file, it supplies you the lines as they were untouched. This is fine when you don't plan on modifying the values, but this is another story when you are doing replacements. In the end, only one replacement would have been made: the last one.

The Keys to success

However, all hopes were not lost. You see, at the same time I was trying in vain to use a Supplier, LluÃs Josep Martinez pointed me to a way to write the output file as a stream.

I was at first skeptical, but he seemed sure of himself that it would be the solution. So I searched again for a solution.

First, it seemed sensible, as LluÃs suggested, to use a Map as parameter of the method instead of two Lists. And make the parameter name more explicit.

private static void populateTemplateFile(Map<String,String> substitutionDictionary) {

But it still didn't help me with my Supplier issue. So I tried to take another perspective. You see, my issue is that I can seem to find an adequate solution to loop through the keys and trying to replace them in the lines.

So what if I looped through the lines first instead? But then I'll get back to the issue of the for loop in the map call again. Unless I get rid of the second loop. You see, as a PHP dev, I used the in_array() function a lot to see if a string was contained in an Array. Granted, the lines containing the information contains more than only the key information (i.e. the placeholders) I was searching, but in a similar fashion, I could check if any of the keys was contained in a file line.

Function<String,String> replacePlaceholders = (line) -> {
    Set<String> keySet = substitutionDictionary.keySet();
    Optional<String> key = keySet.stream()
                                 .filter(line::contains)
                                 .findAny();

    if(key.isPresent()) {
        return line.replace(key.get(), substitutionDictionary.get(key.get()));
    }

    return line;
}

And then I just needed to apply the code found on the link provided by LluÃs.

try (Stream<String> lines = Files.lines(Paths.get(file.toURI()));
     PrintWriter output = new PrintWriter(TARGET_FILE, "UTF-8"))
{

    lines.map(s -> replacePlaceholders.apply(s))
         .forEachOrdered(output::println);
    output.close();
}

In fact, using a Function to do data manipulation is so potent, that I found a similar solution for someone else's problem.

Leaky Supplier

To come back to the piece of code which inspired me to write my first article, I was glad, as it was working and got me the result I wanted. That is until I got a java.nio.file.FileSystemException telling me that there were too many open files... It turned out I was leaking file handles and I had to ensure that those handles would be closed. So I went ahead and used a try-with-resource as suggested.

Supplier<Stream<String>> linesSupplier = () -> {
    try(Stream<String> lines = Files.lines(Paths.get(file.toURI())))
    {
        return lines;
    }
    catch (IOException e)
    {
        log.error("Error while supplying file " + file.getName(), e);
    }
    return null;
};

I got disappointed real fast, as it threw me an IllegalStateException as it did before I used a Supplier. And rightly so, as the Supplier closes the Stream it returned before I could use it.

Again, I had to change perspective. What if I stored all the values at once. And it is possible if I store the Predicate in a list and do all the filtering sequentially before the Stream closes.

List<String> values = null;
List<Predicate<String>> filters = Arrays.asList(sourcePattern.asPredicate(), contentPattern.asPredicate());
String source = "";
String content = "";

try (Stream<String> lines = Files.lines(Paths.get(file.toURI())))
{
    values = lines.filter(line -> filters.stream()
                                      .anyMatch(f -> f.test(line)))
                  .collect(Collectors.toList());
    source = values.get(0);
    content = values.get(1);
}
catch (IOException e)
{
    log.error("Error while filtering " + file.getName(), e);
}

I can then use the values I got to my heart content. Yes, I've been said that I could have transferred the responsibility to close the Stream to the line of code which called the Supplier, but I think that in the end, I found a better way.

Parting thoughts

There is no doubt a good use for a Supplier, but until now, I didn't find one. So next time you try to use one, because you want to access your Stream more than once, ask yourself: "Can't I instead get all I need from the Stream at once?"
If you get stump by a problem, try to change perspective? More often than not, it helps.

Until the next time I need to change my point of view.

Technology stack for one-page one-function web app?

Bastien Helders — Wed, 15 Nov 2017 17:37:12 +0000

EDIT: Was "Best web app technology stack?", but noticed it was not really what I meant to ask

I’m still finishing my article on learning the functional API of Java 8, but I don’t want it to be my only focus. In fact, I want to write about the projects that I’m working at any given point.

My experience in web development has been limited to an HTML/CSS/JavaScript/PHP stack for most part on its pure form. No framework or fancy libraries because that’s how a “real developer” would do it. (I really used to think like that.)

Now it’s time for a change. I want to know what would be good stacks of technologies (framework/libraries/tools/...) to develop one-page one-function web app, such as graph presentation or simple utility tool. Being able to pack the app to be used on any computer would be a plus. About the languages I would use, it could be any of the previous mentioned ones, Java, but it could also be any languages which could be easy to pick if it gives me some advantages.

So what would you pick? It can be your favourite, or simple what you think is interresting. I’ll look into the suggestions, choose some and write about my experience.

Navigating the uncharted Stream

Bastien Helders — Tue, 07 Nov 2017 09:33:14 +0000

Wrong bend of the river

When I left school, Java 6 had just been released and wasn’t really integrated into the school curriculums yet. But I was content to think that I could simply stay as a web developer and forget all that Java is (didn't pay that much attention), forget about IDE, compiler, and all that nonsense. Who needs something like that when you’ve got your trusty text editor to power your web wizardry? Boy, was I wrong.

Since about 2 years, I need to use Java again, I first went in it with my basic programming language knowledge, then rediscovered Object-Oriented Programming and lately I’ve been introduced to Java 8 features. But each time I encountered a new obstacle in my way, I used the new or re-acquainted knowledge more as a Band-Aid, leading more often degraded a bit the quality of the code. Lately, after some refactoring session to level things a bit, I realized that I needed to change strategy. So instead of always scratch the surface, I decided to dig deeper.

The uncharted Stream

It first began when I wanted to find specific information in files, to see if the content wasn’t affected during the course of a test. I would have used reader = new BufferedReader(new FileReader(file)); to check each line for the specific pattern, And this for each file, if I didn't find this question on how to find pattern in files which used the Stream object introduced in Java 8. As a result, I came up with the following code:

// Searching for <filename:"…"> and extract its value.
Pattern pattern = Pattern.compile("filename:\"(.+)\"");

// List of objects containing information on the files
// generated at the beginning of the test.
List<GeneratedFile> generatedFileList = myTest.getFileList();

For (File file : fileList){
    Optional<String> message = Files.lines(Paths.get(file.toURI()))
                                    .filter(pattern.asPredicate())
                                    .findFirst();
    if (message.isPresent())
    {
        String fileContent = message.get();
        Matcher matcher = pattern.matcher(fileContent);
        matcher.find();
        String value = matcher.group(1);
        GeneratedFile generatedFile = findFileByOriginalName(value, generatedFileList);
        if(generatedFileList == null){
            Assert.fail("File "
                        + originalFilename
                        + " wasn't found.");
        }
    }
}

private static GeneratedFile findFileByOriginalName(String filename,
                                List<GeneratedFile> generatedFileList){
    for (GeneratedFile generatedFile : generatedFileList){
        if(generatedFile.getFileName().equals(filename)){
            return generatedFile;
        }
    }
    return null;
}

It became more complicated when I wanted to extract another data point from the file content and it threw me an IllegalStateException. I then discovered the Supplier which would allow me to get the content of the file for each search without worrying about the Stream auto-closing:

Supplier<Stream<String>> linesSupplier = null;
try
{
    linesSupplier = () -> getFileStream(tempfile);
}
catch (Exception e)
{
    log.error(e);
}

//Replace the pattern for each piece of information searched.
Optional<String> message = linesSupplier.get()
                                        .filter(filenamePattern.asPredicate())
                                        .findFirst();

private static Stream<String> getFileStream(File file)
{
    try
    {
        return Files.lines(Paths.get(file.toURI()));
    }
    catch (IOException e)
    {
    log.error("Exception while trying to supply file "
              + file.getName()
              + " content"
              , e);
    }
    return null;
}

Rocky ride

I was quite intrigued and decided to use my newfound knowledge everywhere I thought applicable. And I thought it would be perfect for dealing with any file operation and get rid of those pesky finally clause. I thought that the new and shiny thing would be so much better. Turns out that a Stream is not always auto-closeable, and furthermore it completely broke my code and became an unreadable mess...

Needless to say, my understanding of Stream was not as good as the one I had for Optional for which I already found a use I mostly agree upon. At that point, I decided that I should thrive to better understand what I use, so I could make the best of it.

So when does one use Stream? Let me quote an answer to this question as I asked on Stack Overflow:

If you can easily separate out distinct steps to apply to each dataset member, a Stream seems like a solid bet since that API can combine steps whenever possible.

It means that you need to have a concrete idea of what needs to happen to a point where you can describe it with discrete steps.

Furthermore, I found out that one should be aware of the order in which you do your operations: first, you need to filter, then manipulate and finally collect. Even if it seems like it wouldn't matter most of the time, there are some cases where it could be relevant and it makes more sense from a story standpoint.

Crashing waves

Let's talk about a concrete example, the one I alluded at the beginning of the previous section.

I have a template file that I want to populate by replacing placeholder strings with the wanted values. For that, I feed my method two lists, one with the placeholder keys and one with the desired values.

private static void populateTemplateFile(ArrayList<String> sKeys, ArrayList<String> sVals){
    String line="";
    String newline = System.getProperty("line.separator");
    BufferedReader reader = null;
    FileWriter writer = null;
    StringBuilder storeLine = new StringBuilder("");

    try{
        File file = new File(TEMPLATE_FILE);
        reader = new BufferedReader(new FileReader(file));
        while((line = reader.readLine()) != null){
            storeLineBuilder.append(line + newline);
        }
        reader.close();

        String storeLine = storeLineBuilder.toString();
        for (int iCtr=0; iCtr<sKeys.size();iCtr++){
            storeLine=storeLine.replaceAll(sKeys.get(iCtr), sVals.get(iCtr));
        }

        writer = new FileWriter(TARGET_FILE);
        writer.write(storeLine);
        writer.close();

    } catch(FileNotFoundException e) {
        log.error("The file " + TARGET_FILE + " could not be found!", e);
    } finally {
        if(reader != null) {
            reader.close();
        }
        if(writer != null) {
            writer.close();
        }
    }
}

Now it was my first attempt at adapting the method to use Stream:

private static void populateTemplateFile(ArrayList<String> sKeys, ArrayList<String> sVals) {
    File file = new File(TEMPLATE_FILE);
    File trgFile = new File(TARGET_FILE);
    Stream<String> lines = null;

    try
    {
        lines = Files.lines(Paths.get(file.toURI()));

        //Newline for readability, this is only one line.
        Stream<String> replaced = lines
            .map(line -> {
                for(int iCtr=0; iCtr<sKeys.size(); iCtr++)
                    line.replaceAll(sKeys.get(iCtr), sVals.get(iCtr));
                    return line;});
        lines.close();
        Files.write(Paths.get(trgFile.toURI()), replaced.toString().getBytes());
    }
    catch (IOException e)
    {
       log.error("Exception while trying to create " + TARGET_FILE, e);
    }
    finally {
        lines.close();
    }
}

What a mess did I make... At this point, I would have expected a three-beat story of filtering, processing, collecting but here is what I have:

Get the stream I initialized earlier.
For each of the key, replace it by its corresponding value. Repeat for each line.
Profit?

It appears quite clunky to me for two reasons: there are no clear collecting steps and we have here a double iteration and after further researching the subject, it appears that the use of Stream, in most cases, would not be advised.

In the end I couldn't find a process which would do things better as what is currently used.

Parting thoughts

I am still at the beginning of my journey, but now I have a much better insight on when to use Stream. To summarize:

There should be a clear story as to what you want to do.
The story should, in general, follow the pattern filter -> process -> collect.
Double loop is a no go.

In the end, I now have the feeling that I acquired a comprehension of the utility of Stream and will be able to use it better from now on.

Until the next bend of the river.