добрый день!,

если объявить метод foo вот так :

Код

static void foo(final Object obj){ // some code }

то что это мне даст?: семантическое подчеркивание что в коде не будет
такого оператора

Код

obj = new Object();

хотя если и будет, то после выхода из метода я всё равно получу указатель на
первоначальный объект (ведь в метод ссылка передаётся по значению)


я посмотрел конструкции в которых данный модификатор присутствует в исходниках jdk

таковые присутствуют

вот например один из конструкторов класса JTable:

Код

public JTable(final Object[][] rowData, final Object[] columnNames) {

зачем тут final? а документация javadoc эти модификаторы не показывает
вот строка из api
JTable(Object[][] rowData, Object[] columnNames)


у кого-нибудь есть мысли?
спасибо

По-моему, это означает, что передаваемый объект не может изменяться. Константен в пределах данного метода.
Добавлено @ 15:31
Вообще, это ключевое слово имеет разную семантику при разных применениях.
1. Если мы объявлем класс, как final, то от него нельзя наследовать.
1. Если мы объявлем метод, как final, то его нельзя переопределять.
1. Если мы объявлем объект, как final, то его нельзя изменять. Згачение присваивается при инициализации, или при передаче в метод, как в данном случае.

Надеюсь, ничего не напутал.

Код

public class Dummy{     public static void main(String[] args){         Data d = new Data(0);         foo(d);         assert d.i == 111;     }     static void foo(final Data d){         d.i = 111;     }     static class Data{         int i;         Data(int i){             this.i = i;         };     } }

здесь показано, что состояние объекта является изменяемым

вопрос про final в контексте объявления формальных параметров метода - есть ли в этом действительно польза (кроме удлинения кода), может это как-то связано с многозадачностью, во всяком случае классы System, Thread, ClassLoader содержат такие объявления методов

Да, проверил, действительно, действие модификатора распространяется только на сам объект, а не на его поля. То ли так и должно быть, то ли я чего-то не понимаю.

Цитата(jer1 @ 13.4.2005, 15:45)

есть ли в этом действительно польза (кроме удлинения кода)

Думаю, польза от этого есть, хотя на практике еще не разу не применял. Знаю, что только final-методы могут быть inline => могут дать нам выигрыш в скорости.

Что такое assert?

Seit dem JDK 1.4 gibt es in Java eine assert-Anweisung. Diese, ursprünglich schon für die erste JDK-Version vorgesehene, dann aber aus Zeitgründen zurückgestellte Anweisung wird C- oder C++-Programmierern wohlbekannt sein. Sie dient dazu, an einer bestimmten Stelle im Programmablauf einen logischen Ausdruck zu plazieren, von dem der Programmierer annimmt, daß er stets wahr ist. Ist das der Fall, fährt das Programm mit der nächsten Anweisung fort, andernfalls wird eine Ausnahme des Typs AssertionError ausgelöst. Ein solcher Ausdruck wird auch als Invariante bezeichnet, denn er bleibt unverändert true, solange das Programm korrekt funktioniert.
JDK1.1-1.4



Assertions, wie assert-Anweisungen vereinfachend genannt werden, dienen also dazu, bestimmte Annahmen über den Zustand des Programmes zu verifizieren und sicherzustellen, daß diese eingehalten werden. Soll im Programm beispielsweise überprüft werden, ob eine Variable x nicht-negativ ist, könnte dazu die folgende assert-Anweisung verwendet werden:

assert x >= 0;

Das Programm überprüft die Bedingung und fährt fort, wenn sie erfüllt ist. Andernfalls wird eine Ausnahme ausgelöst. Natürlich hätte derselbe Test auch mit Hilfe einer einfachen if-Anweisung ausgeführt werden können. Die assert-Anweisung hat ihr gegenüber jedoch einige Vorteile:

Der Programmcode ist kürzer.
Auf den ersten Blick ist zu erkennen, daß es sich um einen Korrektheits-Check handelt und nicht um eine Verzweigung zur Steuerung des Programmablaufs.
Assertions lassen sich zur Laufzeit wahlweise an- oder ausschalten. Im Gegensatz zu einer einfachen if-Anweisung verursachen sie praktisch keine Verschlechterung des Laufzeitverhaltens, wenn sie deaktiviert sind.
Der im Syntaxdiagramm angegebene ausdruck1 muß immer vom Typ boolean sein, andernfalls gibt es einen Compilerfehler. Fehlt ausdruck2 (er darf von beliebigem Typ sein), wird im Falle des Nichterfülltseins der Bedingung ein AssertionError mit einer leeren Fehlermeldung erzeugt. Wurde ausdruck2 dagegen angegeben, wird er im Fehlerfall an den Konstruktor von AssertionError übergeben und dient als Meldungstext für das Fehlerobjekt.


Добавлено @ 16:56
Извеняюсь сейчас переведу.

когда ты пишешь для себя, т.е контролируешь корректность передачу параметров, их обработку и т.д, то как правило используются assert. Т.е исходим из того, что алгоритм верен - ты просто убеждаешься (при помощи логического утверждения) в корректности каких-то элементов программы

сравнение с runtime-эксепшинами

Код

public void calculate(Item item){ if (item == null) throw new IllegalArgumentException("низя null");  //process code }

Код

private void calculate(Item item){ assert item == null: "низя null";  //process code }

во втором случае ты сам ответственен за то чтобы прайвет метод был вызван с корректным параметром, если этого не будет - алгоритм не верен
при помощи assert ты об этом узнаешь и исправишь (при запуске программы утверждения можно включать/отключить даже селективно для разных пакетов, классов)

ну а в первом случае клиент должен позаботиться об корректности параметра (javadoc метода об этом должен упоминать)



см. также
утверждения (assert)

для динамического мониторинга программы java logging api

kashka
Да, так тяжеловато

Это сообщение отредактировал(а) Lamer George - 13.4.2005, 17:02

команда assert ставиться перед логическим выражением которое по предположению программиста true. Если это действительно так программа продолжает работу, со следующей комманды, в противном случае мы получаем AssertionError.
Добавлено @ 17:04
теперь дальше (тоже немного труднавато подходящие слова находить)
Добавлено @ 17:05
Хотя jer1 уже все написал.
Добавлено @ 17:07
Могу еще преимущества assert перед if написать, если интересно.

jer1, kashka
Спасибо за объяснения.

Добавлено @ 17:16

Цитата(kashka @ 13.4.2005, 17:03)

Могу еще преимущества assert перед if написать, если интересно

Буду признателен.

Для чего нужен final
:

Код

public class A  {        public static void main(String[] a)     {         Integer i = new Integer(9);         doMethod(i);     }          public static void doMethod(final Integer i)     {         i = new Integer(9);     } }

Запуск дает:

Цитата

A.java:13: final parameter i may not be assigned         i = new Integer(9);

Цитата

вопрос про final в контексте объявления формальных параметров метода - есть ли в этом действительно польза (кроме удлинения кода), может это как-то связано с многозадачностью, во всяком случае классы System, Thread, ClassLoader содержат такие объявления методов

Есть, случае с классами и методами. Например, есli метод нельзя перегрузить, вызов егo статичски связан, а нe динамически.

Цитата

Есть, случае с классами и методами. Например, есli метод нельзя перегрузить, вызов егo статичски связан, а нe динамически.

а когда метод нельзя перегрузить, пример!)

Код

class A {       public final void B()         {} } class C extends A {       public void B()  //-- ошибка времени компиляции       {}  }

Цитата(Domestic @ 13.4.2005, 18:41)

Например, есli метод нельзя перегрузить, вызов егo статичски связан, а нe динамически.

Вот это и дает возможность компилятору встроить метод как инлайн-функцию, если, конечно, он сочтет это целесообразным.

а в таком примере модиф. final что-то даёт?

Код

public void b(final int a){} // контекст: параметры метода

По-моему, никакой особой оптимизации это не даст, я думаю проверка идет на уровне компилятора.
Это просто удобно - видно что аргумент не меняется; кроме того, локальные классы могут обращаться к переменным в локальном скопе только если те final.

Цитата(jer1 @ 14.4.2005, 09:40)

а в таком примере модиф. final что-то даёт?

Навряд ли, ведь для простого типа будет передано значение, а не ссылка.

Цитата(Lamer @ 13.4.2005, 16:18)

Да, проверил, действительно, действие модификатора распространяется только на сам объект, а не на его поля. То ли так и должно быть, то ли я чего-то не понимаю.

Be aware that declaring an object attribute final does not prevent it from being changed. In fact, the final only applies to the reference to the object and not the object itself.

Логично. Неизменяемой объявляется ссылка, а не объект.

Мало того если массив объявим как final, то его элементы менять можно. Короче final запрещает операцию присваивания проводить больше (и меньше) одного раза. В случае с параметром метода - если есть final, мы можем быть уверены, что в любом месте этого метода мы работаем именно с тем объектом, который был передан в качестве параметра.

Массив ведь - тоже объект, и когда мы передаем массив, то передаем неизменяемую ссылку на него.

Короче есть объекты видимые только в методе во время его выполнения. Это объекты, которые объявляются в этом методе и параметры метода. Если мы в этом же методе делаем иннер-класс, который обращается к отмеченным выше объектам - эти объекты должны быть объявлены как final.
Попробуйте из примера ниже убрать final из сигнатуры метода - не скомпилируется:

Код

// file Inner.java public class Inner {     public static void main( String[] args)     {         new Inner().print( "Hello from final!!!");     }     void print( final String s)     {         new Object()         {             {                 System.out.println( s);             }         };     } }

Хотя Domestic Cat об этом уже написал

Это сообщение отредактировал(а) Zandr - 22.4.2005, 13:00

Кстати это свойство final можно использовать для реализации паттерна Singleton:

Код

public class MySingleton {     private static final MySingleton INSTANCE = new MySingleton();     private MySingleton() {         // ...     }     public static getInstance() {         return INSTANCE;     }     // Другой код }

Зато так мы будем точно знать, что существует один и только один объект класса MySingleton.

simanyay
Здесь, в принципе, можно и не указывать final. Мы ведь все равно не сможем создать еще один объект MySingleton - у него же нет неприватного конструктора.
Но хуже, конечно, не будет.

Народ, всё проще. Эккель пишет, что final - это просто напросто замена вызова метода его телом на уровне компиляции. т.е. это указание на то, что методом это считать нужног только в рамках исходника для понятности кода, а реально - это не метод никакой, а просто кусок другого метода в тех местах, где в коде он вызывается.

Даёт это экономию при быстродействии программы, поскольку операция вызова метода сопряжена с дополнительными издержками в частности на выделение памяти под контекст. Здесь получается экономия, но платить за неё приходится невозможностью наследования, что очень неудобно когда речь идёт о многократно-используемых библиотеках.

Цитата

Эккель пишет, что final - это просто напросто замена вызова метода его телом на уровне компиляции. т.е. это указание на то, что методом это считать нужног только в рамках исходника для понятности кода, а реально - это не метод никакой, а просто кусок другого метода в тех местах, где в коде он вызывается.

По-моему, он писал не совсем так. Это рекомендация компилятору, которая совсем не обязательно будет выполнена.
К тому же, это справедливо для методов и констант простых типов, но никак не для объектов или классов Так что все не так просто.

Цитата(Lamer @ 22.4.2005, 14:59)

simanyay Здесь, в принципе, можно и не указывать final. Мы ведь все равно не сможем создать еще один объект MySingleton - у него же нет неприватного конструктора. Но хуже, конечно, не будет.

Но тогда мы сможем после вызова getInstance заменить объект на другой.

Цитата

Народ, всё проще. Эккель пишет, что final - это просто напросто замена вызова метода его телом на уровне компиляции.

Укажи, пожалуйста, где он это пишет, только точно, чтобы можно было найти. Очень интересно было бы увидеть это своими глазами.
И еще вопрос был про final применительно к параметрам метода, а не к самому методу, или классу, или instance member'у.

Цитата

Но тогда мы сможем после вызова getInstance заменить объект на другой.

Только в одном из методов этого класса и никак иначе. Конструктор-то private.

Zandr
угу, мне тоже стало интересно этот момент перечитать уже Вечерком поищу.

Цитата(Zandr @ 4.5.2005, 09:46)

Только в одном из методов этого класса и никак иначе. Конструктор-то private.

Почему? А так

Код

MySingleton m = MySingleton.getInstance(); m = null; // Где-то дальше... MySingleton m1 = MySingleton.getInstance(); m1.someMethod(); // NullPointerException

?

Исключений нет. m=null, но INSTANCE спокойно сидит в памяти.

Век живи - век учись Получается, что final - что то типа const в Си. Отлично! надо будет поиграть


Так как kashka запропастилась, я попробую перевести этот интересный абзатц про преимущества ассертов перед указанием if (Кстати тоже наследство Си, но в Яве они конечно элегантнее реализованы, т.к. не нужно никаких дефайнов )
------------------------------------------------------------------------------------------

• Сорс короче и понятнее
• С первого взгляда ясно, что речь идёт о проверке кода, а не разветвления if для обычного управления программой.
• Ассершены можно включать и выключать по необходимости. В выключенном виде на проверку не затрачивается рессурсов (памяти, процессора. Прим. sergej.z).

Выражение проверяемое оператором "Assert" должно возвращать тип boolean. Если присутствует дополнительное выражение, которое может возвращать любой тип, оно будет передано в конструктор обьекта AssertionError и послужит текстом сообщения об ошибке.
------------------------------------------------------------------------------------------

Цитата(kashka @ 13.4.2005, 15:48)

assert x >= 0; Das Programm überprüft die Bedingung und fährt fort, wenn sie erfüllt ist. Andernfalls wird eine Ausnahme ausgelöst. Natürlich hätte derselbe Test auch mit Hilfe einer einfachen if-Anweisung ausgeführt werden können. Die assert-Anweisung hat ihr gegenüber jedoch einige Vorteile: Der Programmcode ist kürzer. Auf den ersten Blick ist zu erkennen, daß es sich um einen Korrektheits-Check handelt und nicht um eine Verzweigung zur Steuerung des Programmablaufs. Assertions lassen sich zur Laufzeit wahlweise an- oder ausschalten. Im Gegensatz zu einer einfachen if-Anweisung verursachen sie praktisch keine Verschlechterung des Laufzeitverhaltens, wenn sie deaktiviert sind. Der im Syntaxdiagramm angegebene ausdruck1 muß immer vom Typ boolean sein, andernfalls gibt es einen Compilerfehler. Fehlt ausdruck2 (er darf von beliebigem Typ sein), wird im Falle des Nichterfülltseins der Bedingung ein AssertionError mit einer leeren Fehlermeldung erzeugt. Wurde ausdruck2 dagegen angegeben, wird er im Fehlerfall an den Konstruktor von AssertionError übergeben und dient als Meldungstext für das Fehlerobjekt.

У Эккеля это, оказывается, есть. Дочитываю, наконец

Цитата(Lamer @ 4.5.2005, 15:54)

Исключений нет. m=null, но INSTANCE спокойно сидит в памяти.

Точно. Но I'll be back
Добавлено @ 14:34
sergej.z, хм... интересно. Спасибо за перевод.

Цитата(simanyay @ 4.5.2005, 05:33)

Точно. Но I'll be back smile

В смысле?

Цитата(Domestic @ 5.5.2005, 07:03)

В смысле?

simanyay еще подучит Джаву и покажет тебе, Zandr'у, модификатору final и остальным, где раки зимуют.

Цитата(Lamer @ 5.5.2005, 14:26)

simanyay еще подучит Джаву и покажет тебе, Zandr'у, модификатору final и остальным, где раки зимуют. smile

во во

Перечитал я опять главу в Effective Java про синглтоны и теперь полностью согласен с Lamer George и модификатором final по поводу его работы. Вот.

Ааа, ну тогда ладно

Цитата

simanyay еще подучит Джаву и покажет тебе, Zandr'у, модификатору final и остальным, где раки зимуют.

Дык, я не против Лишь бы конструктив

Я встречался с ситуацией когда нужно объявить аргумент метода final: при его использование в анонимном классе:

Код

public class FinalAndAnonimClass {      void m(final int x){   // final нужен          m2(new ICommand(){       public void execute(){         System.out.println(x);       }     });   }      void m2(ICommand command){  }      interface ICommand{     void execute();   } }

без final компилятор говорит:
"FinalAndAnonimClass.java": local variable x is accessed from within inner class; needs to be declared final at line 7, column 28

Это сообщение отредактировал(а) hatsumeika - 14.5.2005, 19:01

hatsumeika, в этом треде про этот случай уже минимум два раза написали

сорри, не заметил

вот ещё такая реплика:
различные инспекторы кода (pmd, findbugs etc) данный вопрос помещают в категорию optimization - imho логично: компилятору даётся дополнительная информация, о неизменности параметра по присвоению, а он уже вправе ею воспользоваться


https://jjguidelines.dev.java.net/book/html...04.html#JAC_003
https://jjguidelines.dev.java.net/book/html/index.html
сподобалось

Скажем прямо, даже у Sun не много про это сказано. http://java.sun.com/docs/books/tutorial/ja...lVariables.html

Цитата(Zandr @ 4.5.2005, 07:46)

Цитата Народ, всё проще. Эккель пишет, что final - это просто напросто замена вызова метода его телом на уровне компиляции. Укажи, пожалуйста, где он это пишет, только точно, чтобы можно было найти. Очень интересно было бы увидеть это своими глазами. И еще вопрос был про final применительно к параметрам метода, а не к самому методу, или классу, или instance member'у.

Чё-то совсем из головы вылетело. Если ещё не нашлось, - страница 246, либо "глава 6" -> "Ключевое слово final".

Вот кусок (смог найти только английский вариант ):

Цитата

In the case of a compile-time constant, the compiler is allowed to “fold” the constant value into any calculations in which it’s used; that is, the calculation can be performed at compile time, eliminating some run-time overhead. In Java, these sorts of constants must be primitives and are expressed with the final keyword. A value must be given at the time of definition of such a constant. Feedback A field that is both static and final has only one piece of storage that cannot be changed. Feedback When using final with object references rather than primitives, the meaning gets a bit confusing. With a primitive, final makes the value a constant, but with an object reference, final makes the reference a constant. Once the reference is initialized to an object, it can never be changed to point to another object. However, the object itself can be modified; Java does not provide a way to make any arbitrary object a constant. (You can, however, write your class so that objects have the effect of being constant.) This restriction includes arrays, which are also objects.

Ну и дальше - там много про него интересного

Прочитал все вышенаписанное, но так и не понял: что нужно сделать компилятору такого чтобы он заинлайнил final метод? Эккель говорит что это возможно если метод небольшой и компилятор этого захочет... а заставить его никак нельзя? пробовал простейший пример:

Код

package finaltester; public class FinalTester {          /** Creates a new instance of FinalTester */     public FinalTester()     {         secondFinalMethod();         secondNotFinalMethod();     }          public final int secondFinalMethod()     {         return -1;     }     public int secondNotFinalMethod()     {         return -1;     }          public static void main(String[] args)     {         FinalTester ft = new FinalTester();              } }

дизассемблировал - никакого иналйна не наблюдается... понимаю что этот тест поверхностный и надо было провести более детальное исследование но не было времени..

Код

package finaltester; public class FinalTester {     public FinalTester()     {     //    0    0:aload_0              //    1    1:invokespecial   #1   <Method void Object()>     //    2    4:aload_0              //    3    5:invokevirtual   #2   <Method int secondFinalMethod()>     //    4    8:pop                  //    5    9:aload_0              //    6   10:invokevirtual   #3   <Method int secondNotFinalMethod()>     //    7   13:pop                  //    8   14:return               }     public final int secondFinalMethod()     {     //    0    0:iconst_m1            //    1    1:ireturn              }     public int secondNotFinalMethod()     {     //    0    0:iconst_m1            //    1    1:ireturn              }     public static void main(String args[])     {     //    0    0:new             #4   <Class FinalTester>     //    1    3:dup                  //    2    4:invokespecial   #5   <Method void FinalTester()>     //    3    7:astore_1             //    4    8:return               } }

компилировал 1.4 with optimization(netBeans 5.0 beta)

Инлайн на этапе компиляции может делаться только для private методов (и то пока это не делается), а для public только JIT-ом.

Сонный бред был удалён его создателем

Это сообщение отредактировал(а) chief39 - 16.11.2005, 11:03

Цитата(chief39 @ 16.11.2005, 01:37)

....

Хороша трава

Цитата(Domestic @ 16.11.2005, 10:41)

Хороша трава

Не. Спать надо.... Понесло. Буду кофе пить

в продолжении про final у private метода:




Нужен ли final у private-метода (если да, то зачем?) в классе B, если он и так private и не даст себя переопределить?

Нет не нужен, но и не запрещен.

LSD, понял.

По поводу увеличения производительности классов и методов, объявленных как final: довольно свежая статья (2007-02)
это интересно

Чет вроде про это не обсуждали, что странно, как сделать объект-то константым ? Чтобы например 



или так нельзя?

Наверное не четко выразился, имелось ввиду сделать объект именно в этой функции константным. Т.е. именно этот объект "m". 

Или например при передаче объекта в функцию

Я думаю нельзя. Как выход - передавать копию объекта в метод.

Нет.