Какие есть методы у Object в java?
Базовый класс в Java, как известно, Object. Какие его методы вы можете назвать? Я нашел такую информацию: https://habrahabr.ru/post/265373/ Object это базовый класс для всех остальных объектов в Java. Каждый класс наследуется от Object. Соответственно все классы наследуют методы класса Object. Методы класса Object:
public final native Class getClass() public native int hashCode() public boolean equals(Object obj) protected native Object clone() throws CloneNotSupportedException public String toString() public final native void notify() public final native void notifyAll() public final native void wait(long timeout) throws InterruptedException public final void wait(long timeout, int nanos) throws InterruptedException public final void wait() throws InterruptedException protected void finalize() throws Throwable
Можно ли информацию чем-то добавить?
Отслеживать
задан 2 июн 2018 в 15:55
141 9 9 бронзовых знаков
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
【完全マスター】オブジェクト指向の考え方や「とは?」が一瞬で丸分かり【Javaプログラミング入門】【未経験エンジニア】【オブジェクト指向 #1】
Методы Вы перечислили все. Добавить можно разве что их краткое описание.
-
protected native Object clone() throws CloneNotSupportedException — возвращает shallow (поверхностную) копию объекта. Для использования обязательно д.б. переопределен в классе. Класс должен имплементить маркерный интерфейс Cloneable, иначе метод выкинет CloneNotSupportedException. Типовая реализация:
public YourClass clone()
public boolean equals(Object obj)
- рефлексивность: a.equals(a) == true
- симметричность: a.equals(b) == b.equals(a)
- транзитивность: if a.equals(b) == true and b.equals(c) == true -> a.equals(c) == true
- консистентность: повторный вызовов a.equals(b) возвращает тот же результат
- a.equals(null) == false
- public int hashCode() — возвращает хэш объекта. Нужен чтобы с объектом могли работать хэш-таблицы (например, HashMap). Всегда должен предопределяться с equals(). Контракт hashCode:
- if a.hashCode() вызывается несколько раз, то результат д.б. одинаков
- в определении hashCode() должны участвовать те же поля, что и в equals()
- if a.equals(b) == true -> a.hashCode() == b.hashCode()
- if a.equals(b) == false -> a.hashCode() != b.hashCode() — это не обязательное требование, но желательное т.к. это повышает эффективность хэш-таблиц
- Вызывается за время существования объекта в памяти только 1 раз.
- В Object не делает ничего (у метода пустое тело).
- В наследуемых классах может быть переопределен, если есть какие-то операции, которые должны быть обязательно выполнены перед уничтожением объекта.
- Метод может сделать объект снова доступным, повесив ссылку на this.
- Использовать явный вызов этого метода — очень плохая практика.
- Переопределять также не нужно практически никогда. Разве что как средство последнего шанса на высвобождение системных ресурсов. Но именно как последнего. Шатно это должно делаться при помощи конструкции try-with-resources.
- Если все-таки нужно переопределить, то надо не забыть в конце метода вызвать super.finalize () в блоке finally.
- В HotSpot VM GC не вызывает finalize() напрямую, а только добавляет объекты в специальный список, вызывая статический метод Finalizer.register(Object). В список добавляются только объекты с переопределенным finalize(). Объект Finalizer представляет собой ссылку на объект, для которого надо вызвать finalize(), и хранит ссылки на следующий и предыдущий Finalizer, формируя двусвязный список. Вызов finalize() происходит в отдельном потоке Finalizer, кот. создается при запуске VM. Исключения, брошенные в finalize(), не обрабатываются потоком-финализатором, т.е. данный стектрейс скорее всего нельзя будет отследить.
- В Java 9 deprecated.
- в качестве альтернативы переопределения finalize() можно использовать фантомную ссылку.
Источник: ru.stackoverflow.com
すべてのJavaプログラマがObjectクラス(型)を知っておくべき理由【Java入門講座】6-2 Objectクラス
Java object что это за программа
Хотя мы можем создать обычный класс, который не является наследником, но фактически все классы наследуются от класса Object. Все остальные классы, даже те, которые мы добавляем в свой проект, являются неявно производными от класса Object. Поэтому все типы и классы могут реализовать те методы, которые определены в классе Object. Рассмотрим эти методы.
toString
Метод toString служит для получения представления данного объекта в виде строки. При попытке вывести строковое представления какого-нибудь объекта, как правило, будет выводиться полное имя класса. Например:
Метод hashCode
Метод hashCode позволяет задать некоторое числовое значение, которое будет соответствовать данному объекту или его хэш-код. По данному числу, например, можно сравнивать объекты.
Например, выведем представление вышеопределенного объекта:
Person tom = new Person(«Tom»); System.out.println(tom.hashCode()); // 2036368507
Но мы можем задать свой алгоритм определения хэш-кода объекта:
Получение типа объекта и метод getClass
Метод getClass позволяет получить тип данного объекта:
Person tom = new Person(«Tom»); System.out.println(tom.getClass()); // class Person
Метод equals
Метод equals сравнивает два объекта на равенство:
Метод equals принимает в качестве параметра объект любого типа, который мы затем приводим к текущему, если они являются объектами одного класса.
Оператор instanceof позволяет выяснить, является ли переданный в качестве параметра объект объектом определенного класса, в данном случае класса Person. Если объекты принадлежат к разным классам, то их сравнение не имеет смысла, и возвращается значение false.
Затем сравниваем по именам. Если они совпадают, возвращаем true, что будет говорить, что объекты равны.
Источник: metanit.com
Зри в корень: java.lang.Object
В Java в вершине иерархии классов лежит класс java.lang.Object. Лежит и лежит, долгое время я им совсем не интересовался.
На собеседованиях часто спрашивают, какие в нем есть методы, поэтому они как-то сами собой выучились. Пришло время посмотреть на этот класс более внимательно. Первый вопрос, который у меня возник, есть ли вообще в исходниках Java класс java.lang.Object. Он же ведь необычный, он вполне может быть жестко зашит в реализацию, как самый верхний.
Однако, такой класс есть и я приведу тут исходники java/lang/Object.java, опустив javadoc, и попытаюсь пролить свет на некоторые моменты связанные с реализацией jvm:
Что бы я хотел отметить в этом коде?
Всего в Object 11 публичных методов, 5 обычных и 6 с нативной реализацией.
Рассмотрим обычные методы, так как их код уже доступен.
По дефолту все объекты сравниваются на равенство ссылок. Мне, кстати, в своем время понравилась шутка про то, что для того, чтобы запутать C++ программистов указатели в Java названы ссылками.
public boolean equals(Object obj)
toString тоже не содержит ничего необычного, кроме разве того, что hashCode() преобразуется в шестнадцатеричную строку. И если бы apangin не написал, что нынче как только нельзя посчитать hashCode, я бы подумал, что раньше Java программисты могли найти свой объект по hashCode, т.к. он был не чем иным как ссылкой. Те 32 битные времена для многих прошли, и теперь даже не знаю, есть ли смысл в toString() выводить hashCode.
public String toString()
Кроме того, что wait относится к примитивам обеспечивающим многопоточность, хочется отметить бесполезность параметра nanos.
В некоторых случаях он просто добавляет одну милисекунду. Интересно, это закладка на будущее или уже есть системы в которых у wait(long timeout, int nanos) другая реализация.
public final void wait(long timeout, int nanos) throws InterruptedException < if (timeout < 0) < throw new IllegalArgumentException(«timeout value is negative»); >if (nanos < 0 || nanos >999999) < throw new IllegalArgumentException( «nanosecond timeout value out of range»); >if (nanos >= 500000 || (nanos != 0 timeout == 0)) < timeout++; >wait(timeout); > public final void wait() throws InterruptedException
Завершает парад обычных методов в java.lang.Object:
protected void finalize() throws Throwable
Этот метод ничего не делает, и есть куча материалов о том, что следует избегать его использования finalize и Finalizer, смысл finalize.
Теперь посмотрим на на java/lang/Object.class Например, мне интересно что в нем указано в качестве супер класса. Находим в установленном jre или jdk rt.jar, распаковываем:
jar -xf rt.jar
И видим, что в super class у него прописаны 00 00, интересно что будет, если руками создать class файл без супер класса.
Я взял Hello.class из моей предыдущей заметки.
Поразился мощи vim редактора. Быстренько нашел байты для super_class. Напомню, они лежат согласно спецификации через 4 байта после окончания constant_pool. Конец constant_pool ищется по тегу строки 00 01 и последовательности не нулевых байтов, когда начинаются нули идут другие разделы constant_pool. Для других class файлов это может быть не так, но в моем случае сработало.
Возвращаемся обратно к бинарному виду:
:%!xxd -r
Сохраняем изменения. Запускаем наше поправленное приложение:
java -cp classes/ hello.App Error: A JNI error has occurred, please check your installation and try again Exception in thread «main» java.lang.ClassFormatError: Invalid superclass index 0 in class file hello/App at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
Ошибка, да еще не какая-нибудь, а выброшенная из нативного метода во время загрузки классов. Пойдем разбираться, за одно может поймем как выбрасывать такие ошибки.
Нам нужны исходники jdk. Я выбрал OpenJDK для исследования. Будем качать их отсюда:
И хранить в Меркурии:
Но на этом не всё.
Надо еще запустить:
./get_source.sh
И подождать. Отлично, исходники скачались и можно искать нашу ошибку. Я делаю это grep-ом:
grep -nr ‘Invalid superclass index’ * hotspot/src/share/vm/classfile/classFileParser.cpp:3095: «Invalid superclass index %u in class file %s», hotspot/src/share/vm/classfile/classFileParser.cpp:3100: «Invalid superclass index %u in class file %s»,
Открываем classFileParser.cpp и там на 3095 строчке:
instanceKlassHandle ClassFileParser::parse_super_class(int super_class_index, TRAPS) < instanceKlassHandle super_klass; if (super_class_index == 0) < check_property(_class_name == vmSymbols::java_lang_Object(), «Invalid superclass index %u in class file %s», super_class_index, CHECK_NULL); >else < check_property(valid_klass_reference_at(super_class_index), «Invalid superclass index %u in class file %s», super_class_index, CHECK_NULL); // The class name should be legal because it is checked when parsing constant pool. // However, make sure it is not an array type. bool is_array = false; if (_cp->tag_at(super_class_index).is_klass()) < super_klass = instanceKlassHandle(THREAD, _cp->resolved_klass_at(super_class_index)); if (_need_verify) is_array = super_klass->oop_is_array(); > else if (_need_verify) < is_array = (_cp->unresolved_klass_at(super_class_index)->byte_at(0) == JVM_SIGNATURE_ARRAY); > if (_need_verify) < guarantee_property(!is_array, «Bad superclass name in class file %s», CHECK_NULL); >> return super_klass; >
Нас интересует вот эта часть:
if (super_class_index == 0)
check_property лежит в заголовочном файле classFileParser.hpp и выглядит так:
inline void check_property(bool property, const char* msg, int index, TRAPS) < if (_need_verify) < guarantee_property(property, msg, index, CHECK); >else < assert_property(property, msg, index, CHECK); >>
Я стал искать где выставляется _need_verify и за что отвечает. Оказалось в classFileParser.cpp есть вот такая строчка:
_need_verify = Verifier::should_verify_for(class_loader(), verify);
verify передается при вызове:
instanceKlassHandle ClassFileParser::parseClassFile(Symbol* name, ClassLoaderData* loader_data, Handle protection_domain, KlassHandle host_klass, GrowableArray* cp_patches, TempNewSymbol
Как же устроен should_verify_for в hotspot/src/share/vm/classfile/verifier.cpp:
bool Verifier::should_verify_for(oop class_loader, bool should_verify_class)
Так как в should_verify_class мы передаем false, смотрим BytecodeVerificationLocal в hotspot/src/share/vm/runtime/arguments.cpp:
// -Xverify > else if (match_option(option, «-Xverify», if (strcmp(tail, «:all») == 0 || strcmp(tail, «») == 0) < FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, true); FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true); >else if (strcmp(tail, «:remote») == 0) < FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false); FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, true); >else if (strcmp(tail, «:none») == 0) < FLAG_SET_CMDLINE(bool, BytecodeVerificationLocal, false); FLAG_SET_CMDLINE(bool, BytecodeVerificationRemote, false); >else if (is_bad_option(option, args->ignoreUnrecognized, «verification»)) < return JNI_EINVAL; >// -Xdebug >
Зарываясь дальше можно найти черную магию с макросами в hotspot/src/share/vm/runtime/globals_extension.hpp:
#define FLAG_SET_CMDLINE(type, name, value) (CommandLineFlagsEx::type##AtPut(FLAG_MEMBER_WITH_TYPE(name,type), (type)(value), Flag::COMMAND_LINE)) class CommandLineFlagsEx : CommandLineFlags < public: static void boolAtPut(CommandLineFlagWithType flag, bool value, Flag::Flags origin); static void intxAtPut(CommandLineFlagWithType flag, intx value, Flag::Flags origin); static void uintxAtPut(CommandLineFlagWithType flag, uintx value, Flag::Flags origin); static void uint64_tAtPut(CommandLineFlagWithType flag, uint64_t value, Flag::Flags origin); static void doubleAtPut(CommandLineFlagWithType flag, double value, Flag::Flags origin); static void ccstrAtPut(CommandLineFlagWithType flag, ccstr value, Flag::Flags origin); static bool is_default(CommandLineFlag flag); static bool is_ergo(CommandLineFlag flag); static bool is_cmdline(CommandLineFlag flag); >;
Но меня это пока не интересует.
Мне надо выяснить значение BytecodeVerificationLocal, в случае когда jvm стартует без параметра -Xverify. Это можно найти в коде, но мне кажется, сейчас не уместным лезть дальнейшие дерби и пора выбираться. Документация в помощь. По дефолту jvm запускается с параметром -Xverify:remote и BytecodeVerificationLocal будет false.
Значит _need_verify тоже false и в check_property вызывается assert_property(property, msg, index, CHECK) с параметрами false, «Invalid superclass index %u in class file %s», 0, CHECK_NULL.
inline void assert_property(bool b, const char* msg, int index, TRAPS) < #ifdef ASSERT if (!b) < ResourceMark rm(THREAD); fatal(err_msg(msg, index, _class_name->as_C_string())); > #endif >
Собственно, здесь и выбрасывается сообщение об ошибке. Теперь посмотрим на fatal(msg), чтобы узнать как это делается.
Хотя, на часть вопроса мы уже ответили. Нельзя сделать classfile в котором для поля super_class будет значение 0 и загружать его с помощью дефолтного ClassLoader.
Итак, fatal определенный в hotspot/src/share/vm/utilities/debug.hpp:
#define fatal(msg) do < report_fatal(__FILE__, __LINE__, msg); BREAKPOINT; >while (0)
void report_fatal(const char* file, int line, const char* message) < report_vm_error(file, line, «fatal error», message); >void report_vm_error(const char* file, int line, const char* error_msg, const char* detail_msg)
Реализация report_and_die() в hotspot/src/share/vm/utilities/vmError.cpp нетривиальна, но из нее следует, что в Java мы уже не возвращаемся и выводим сообщение об ошибке из недр jvm. На этом я хочу переостановить исследование jvm и java.lang.Object.
Выводы
java.lang.Object особый класс, имеющий уникальный class file, в котором в качестве суперкласса не указан ни один класс. Создать такой же класс средствами языка Java нельзя, но также затруднительно, если вообще возможно, сделать это и манипуляциями с байтами class файла. Надеюсь у меня получилось передать часть восхищения, которое я испытывал исследуя исходники jvm. Призываю всех попробовать сделать то же самое.
Источник: habr.com
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Cancel Create
JBook / object / intro.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cannot retrieve contributors at this time
164 lines (103 sloc) 14.2 KB
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents Copy raw contents
Copy raw contents
java.lang.Object и все-все-все
Java — это объектно-ориентированный язык программирования. В ООП мы в основном оперируем понятиями класса и объекта.
Подробнее про ООП можно прочесть здесь.
Ну а если вы ознакомились с основными понятиями, то давайте обсудим главный класс в Java . И этим классом является: java.lang.Object — это корень иерархии всех классов в Java .
Это значит, что каждый класс, включая массивы, является потомком java.lang.Object .
Именно поэтому писать что-то в духе:
public class Test extends Object < // some code >
Абсолютно лишено смысла, Java автоматически добавит ваш класс в иерархию с родителем java.lang.Object .
При этом, даже если вы не создали ни одного конструктора для вашего класса, то Java создаст конструктор по умолчанию. И, с учетом того, что у нас есть родительский класс, этот конструктор будет выглядеть в виде:
public class Test < public Test() < super(); > >
Теперь давайте посмотрим какое влияние на поведение классов оказывает java.lang.Object , являясь родительским классом. Поведение класса — это его интерфейс, методы, которые он предоставляет.
Всего в java.lang.Object представлено 11 public -методов, 6 из которых имеют нативную реализацию. Так как все классы в Java являются потомками java.lang.Object , то все эти методы унаследованы каждым классом в Java . Именно поэтому важно представлять о чем они и какие возможности предоставляют.
Нативная реализация означает, что метод реализован в платформенно-зависимом коде, чаще всего на C/C++ , и скомпонован в виде динамической библиотеки. А значит, эта реализация зависит от JVM .
Возможно, вас сейчас это напугало, но на самом деле достаточно просто понимать, что native означает лишь то, что мы вызываем код, который реализован не на Java .
Почему java.lang.Object не является абстрактным классом
После того, как мы ознакомились с методами java.lang.Object , прочли про ООП , то давайте зададимся вопросом — а почему это не абстрактный класс?
Про абстрактные классы прочитать можно тут.
В целом, на первый взгляд было бы логичным ожидать, что такой класс должен быть абстрактным. Это кажется логичным даже из названия — Object , которое является довольно обобщенным — «объект».
Однако, модификатора abstract у java.lang.Object нет и мы постараемся ответить на вопрос: почему?
Все это только мое личное мнение.
Для ответа на этот вопрос давайте разберемся, а какие плюсы принес бы модификатор asbtract ?
Пусть java.lang.Object был бы абстрактным
Представим себе ситуацию, когда у java.lang.Object существует один или несколько абстрактных методов. Что это дает?
Пометив какие-то методы abstract мы явно потребуем от разработчиков реализации этих методов.
Еще раз взглянем на методы класса java.lang.Object и подумаем: насколько упростит жизнь разработчика, то, что хотя бы один из методов будет необходимо каждый раз реализовывать при написании класса.
Методы wait , notify , finalize , notifyAll и getClass довольно сложны(часть из этих методов являются native -методами) и требовать каждый раз от разработчика их реализации — это дополнительные проблемы и большое количество подводных камней, на которые все будут регулярно натыкаться.
Методы equals , hashCode , clone и toString , в целом, можно было бы сделать абстрактными, но мое мнение по этому поводу: эти методы относятся к отдельным абстракциям. Далеко не каждому классу нужно(да и можно) иметь строковое представление, возможности клонирования, сравнения и предоставления hash -кода.
На мой взгляд, подобные методы логичнее было бы вынести в собственные интерфейсы, например, Hashable , чтобы добавлением интерфейса привнести уже действительно необходимый функционал.
Но объявлять эти методы абстрактными — это уже опять делать шаг в сторону усложнения написания кода, ведь требовать от класса, которому не нужно уметь представлять себя в строковом виде определение toString — неразумно и глупо. В таком случае разработчик будет каждый раз писать какой-то «фейковый» toString , не имеющий ценности и необходимости.
Поэтому, на мой взгляд, оптимальное решение было то, какое выбрали в текущей реализации.
В итоге, как мы сейчас увидели, делать методы класса java.lang.Object абстрактными неразумно, так как это только усложнит написание кода и не дает никаких преимуществ.
java.lang.Object как абстрактный класс, без абстрактных методов
Теперь предположим, что класс java.lang.Object является абстрактным, но не имеет абстрактных методов.
С точки зрения наименований — довольно логично было бы, чтобы такой класс был абстрактным.
Ведь сложно найти что-то, что полностью подходило под описание «объект». Объект — это всегда что-то абстрактное. Объектами являются и лампа, и машина, и дом.
Поэтому, с точки зрения дизайна языка, было бы правильней чтобы java.lang.Object был абстрактным.
Однако, возможность создания некоторого абстрактного объекта может быть полезна, а вот запрет на такое действие не дает никакой выгоды, кроме стилистической, так как это больше вопрос дизайна.
Разберем теперь пользу от возможности создания экземпляра класса java.lang.Object .
Экземпляр класса java.lang.Object часто используется для synchronized операций. Так как в Java можно занять монитор объекта — сделать синхронизацию на нем.
И часто для таких целей пишут что-то в виде:
public class Example < private final Object lock = new Object(); public void doSomething() < synchronized (lock) < // do possibly dangerous stuff > > >
Иногда полезно иметь возможность создать некоторый пустой объект, без состояния, для подобных целей.
С другой стороны, для возможности использовать synchronized можно было бы сделать специальный объект, например, java.lang.Lock или что-то подобное.
Чтобы тип поля явно говорил нам — для чего это поле будет использоваться, ведь когда вы видите поле с типом Object — это по началу вводит в ступор, особенно, если название переменной не слишком понятно.
Иногда бывает также удобно иметь возможность создать объект-пустышку, так называемый Placeholder , без состояния, например, как реализован java.util.HashSet .
Это реализация java.util.Map , где ключами являются элементы множества, а значениями будут объекты-пустышки.
И опять же, можно было бы ожидать, что для таких целей будет именно так и названный класс, что-то типа java.lang.Placeholder , являющийся наследником нашего абстрактного java.lang.Object .
Исходя из вышесказанного можно сделать вывод, что объекты-пустышки иногда бывают полезны и применимы в реальных задачах. И поэтому было бы полезно иметь возможность ими пользоваться, это вполне допустимо и с точки зрения дизайна языка.
Также, возможно, есть еще какие-то применения java.lang.Object , например в механизме Reflection , в безопасности и так далее.
Поэтому, я считаю, что java.lang.Object может быть не абстрактным, почему нет? И лично я не стал бы относить это к минусам дизайна языка.
А вот методы equals , hashCode , clone и toString , я считаю, должны быть в отдельных интерфейсах, так, чтобы это поведение я мог подмешивать к своему классу тогда, когда мне это было бы надо.
Но что сделано — то сделано.
Каждый класс в Java неявно является наследником java.lang.Object , благодаря чему каждый класс имеет методы equals , hashCode , toString и т.д.
Помните, что оператор == сравнивает объекты по ссылкам, поэтому, если вы хотите сравнивать объекты по внутреннему состоянию, то необходимо переопределить equals . Вместе с equals обязательно переопределять еще и hashCode , так как эти методы тесно связаны друг с другом.
Также хорошим тоном является переопределение toString , так как текстовое представление объекта помогает при отладке и печати объекта в консоль или лог-файл. Следите за тем, чтобы в toString не попадала конфиденциальная информация, пароли и т.д. Старайтесь не завязывать логику программы на результат работы toString .
Никогда не используйте finalize , ввиду непредсказуемости его работы, в частности момента вызова и исполнение метода.
Будьте аккуратнее с методом clone , так как при таком клонировании объекта встречается большое количество подводных камней, не вызывается конструктор класса и т.д. Предпочитайте конструктор копирования или статические методы-фабрики.
Источник: github.com
Класс Object и его методы
В Java определен один специальный класс, называемый Object. Все остальные классы являются подклассами, производными от этого класса, даже если в объявлении это явно не указано. В классе Object определен ряд методов, которые доступны всем классам языка Java.
Методы класса Object в Java:
- protected Object clone() — создает новый объект, не отличающийся от клонируемого.
- public boolean equals(Object obj) — определяет, равен ли один объект другому.
- protected void finalize() — вызывается перед удалением неиспользуемого объекта.
- public final Class getClass() — получает класс объекта во время выполнения.
- public int hashCode() — возвращает хэш-код, связанный с вызывающим объектом.
- public final void notify() — возобновляет исполнение потока, ожидающего вызывающего объекта.
- public final void notifyAll() — возобновляет исполнение всех потоков, ожидающих вызывающего объекта.
- public String toString() — возвращает символьную строку, описывающую объект.
- public final void wait() — ожидает другого потока исполнения.
- public final void wait(long timeout) — ожидает другого потока исполнения.
- public final void wait(long timeout, int nanos) — ожидает другого потока исполнения.
- Метод equals()
- Метод toString()
- Модификатор native
- Слайды
Trustpilot
Комментарии
Зарегистрируйтесь или войдите, чтобы иметь возможность оставить комментарий.
Источник: www.examclouds.com