Mike Simmons

Your properties are being loaded from the file, and only from the file.  Properties from the command line are found among the system properties in System.getProperties().  If you want to combine both, with command-line properties overriding the ones in the file, here is one way:
   Properties properties = new Properties();    properties.load(getClass().getClassLoader().getResourceAsStream("application.properties"));    System.getProperties().putAll(properties);

The motivation is discussed in JEP 330: Launch Single-File Source-Code Programs, which came out in Java 11:

Motivation

Single-file programs -- where the whole program fits in a single source file -- are common in the early stages of learning Java, and when writing small utility programs. In this context, it is pure ceremony to have to compile the program before running it. In addition, a single-file program may declare multiple classes and thus compile to multiple class files, which adds packaging overhead to the simple goal of "run this program". It is desirable to be able to run the program directly from source with the java launcher:
java HelloWorld.java

I think it's because single file program compilation with java is a feature designed to make things simpler for beginning programmers.  They relaxed some rules to make it easier for a beginner to copy and paste some code in one place and get it to run without error.  However, in the longer run it is still considered desirable to organize your code according to the stricter rules of javac.  Since you can't run multi-file programs without using javac, and you can't get other benefits of compiling in advance unless you use javac, you will sooner or later be forced to follow the stricter rules of javac.  You just don't have to learn all those rules at once.

Why is this particular rule considered desirable but not required?  Well, for the compiler, it's not that difficult to just scan everything and find out where a given file is declared.  But for humans, it's nice to organize your code in a standard way that makes it easy for other humans to figure out where a given class might be.  So you want to eventually be following this rule.

Campbell Ritchie wrote:The array indices are calculated from h & c − 1, which for positive values of h gives the same result as h % c.

This omits the fact that another method is invoked before h & c is computed:
 static final int hash(Object key) {        int h;        return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);    }
This is to try to make it so hashes that differ only in the higher-order bits don't lose that differentiation - the differences are spread to lower-order bits as well.  It has no effect on small values like those in this problem, however.

Of course, these details can change in future implementations... as they have in the past.  But this part has been stable for a while now.

Swapnil: the thing to remember is, a HashSet or HashMap aren't guaranteeing that there is never any order in the HashSet or Table.  This isn't a cryptographic application where that order is a problem.  Rather , they are just saying that we shouldn't expect any order.  If some order is present, that's not really a problem.  But the details of the math are more trouble than they are worth to follow.

Swapnil Mishra wrote:this is what I am asking, can't we avoid this creation of a separate class?

Ron, Norm, and Piet show examples that create exactly one new class that handles both even and odds.  In my own post, I show later examples using lambdas and method references, that create no new classes - exactly what you say you want.  I included the earlier versions for comparison.

In the past, lambdas would have been compiled to create classes behind the scenes, because older JVMs required that.  Nowadays this is no longer the case.  Lambda expressions and method references do not create any new classes, even hidden behind the scenes, on modern compilers.

Swapnil Mishra wrote:This above code is not truly multithreading isn't it?

It's technically multithreading, in the sense that you have two threads - the main thread, and the new Multitasking instance thread.  But the even() and odd() code are both occurring in the same thread, so that's probably not what you want.

Swapnil Mishra wrote:any other approach? without needing to create multiple classes?

Well, creating multiple classes is a pretty normal thing in Java, not something to be avoided generally.  But there are a number of simplfications and improvements possible  First, you don't need to extends Thread directly - you can implement Runnable instead:
public class MultiThreading {  public static void main(String[] args) {    Runnable oddTask = new OddTask();    Runnable evenTask = new EvenTask();    new Thread(oddTask).start();    new Thread(evenTask).start();  }  public static void sleep() {    try {      Thread.sleep(1000);    }    catch (InterruptedException e) {      throw new RuntimeException(e);    }  } } class OddTask implements Runnable {  @Override  public void run() {    for (int i = 0; i < 10; i++) {      if (i % 2 != 0) {        MultiThreading.sleep();        System.out.println(Thread.currentThread().getName() + ": " + i);      }    }  } } class EvenTask implements Runnable {  @Override  public void run() {    for (int i = 0; i < 10; i++) {      if (i % 2 == 0) {        MultiThreading.sleep();        System.out.println(Thread.currentThread().getName() + ": " + i);      }    }  } }
I added the sleep() method to slow things down a bit, and put the thread name in the output so you can see the effect.

In the old days, we might write this with anonymous classes:
public class MultiThreading {  public static void main(String[] args) {    Runnable oddTask = new Runnable() {      @Override      public void run() {        odd();      }    };    Runnable evenTask = new Runnable() {      @Override      public void run() {        even();      }    };    new Thread(oddTask).start();    new Thread(evenTask).start();  }  private static void even() {    for (int i = 0; i < 10; i++) {      if (i % 2 == 0) {        sleep();        System.out.println(Thread.currentThread().getName() + ": " + i);      }    }  }  private static void odd() {    for (int i = 0; i < 10; i++) {      if (i % 2 != 0) {        sleep();        System.out.println(Thread.currentThread().getName() + ": " + i);      }    }  }  public static void sleep() {    try {      Thread.sleep(1000);    }    catch (InterruptedException e) {      throw new RuntimeException(e);    }  } }
Nowadays, we would prefer to use lambda expressions:
 public static void main(String[] args) {    new Thread(() -> odd()).start();    new Thread(() -> even()).start();  }
Or method references:
 public static void main(String[] args) {    new Thread(MultiThreading::odd).start();    new Thread(MultiThreading::even).start();  }
 Also, nowadays we usually wouldn't create a Thread directly, but would prefer to use an ExecutorService (which manages its own threads internally):
   public static void main(String[] args) {    try (var execService = Executors.newFixedThreadPool(2)) {      execService.execute(MultiThreading::even);      execService.execute(MultiThreading::odd);    }  }
That should give you a few options to choose from...

Pretty much all boolean operators and control statements which depend on boolean expressions have the ability to extend the scope of a pattern variable (like your "data" example)  and make it defined, or undefined, under different conditions.  It's hard to memorize all the rules, and best to think of it this way: if a given instanceof expression with pattern variable is true, what other parts of the code would be reachable as the program executes?  Those areas will also have access  to the new pattern variable.  Conversely, any parts of the code that are not reachable if the instanceof is true, those parts do not have access to the pattern variable.  This can have a wide variety of effects - here are some:
 public void test(Object obj) {    if (!(obj instanceof String str)) { //      System.out.println(str); // compile error    } else {      System.out.println(str);    }    if (!(obj instanceof Number n) || n.intValue() < 0) { //      System.out.println(n); // compile error    }    int size = obj instanceof Collection coll ? coll.size() : obj.toString().length(); //    int size2 = obj instanceof Collection coll ? obj.toString().length() : coll.size(); // compile error    if (obj instanceof Iterable iterable) {      Iterator itr = iterable.iterator();      while (itr.hasNext() && itr.next() instanceof String s) {        System.out.println(s);      }    }  }
The full rules are given in JLS 6.3. Scope of a Declaration (particularly under 6.3.1 and 6.3.2) - but they are, frankly, quite hard to decipher.  You're better off thinking through the logic of examples like these, to see why they should (or shouldn't) work.

Yeah, based only on what's quoted here, the original text is wrong, and needs to be changed.  But maybe there's preceding text making clear that we're only talking about local variables or method arguments, at this point.

Campbell Ritchie wrote:my memory might be wrong, but in the days when I tried timing, it took more than 100× as long to concatenate 100,000× than 10,000×. Maybe because you are overwhelming your heap space with char[]s (or byte[]s for all‑ASCII text), containing millions of elements, requiring repeated garbage collection runs.

Yeah, that sounds like a reasonable guess.  I don't see a reason for the algorithm itself to be worse than O(n^2), but if you start getting overwhelmed by GC or other memory issues, that's a different ballgame.

Campbell Ritchie wrote:I remember being told that such code allows the JVM to choose its own optimisation. What Brian Goetz calls “dumb code” is much easier to optimise than if the programmer tries to be too clever.

Yeah.  The trick is figuring out which "dumb code" could be optimized, and which prevents optimization.  Using += for Strings in a loop usually falls in the latter category.

Yeah, with the rules on p. 247, rule 2 implies rule 1.  You don't really need both.  It's nice that they said rule 1 for extra clarity, but that doesn't mean they need to repeat it every time the subject comes up.  Rule 2 is sufficient.

Campbell Ritchie wrote:

Jan Hoppmann wrote:. . . But this doesn't make a difference since Java 8, does it?

Yes, it does make a difference. Repeated concatenation in a loop runs in worse than On²  time complexity.

Hmmm, how would it be worse than O(n^2)?

I would observe that it can run at O(n^2) - depending on the situation.  And this is something to be strenuously avoided.  But there are also plenty of cases where using + is fine - it's no worse, or even faster, than using StringBuilder.  (As you give one example of, later.)

For Jan: the key is to avoid using += on a String inside a loop, any time the number of iterations is not known to be small.  (This also applies to + and = in combination, as in "str = str + foo;" and such.)  The O(n^2) problem occurs when (a)  you are building a string that is growing in size, and (b) you are repeatedly creating a new string containing a copy of all previous content, plus new content.  You could create equivalent O(n^2) problems through mis-use of a StringBuilder, ArrayList or other mutable structures, too - but with those, you have to work harder to misuse them.  While with Strings and += inside a loop, it's very very easy to accidentally create a problem situation.

Campbell Ritchie wrote:

Jan Hoppmann wrote:At compile time, the + will be replaced by calls to a StringBuilder's append method. Or did I get something wrong here?

At runtime, I think, but not certain.

Before Java 9, you could see a StringBuilder (or even Buffer) being used in the compiled bytecode.  Nowadays, it's usually using a MethodHandle returned from one of the StringConcatFactory.makeConcatXxx() methods.  Which probably results in something like using a StringBuilder at runtime, but is more harder for us to see clearly.

Tim Holloway wrote:Which is odd, because I'd expect that to have been scooped up into the internal <init> method. But a diffference that makes no difference is no distance.[/url]

It seems that javap labels the <init> method as constructor.  Slightly misleading, as a constructor in Java translates into a "new" command plus an "<init>" call.  The new just allocates the object, and the <init> does all initialization, whether it was written in an instance initializer, instance field initializer expression, or a constructor.  But labeling <init> as a constructor is at least close to the truth.

Tim Holloway wrote:I wouldn't call the manifest constants in a class file a "pool". More like a list. That is it's a sequence both logical and physical of delimited values.

I understand that it's not the same as the pool of interned strings - but "pool" is the terminology used in the Java Virtual Machine Specification, as previously linked.  We can use different terminology if we want, but simply following the relevant spec seems like a reasonable option...

Tim Holloway wrote:I wouldn't obsess about formatting in samples posted here. we have people of all persuasions here, so there can be no "wrong" option.

Agreed - I think we just want to know what exact effect the OP is trying to achieve.  In any event, IntelliJ does seem to offer options that cover the main possibilities.

That looks like:
 public static void main(String... args) {  }
In any event, we can always edit the post after copying, to modify spacing as needed.

Hmm, I usually just copy with all the leading spaces, like these: