А вы крутой Java-программист? Тест на проверку знаний языка Java

1 / 8

Начнём с простого: что такое Java?

Не верно!

Это язык программирования


Не верно!

Это язык программирования


Не верно!

Это язык программирования


Верно!

Не верно!

Это язык программирования


Что будет в результате выполнения операции?

2 + 2 == 5 && 12 / 4 == 3 || 2 == 5 % 3

Верно!

Конъюнкция (&&) приоритетнее, чем дизъюнкция (||). То есть к «логическому И» в данном случае относятся два аргумента: 2 + 2 == 5 и 12 / 4 == 3. Левый возвращает false, значит, второй не выполняется. Результат этой операции будет использован в качестве операнда в «логическом ИЛИ». Это выражение можно переписать так: (2 + 2 == 5 && 14 / 4 == 3) || 2 == 5 % 3. Если вычислить все выражения, получаем: (false && true) || true. Далее false || true. Результат: true.


Не верно!

Конъюнкция (&&) приоритетнее, чем дизъюнкция (||). То есть к «логическому И» в данном случае относятся два аргумента: 2 + 2 == 5 и 12 / 4 == 3. Левый возвращает false, значит, второй не выполняется. Результат этой операции будет использован в качестве операнда в «логическом ИЛИ». Это выражение можно переписать так: (2 + 2 == 5 && 14 / 4 == 3) || 2 == 5 % 3. Если вычислить все выражения, получаем: (false && true) || true. Далее false || true. Результат: true.


Не верно!

Конъюнкция (&&) приоритетнее, чем дизъюнкция (||). То есть к «логическому И» в данном случае относятся два аргумента: 2 + 2 == 5 и 12 / 4 == 3. Левый возвращает false, значит, второй не выполняется. Результат этой операции будет использован в качестве операнда в «логическом ИЛИ». Это выражение можно переписать так: (2 + 2 == 5 && 14 / 4 == 3) || 2 == 5 % 3. Если вычислить все выражения, получаем: (false && true) || true. Далее false || true. Результат: true.


Не верно!

Конъюнкция (&&) приоритетнее, чем дизъюнкция (||). То есть к «логическому И» в данном случае относятся два аргумента: 2 + 2 == 5 и 12 / 4 == 3. Левый возвращает false, значит, второй не выполняется. Результат этой операции будет использован в качестве операнда в «логическом ИЛИ». Это выражение можно переписать так: (2 + 2 == 5 && 14 / 4 == 3) || 2 == 5 % 3. Если вычислить все выражения, получаем: (false && true) || true. Далее false || true. Результат: true.


Что будет, если скомпилировать и запустить этот код?

 
public class Test {
    public static void main(String[] args) {
        User user = new User();
        user.setReferalId(112L);
    }

    static class User {
        long id;

        User referal = new User();

        public void setReferalId(long referalId) {
            this.referal.id = referalId;
        }
    }
}
Не верно!

В данном коде всё отлично скомпилируется и запустится. Но из-за инициализации поля referal мы получим бесконечную глубину вложенности данных. Каждый раз при создании пользователя будет создаваться пользователь и т. д. В итоге получим StackOverflowError.


Не верно!

В данном коде всё отлично скомпилируется и запустится. Но из-за инициализации поля referal мы получим бесконечную глубину вложенности данных. Каждый раз при создании пользователя будет создаваться пользователь и т. д. В итоге получим StackOverflowError.


Верно!

В данном коде всё отлично скомпилируется и запустится. Но из-за инициализации поля referal мы получим бесконечную глубину вложенности данных. Каждый раз при создании пользователя будет создаваться пользователь и т. д. В итоге получим StackOverflowError.


Не верно!

В данном коде всё отлично скомпилируется и запустится. Но из-за инициализации поля referal мы получим бесконечную глубину вложенности данных. Каждый раз при создании пользователя будет создаваться пользователь и т. д. В итоге получим StackOverflowError.


Что будет, если скомпилировать и запустить этот код?

 
public class Test {

    interface I {
        String generate();

        default void print(String value) {
            System.out.println(Optional.ofNullable(value).orElseGet(this::generate));
        }
    }

    public static void main(String[] args) {
        ((I) () -> "Hello!").print(null);
    }
}
Не верно!

Может показаться, что в качестве реализации такого интерфейса нельзя использовать лямбду, но так как второй метод имеет модификатор default, такое поведение допустимо. В данном случае код скомпилируется и выполнится успешно, в консоль будет выведено «Hello!»


Не верно!

Может показаться, что в качестве реализации такого интерфейса нельзя использовать лямбду, но так как второй метод имеет модификатор default, такое поведение допустимо. В данном случае код скомпилируется и выполнится успешно, в консоль будет выведено «Hello!»


Не верно!

Может показаться, что в качестве реализации такого интерфейса нельзя использовать лямбду, но так как второй метод имеет модификатор default, такое поведение допустимо. В данном случае код скомпилируется и выполнится успешно, в консоль будет выведено «Hello!».


Верно!

Может показаться, что в качестве реализации такого интерфейса нельзя использовать лямбду, но так как второй метод имеет модификатор default, такое поведение допустимо. В данном случае код скомпилируется и выполнится успешно, в консоль будет выведено «Hello!».


Что будет, если скомпилировать и выполнить код:

 
class Nullable {
    public static String hello() {
        return "Hello!";
    }
}

public class Test {
    public static void main(String[] args) {
        Nullable nullable = null;
        System.out.println(nullable.hello());
    }
}
Верно!

Так как мы обращаемся к статичному полю, не имеет значения, была переменная проинициализирована объектом или она ссылается на null. Статичные поля и методы принадлежат классу, а не конкретному его объекту.


Не верно!

Так как мы обращаемся к статичному полю, не имеет значения, была переменная проинициализирована объектом или она ссылается на null. Статичные поля и методы принадлежат классу, а не конкретному его объекту.


Не верно!

Так как мы обращаемся к статичному полю, не имеет значения, была переменная проинициализирована объектом или она ссылается на null. Статичные поля и методы принадлежат классу, а не конкретному его объекту.


Не верно!

Так как мы обращаемся к статичному полю, не имеет значения, была переменная проинициализирована объектом или она ссылается на null. Статичные поля и методы принадлежат классу, а не конкретному его объекту.


Каким будет результат выполнения кода:

 
List list = new ArrayList<>();
list.add("One");
list.add("Two");
list.add("Three");

list.stream().forEach(s -> {
   System.out.println(s);
   list.add(s + "New");
});
Не верно!

Ошибок во время компиляции не будет. А вот во время выполнения очень даже. Коллекции, которые используются в стримах, не могут быть модифицированы. Но из-за того, что в данном случае используется Spliterator, а не Iterator, исключение генерируется не сразу. Метод, который используется в стримах для итерирования, проверяет размер массива в самом начале, затем итерации выполняются до тех пор, пока порядковый номер элемента не станет соответствовать сохранённому в начале значению. В данном случае мы получим ConcurrentModificationException после третьей итерации.


Не верно!

Ошибок во время компиляции не будет. А вот во время выполнения очень даже. Коллекции, которые используются в стримах, не могут быть модифицированы. Но из-за того, что в данном случае используется Spliterator, а не Iterator, исключение генерируется не сразу. Метод, который используется в стримах для итерирования, проверяет размер массива в самом начале, затем итерации выполняются до тех пор, пока порядковый номер элемента не станет соответствовать сохранённому в начале значению. В данном случае мы получим ConcurrentModificationException после третьей итерации.


Верно!

Ошибок во время компиляции не будет. А вот во время выполнения очень даже. Коллекции, которые используются в стримах, не могут быть модифицированы. Но из-за того, что в данном случае используется Spliterator, а не Iterator, исключение генерируется не сразу. Метод, который используется в стримах для итерирования, проверяет размер массива в самом начале, затем итерации выполняются до тех пор, пока порядковый номер элемента не станет соответствовать сохранённому в начале значению. В данном случае мы получим ConcurrentModificationException после третьей итерации.


Не верно!

Ошибок во время компиляции не будет. А вот во время выполнения очень даже. Коллекции, которые используются в стримах, не могут быть модифицированы. Но из-за того, что в данном случае используется Spliterator, а не Iterator, исключение генерируется не сразу. Метод, который используется в стримах для итерирования, проверяет размер массива в самом начале, затем итерации выполняются до тех пор, пока порядковый номер элемента не станет соответствовать сохранённому в начале значению. В данном случае мы получим ConcurrentModificationException после третьей итерации.


Каким будет результат выполнения кода:

 
String[] names = {"Java", "Kotlin", "Java"};
String name = "Java";
Predicate predicate = name::equals;
Stream.of(names).filter(predicate).count();
name = "Kotlin";
Stream.of(names).filter(predicate).count();
Не верно!

Проблем с компиляцией тут не будет, но, так как в данном случае используется не лямбда, а ссылка на конкретный метод конкретного объекта, даже если мы изменим значение в переменной name, ссылка на метод equals будет вести на всё тот же объект строки со значением «Java». В итоге мы оба раза получим значение «2».


Не верно!

Проблем с компиляцией тут не будет, но, так как в данном случае используется не лямбда, а ссылка на конкретный метод конкретного объекта, даже если мы изменим значение в переменной name, ссылка на метод equals будет вести на всё тот же объект строки со значением «Java». В итоге мы оба раза получим значение «2».


Не верно!

Проблем с компиляцией тут не будет, но, так как в данном случае используется не лямбда, а ссылка на конкретный метод конкретного объекта, даже если мы изменим значение в переменной name, ссылка на метод equals будет вести на всё тот же объект строки со значением «Java». В итоге мы оба раза получим значение «2».


Верно!

Проблем с компиляцией тут не будет, но, так как в данном случае используется не лямбда, а ссылка на конкретный метод конкретного объекта, даже если мы изменим значение в переменной name, ссылка на метод equals будет вести на всё тот же объект строки со значением «Java». В итоге мы оба раза получим значение «2».


Что произойдет после вызова метода test()?

 
interface I { void print(); }

public I create() {
   return () -> { System.out.println("Hello!"); };
}

private I i = this::create;

public void test() {
   i.print();
}
Не верно!

Несмотря на то, что метод create() возвращает значение, а метод в интерфейсе — void, всё равно можно использовать его как реализацию интерфейса I. Но во время вызова метода print() будет вызван сам метод create(), который создаст новую лямбду и вернёт её. Сама лямбда уже нигде не вызывается, значит и в консоль ничего выведено не будет.


Не верно!

Несмотря на то, что метод create() возвращает значение, а метод в интерфейсе — void, всё равно можно использовать его как реализацию интерфейса I. Но во время вызова метода print() будет вызван сам метод create(), который создаст новую лямбду и вернёт её. Сама лямбда уже нигде не вызывается, значит и в консоль ничего выведено не будет.


Верно!

Несмотря на то, что метод create() возвращает значение, а метод в интерфейсе — void, всё равно можно использовать его как реализацию интерфейса I. Но во время вызова метода print() будет вызван сам метод create(), который создаст новую лямбду и вернёт её. Сама лямбда уже нигде не вызывается, значит и в консоль ничего выведено не будет.


Не верно!

Несмотря на то, что метод create() возвращает значение, а метод в интерфейсе — void, всё равно можно использовать его как реализацию интерфейса I. Но во время вызова метода print() будет вызван сам метод create(), который создаст новую лямбду и вернёт её. Сама лямбда уже нигде не вызывается, значит и в консоль ничего выведено не будет.


Далее
0 из 8

Поздравляем с прохождением теста! А теперь предлагаем почитать статьи по программированию на Python на нашем сайте PythonTurbo!

Интересно, хочу посмотреть