Stephan van Hulst

The question is, why are you implementing a sort at all? Java has a built in generic sort algorithm. Are you doing this as an exercise?

That's called being cocky.

Just keep practicing.

First off, ask yourself what it is that you want a stream of, and how are you going to get it? Then you add processing steps later.

You want a stream of doubles from the scanner. Starting out with Stream.of(in.nextDouble()) won't do, because you will get a stream consisting of only one double.

Let's take a look at Scanner. It has a method tokens() (Java 9) that returns a stream of all tokens that you would have gotten by calling next() repeatedly. It would have been perfect for us if we wanted to handle string tokens, but we want a stream of doubles. So there are two things we can do:

Use tokens() and filter out tokens that are not doubles and then parse the other tokens as doubles.

Generate the stream ourselves from repeatedly calling nextDouble().

The advantage of the first approach is that we can filter out tokens that are not doubles before we start working on them. The disadvantage is that tokens() is only available starting with Java 9.

The advantage of the second approach is that the code to create a stream is super simple, but the downside is that it will crash if there are tokens in the scanner that aren't valid doubles.

Let's start with the first approach. If we use Scanner.tokens(), we start with a stream of strings. We want a stream of doubles, so we first have to filter out strings that are not doubles. Let's make a method that can check whether a string is a double:
private static final class Token {  private static boolean isDouble(String string) {    return new Scanner(string).useDelimiter("$").hasNextDouble();  } } static void printSolution(Scanner input) {  input.tokens().filter(Token::isDouble).mapToDouble(Double::parseDouble); }
Now we have a DoubleStream which we can process further. Let's start by limiting how many elements we get from it. Then, we map each value to a magnitude, and finally we print them all:
var numberOfCases = input.nextInt(); input.tokens()  .filter(Token::isDouble)  .mapToDouble(Double::parseDouble)  .limit(numberOfCases)  .mapToInt(x -> (x == 0) ? 1 : (int) floor(log10(x) + 1))  .forEachOrdered(System.out::println);
Doing all of this with the second approach is pretty much the same, except for how we create the stream:
DoubleStream.generate(input::nextDouble)  .limit(numberOfCases)  .mapToInt(x -> (x == 0) ? 1 : (int) floor(log10(x) + 1))  .forEachOrdered(System.out::println);

I give classes default access, unless I need to use them in a different package.

I give methods private access, unless I need to use them in a different class. Then I give them default access, unless I need to use them in a different package.

I always give fields private access. Period.

final class YesOrNoApplication {  public static void main(String... args) {    ...  } }

Actually, it IS possible if those variables are declared as wrapper types. Don't use Integer, use int instead.

I love using natural/compound keys, but I will concede that it can be a pain if the keys are big (long strings or many components) and have to be used in many other tables, causing those tables to bloat.

I don't like using surrogate keys if a row can be identified uniquely by natural properties, but it's important to consider issues like how well the keys can be indexed or how large they are.

Drop the habit of making declarations public by default. Make classes and methods package private until you're certain they're going to be used in other packages.

Make your classes final, unless you have a REALLY good reason to extend them, and have designed them to be extended. This is not a trivial task.

You don't have to initialize your answer variable when you declare it, because the initial value is never used.

Why are the strings that you print enclosed in an extra pair of parentheses?

Take the effort to use variable names that make the code read fluently. Instead of answer, which implies that the variable holds the actual answer, use something like 'isAnswerValid'.

In this particular case it doesn't really matter, but in general avoid the toUpperCase() and toLowerCase() methods. Instead, use the overloads that take a Locale.

A common bug in many professional codebases is that they assume programs are going to be executed on a system with latin encoding. For instance, if one of the answers that the user could have given was the letter 'i', your code would have failed if you checked for the uppercase letter 'I' and the program was executed on a Turkish machine, because in Turkish, "i".toUpperCase() returns "İ".

If your application is not internationalized and you use hard-coded strings in a particular language, then also perform string operations using the same Locale:
input.toUpperCase(Locale.ENGLISH)

All your POMs are poorly indented. Use consistent indenting.

It's common for group and artifact IDs to be all lowercase.

Your parent POM doesn't lock down the following plugins: maven-antrun-plugin, maven-assembly-plugin, maven-dependency-plugin, maven-release-plugin.

Your parent POM declares dependencies that should be declared in sub-modules. Right now it forces all sub-modules to have dependencies they might not need. Use <dependencyManagement> if you just want to configure dependencies without requiring them.

You can remove <packaging>jar</packaging> from your POMs, because that's the default.

Try to list plugins and dependencies alphabetically by group ID and then by artifact ID, to make them easy to locate.

Properties are inherited, so you don't have to declare the source encoding and compiler version in every sub-module.

Plugin configuration is inherited, so you don't have to reconfigure plugins in sub-modules when you've configured them in the <pluginManagement> element of the parent POM.

You can pre-configure the versions of commonly used plugins in your parent POM. Your sub-modules then only have to declare the group and artifact IDs, and can omit the version.

Eliminate explicit declarations of transitive dependencies from your POM. For instance, your analysis module directly depends on commons-math3, but the declaration is unnecessary because it already gets that dependency through the core module.

I created a Pull Request that merges these changes into your repository. Let me know what you think.

Congratulations all! It's good to have you join the ranks.

Matt Wong wrote:so - IF you want to encrypt something - use AES - and at least something secure as CBC or OFB or so - never ECB

Wrong. IF you want to encrypt something, you generally want to use an AEAD algorithm like GCM, OCB or EAX. Don't hack around by combining primitives by yourself.

Java comes with GCM and unless you're working on a small embedded device with limited memory, there's very little reason not to use it.

Please show us the command you used to compile.

We want you to have your client execute that command on their system so we can debug it.

If it works, then clearly java is installed and is working, and then the default file association for .jar is not configured to run the correct command. In that case the fix that Daniel proposed would likely solve your problems.

They do. You're just not getting any output because you clear the list that the asynchronous task have to work with, so they don't print anything.

The fact that it works at all is more luck than anything else.

A big part of the problem is that you're passing the same list instance to every asynchronous task handler and clearing it instead of creating a new one. So not only does every handler work with the same list of lines, the lines are cleared at the same time that the processing begins.

Let's first create a reusable collector that will batch your lines:
 public static <T, A, D, C extends Collection<D>> Collector<T, ?, C> batching(    int maxBatchSize,    Supplier<C> collectionFactory,    Collector<? super T, A, D> downstream  ) {    final class Accumulation {      private final C finishedBatches = collectionFactory.get();      private A nextBatch = downstream.supplier().get();      private int nextBatchSize;            private boolean isEmpty() {        return finishedBatches.isEmpty() && nextBatchSize == 0;      }            private void finishNextBatch() {        D finishedChunk = downstream.finisher().apply(nextBatch);        finishedBatches.add(finishedChunk);        nextBatch = downstream.supplier().get();        nextBatchSize = 0;      }      void accumulate(T element) {        downstream.accumulator().accept(nextBatch, element);        if (nextBatchSize == maxBatchSize)          finishNextBatch();      }            Accumulation combine(Accumulation other) {        if (other.isEmpty())          return this;                if (this.isEmpty())          return other;                if (nextBatchSize > 0)          finishNextBatch();                finishedBatches.addAll(other.finishedBatches);        nextBatch = other.nextBatch;        return this;      }            C finish() {        if (nextBatchSize > 0)          finishNextBatch();                return finishedBatches;      }    }    return Collector.of(      Accumulation::new,      Accumulation::accumulate,      Accumulation::combine,      Accumulation::finish    );  }
You can then very easily achieve what you want with the following code:
final class ChunkProcessor implements Callable<String> {    private final List<String> lines;    ChunkProcessor(Collection<String> lines) {    this.lines = new ArrayList<>(lines);  }    @Override  public String call() {    //  }    static void processInChunks(Stream<String> lines, ExecutorService executor) throws InterruptedException {    var processors = lines.collect(batching(3, ArrayList::new, collectingAndThen(toList(), ChunkProcessor::new)));    var futureResults = executor.invokeAll(processors);    // When the application has reached this line, all chunks will have finished being processed in parallel.  } }