Campbell Ritchie

Familiarity with a technique is probably a good reason for trying it.
But, I suggest you start with a description of what you want to do. Consider what you will do if prices change, or new bars open.
Consider whether it will look better if you use raw code to achive your ends, or the tools you mentioned. Whichever you do, make sure you have a good explanation for it, so you can answer, “Why did you use XYZ?”

Welcome to the Ranch

Why have you decided those implementation details at such an early stage of the process?

Martin Gerard wrote:I think that  using below would cause the evaluation to always be true. . . .

Have you tried a score of 101?

I am afraid that latest design still looks wrong. It is rather like using instanceof. You could simply and correctly have got those Lists with the correct type by overloading that method to take a String or a boolean as arguments.

Please don't quote the whole of a preceding post, only the relevant parts. Unnecessary quotes add no information and are liable to removal without warning.

Tapio Niemela wrote:. . . if it is "misused" by the client (expecting giveMeNumber to return Long). Of course, such method should not exist in the first place, to be "misused" by the client.

That method returns an Integer object irrespective of the generics and its declared return type, and is therefore written incorrectly. The client is not misusing that method at all. All the blame should fall on line 7.

. . . I'm grateful . . .

That's a pleasure

That's a pleasure

Stephan points out that casts should be rare. The following is a situation where a cast is permissible, indeed probably necessary.
Imagine you want a parametrised type with an array of that type:-class Foo<T> {   private T[] values;   // ... }You can initialise that array with a method:-class Foo<T> {   private T[] values;   Foo()   {      //...      values = getNewArray(10);   }   private T[] getNewArray(int size)   {      return ???; // “new T[size]” won't compile :-(   }   // ... }You can't initialise anything as T[], so what can you do? You declare it as T[], initialise it as Object[], and cast it when it only contains nulls, remembering that a null has notno type of its own and can therefore be cast to any type:-class Foo<T> {   private T[] values;   Foo()   {      //...      values = getNewArray(10);   }   private T[] getNewArray(int size)   {      return (T[]) new Object[size];   }   // ... }That code can be compiled, but you will get a warning. You can now suppress the warning. Note that the method in line 11 cannot be static because T is an attribute of the object, not the class. Note also that you cannot apply the annotation to a statement, but you can apply it to a declaration. And remember a comment to explain why you are using it.class Foo<T> {   private T[] values;   Foo()   {      //...      values = getNewArray(10);   }   private T[] getNewArray(int size)   {      @SuppressWarnings("unchecked")      /*       * At this stage the array only contains nulls and       * there is no risk of the cast failing.       */      T[] array = (T[]) new Object[size];      return array;   }   // ... }[edit]Spelling correction

Afraid that doesn't look correct. There is only any point in declaring a method as generic if you pass it an argument that can match that generic‑ity. That is what Stephan means about generic types being determined by the method's caller. Remember that actual type parameters are erased at runtime. I think because you didn't supply an argument, the formal type parameter will be used, and that will degenerate to its upper bound. So it is no different from writing,void test() {    Number z = giveMeNumber();//OK!    Long x = giveMeNumber();//CRASH at runtime! } Number giveMeNumber() {    return (Number)Integer.valueOf(1); }And you can change that to the following with no change to its semantics, since the implementation detail of line 7 can be ignored:-void test() {    Number z = giveMeNumber();//OK!    Long x = giveMeNumber();//CRASH at runtime! } Number giveMeNumber() {    return (Number)1; // Use boxing conversion }Because a cast to a reference type doesn't change the object's runtime type, that cast has no effect, and that can be reduced to,void test() {    Number z = giveMeNumber();//OK!    Long x = giveMeNumber();//CRASH at runtime! } Number giveMeNumber() {    return 1; // Use boxing conversion }I am surprised that you didn't anticipate the exception being thrown. It should be obvious in advance that the assignment to a Long will fail. I am also a bit surprised that you got your line 3 to compile. You do however get a warning about line 7 at compile time.
Look in Essential Java by Joshua Bloch (in 3rd edition page 123, in 2nd edition page 116), where he tells you that you can be sure your types are all correct and there is no risk of an incorrect assignment if the code compiles without warnings.

The example you have shown is probably not an appropriate candidate for using generics in the first place. I also think it doesn't give us the information to give you the help you want.
[edit]Minor spelling correction

Stephan van Hulst wrote:I think those commands are wrong Campbell. . . .

Of course they are. sorry

Tapio Niemela wrote:. . . rather complicated case which I oversimplified with my example . . .

No, you changed it completely with that generic method.

Use E rather than T when using Lists. But that is only a convention.
You should not need a cast anywhere. That is the whole idea behind generics. I am surprised you got lines 4 and 5 to compile. What you should do is to pass the Lists as arguments to that method. Then the compiler will be able to infer the type of element in the List and the method will use the specific type.public static <E extends Number> List<E> calc(List<E> list){    List<E> numbers = new ArrayList<>();    numbers.addAll(list);    return numbers; }If you do that, you will find that the casts become unnecessary, and will at best produce warnings.
The cast to List<String> is guaranteed to fail, so the compiler cannot allow it.void foo(List<Number> list) {   List<String> list = (List<String>)numbers; // Won't compile }import java.util.ArrayList; import java.util.List; class Foo {    public static void main(String... args)    {        System.out.printf("ints:  %s%nlongs: %s%n",                ints(args), longs(args));    }    private static List<Integer> ints(String... args)    {        /* Note use of anonymous class here */        return new ArrayList<Integer>()        {            /* “instance” initialiser block */            {                for (String s : args)                {                    this.add(Integer.valueOf(s));                }            }        };    }    private static List<Long> longs(String... args)    {        return new ArrayList<Long>()        {            {                for (String s : args)                {                    this.add(Long.valueOf(s));                }            }        };    }    private static <E extends Number> List<E> collect(List<E> list)    {        return new ArrayList<>()        {            {                this.addAll(list);            }        };    } }

Welcome to the Ranch (again)

vincenzo leone wrote:. . . What if I want to save a file in another folder and make it run using the terminal? . . .

Use the CLASSPATH. Look at the the options for the javac and java tools. Link 1 Link 2 (slightly old versions)./* Assumes the file is in the ~/java directory */ javac -cp /home/vicenzo/java/HelloWorld.java java -cp /home/vicenzo/java/HelloWorld

Junilu Lacar wrote:. . . Kotlin, where x in 1..max  is means 1 <= x <= max . . .

Hehner, whom I mentioned last night, is firmly of the iinclusive...jexclusive school, and you can see the designers of IntStream#range() thought the same way. Fortunately, they named the parameters in the documentation to make that easier to understand.
I have seen too many people misunderstand the range of results from this Random method or this one. But they would have got it right if they had read the links properly

Mike Simmons wrote:. . . .takeWhile(n -> n < max). . .

I like takeWhile() and its brother, both methods missed out when Streams appeared in Java8. I was pleased to see them, added as necessary enhancements in Java9. They allow us to start or stop reading from a sentinel value,, and both have counterparts in the other kinds of Stream.