That would be a breaking change.

yeah.. I agree :) thanks for your comment.

First, those methods exist so you don't have to suppress the unchecked exception from using varargs on a generic type for typical 1-9 argument cases. Second, if items is long, you have two loops over it instead of one. Third, the proposed method doesn't tell which element was null. Fourth, that just(...) would cause ambiguity problems with the other existing ones; this is why fromArray has been introduced.

good comment! Thanks :)

@ggikko @akarnokd Hi I'm an Android developer and are learning RxJava now.
I have the same question and I think neither of the last 2 reasons is reasonable.
3.We can change the proposed code like this:

    public static <T> Observable<T> just(T... items) {
        int count = items == null ? 0 : items.length;
        for (int i = 0; i < count; i++) {
            ObjectHelper.requireNonNull(items[i], "The items[" + i + "] is null");
        }
        return fromArray(items);
    }

4.The just methods given in Observable.java have the same problem too.

3: now you have string concatenation overhead as well. When looking at an API, one usually doesn't see the evolution of it. Many RxJava 2 API design choices were established from the experience with the initial Java 8 target where ambiguities were very common. Plus, the new version allowed a design of an API where all operators and overloads have been known upfront and the naming and distribution of them could be done more consistently (instead of the tagged-on feeling of many 1.x operators).

@ggikko @akarnokd
So this is a historical issue? Will you fix it this year?
Anyway I still fell love with it after several days learning recently and made a RxJava example here:

https://github.com/TommyLemon/APIJSON-Android-RxJava

@akarnokd thank you~