B>>>String[] x = (String[]) v.toArray(new String[v.size()]);//где v - коллекция строк
B>>>
ВП>>И подобное на моём компе вызывает ClassCastException на серверной стороне. Ладно бы при транспортировке... Вы думаете, я не пытался приведением типа воспользоваться? "Дык оно ж приведение! кто ж его посадит?"
T>Собственно, а откуда вы знаете, что v это коллекция содержащая объекты только одного типа и к тому же String. Вот я и говорю, что без женериксов ничего гарантировать нельзя, только если вы сами знаете на 100%, что в этой коллекции лежит. Странно, что ClassCast вылетает в данном примере, написано ведь правильно.
1) Никогда не приходилось работать с коллекцией совершенно разнородных объектов. Не представляю зачем это может понадобиться.
2) Повторюсь но ниразу не приходилось фиксить ClassCastException потому что в коллекцию попал вдруг не тот объект. Поэтому я не считаю что это одно из основных предназначений генериков.
3) А в данном примере ClassCastException может быть вызван заморочками с класслоадингом. То есть у меня в коллекции объекты класс которых загружен одним загрузчиком, а кастить приходиться к классу загруженному другим загрузчиком. Тут-то типобезопастность явы даёт трещину и мы имеем то что мы имеем.
как отключить автобоксинг в jdk1.5.0 во время компиляции?
Я както создавал топик с темой на подобие "JBuilder7+jdk1.5.0=verifiy error". Теперь я нашел в нете тему в импортном формуме с такой тематикой, это на форуме sun. Там были советы вроде добавление параметра "-noverify", но это только "решение на одну машину". Самое разумное предмположение, которое там прозвучало, это то, что автобоксинг "во всём виноват". Но там также было сказано:
I suspect it is a JBuilder — java 1.5 compatibility issue. I created a simple java bean using JBuilder6 and the 1.5 SDK. When I try to run the packager for the ActiveX bean bridge, I get a
"java.lang.VerifyError Incompatible object argument for function call".
I wonder if the problem lies in the new AutoBoxing/UnBoxing feature. I am suspicious since I always get this error when trying to run the packager if I have this line somewhere in my code:
System.out.println("text" + Integer.toString(1) + "text");
However, this is OK:
System.out.println("text" + Integer.toString(1));
And this is OK:
System.out.println(Integer.toString(1) + "text");
And then I tried compiling the bean using the NetBeans IDE, then running the packager, and everythng worked fine!
по поводу
Your program
public class Tester {
public Tester() {
String ONE = "abc";
String TWO = "def";
System.out.println(ONE + " " + TWO);
}
public static void main(String[] args) {
Tester tester1 = new Tester();
}
}
It's been a month and a half since I used the -noverify option in the VM parameters to get by this error and I ran into it again in a different project. So after some time I narrowed the problem down into a very simple program, and I found a way around it. Here is the program with the error:
public class Tester {
public Tester() {
String ONE = "abc";
String TWO = "def";
System.out.println(ONE + " " + TWO);
}
public static void main(String[] args) {
Tester tester1 = new Tester();
}
}
This code generates the java.lang.VerifyError at runtime. Now, instead of using the "+" operator inside the catch block, break it up into separate print statements as follows:
public class Tester {
public Tester() {
String ONE = "abc";
String TWO = "def";
System.out.print(ONE);
System.out.print(" ");
System.out.println(TWO);
}
public static void main(String[] args) {
Tester tester1 = new Tester();
}
}
The error disappears (at least it did for me). Interestingly, the first class runs fine if you exclude the " " literal. The class also runs fine if you include the " " literal, but exclude either the ONE or TWO variable. But again, the error only occurs when you include all three in the same println() statement using the "+" operator. I have no idea why. Does anyone know?
Такие вот пироги. Правда поиск в гугле вёлся по поводу "using jdk 1.5.0 with jbuilder7" и "another compiler with jbuilder7".
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re: как отключить автобоксинг в jdk1.5.0 во время компиляции
"Решение" пришло само, как следствие "ошибки".
Запускать JBuilder7 из под JDK 1.5.0 (чтоб летал как на ядернуом антигравитоне, и чтоб без глюков, а проекту выстовить JDK 1.3.1 (правда отладка будет немного глюкаыая в облости гуя олаживаемой проги но после компиляции эти глюки должниы того, — то бишь прекратиться.
Что касается шаблонов — то и без них жить можно. MyType[] ещё никто не отменял (собираешь объекты в LinkedList, а потом toArray возвращаешь, и код пользователь даже не узнает, что у кода-источника внутри происходит за "секс с коллекцией", простите за выражение.
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re[2]: как отключить автобоксинг в jdk1.5.0 во время компиля
Здравствуйте, Волк-Призрак, Вы писали:
ВП>"Решение" пришло само, как следствие "ошибки". ВП>Запускать JBuilder7 из под JDK 1.5.0 (чтоб летал как на ядернуом антигравитоне, и чтоб без глюков, а проекту выстовить JDK 1.3.1 (правда отладка будет немного глюкаыая в облости гуя олаживаемой проги но после компиляции эти глюки должниы того, — то бишь прекратиться. ВП>Что касается шаблонов — то и без них жить можно. MyType[] ещё никто не отменял (собираешь объекты в LinkedList, а потом toArray возвращаешь, и код пользователь даже не узнает, что у кода-источника внутри происходит за "секс с коллекцией", простите за выражение.
Не совсем понял как toArray может спасти от ClassCastException (для чего собственно и были введены generics).
Кстати запускать JBuilder 7 под 5 жавой, наверное не стоит, так как даже с JDK 1.4.2 было много несовместимостей, даже в плане GUI. Кстати рекомендую поставить 2005-й билдер, я уж помню сколько глюков было убрано начиная с 9 (особенно по части web-development), так даже не представляю какой геморой ждал бы меня если бы я писал сейчас на 7-ом =), да еще под новой жавой.
Re[3]: как отключить автобоксинг в jdk1.5.0 во время компиля
Здравствуйте, Trean, Вы писали:
T>Не совсем понял как toArray может спасти от ClassCastException (для чего собственно и были введены generics).
Просто придходится делать сначала Object[] который преобразуется в подленный тип с помощью System.arraycopy. T>Кстати запускать JBuilder 7 под 5 жавой, наверное не стоит, так как даже с JDK 1.4.2 было много несовместимостей,
Я смотрю, тебе мои топики остальные не попадались. я мегабайт 50 наверное по этому поводу насрал в форуме.
T> даже в плане GUI.
Я наверное родился в рубашке наинанку У меня всё наоборот В jb7 под jdk 1.3.1 срашные глюки с раздвиженим вширь открываемых диалговых окон билдера. А если его запустить из подь 1.5.9 то все эти глюки исчезают, плюс я ускоряю работу билдера с помощью -Dcom.sun.java2d.opengl=true.
А в проекте выставлена jdk 1.3.1, таким образом я избавился от Verify Error. T>Кстати рекомендую поставить 2005-й билдер, я уж помню сколько глюков было убрано начиная с 9 (особенно по части web-development), так даже не представляю какой геморой ждал бы меня если бы я писал сейчас на 7-ом =), да еще под новой жавой.
Тебя то он может и ждал, но у меня же вссё наоборот Меня герр Моррой обошёл стороной
Между прочем на моём прямо скажем незапгрейденном насмерть компе, JBuilder7 просто летает, если запущен под 1.5.0[!]
Хардвар такой (специально для тебя говорю, так как мя ситуацтя тебе "в новинку": PIII766/256/GeForce Ti4200 128.
А пираты жабу перестали уважать.
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re[4]: как отключить автобоксинг в jdk1.5.0 во время компиля
T>>Не совсем понял как toArray может спасти от ClassCastException (для чего собственно и были введены generics). ВП>Просто придходится делать сначала Object[] который преобразуется в подленный тип с помощью System.arraycopy.
String[] x = (String[]) v.toArray(new String[v.size()]);//где v - коллекция строк
T>>Кстати запускать JBuilder 7 под 5 жавой, наверное не стоит, так как даже с JDK 1.4.2 было много несовместимостей, ВП>Я смотрю, тебе мои топики остальные не попадались. я мегабайт 50 наверное по этому поводу ...
Второе китайское предупреждение за брань
Re[5]: как отключить автобоксинг в jdk1.5.0 во время компиля
Здравствуйте, Blazkowicz, Вы писали:
B> B> Вы щас будете третье китайское предупреждение делать. Потому что B>
B>String[] x = (String[]) v.toArray(new String[v.size()]);//где v - коллекция строк
B>
И подобное на моём компе вызывает ClassCastException на серверной стороне. Ладно бы при транспортировке... Вы думаете, я не пытался приведением типа воспользоваться? "Дык оно ж приведение! кто ж его посадит?"
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();};
Скажи .net корпорации Microsoft! (c) ghostwolf 2004
7 раз поищи в стандартной библиотеке, 1 раз накодь своё.
Re[6]: как отключить автобоксинг в jdk1.5.0 во время компиля
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Blazkowicz, Вы писали:
B>> B>> Вы щас будете третье китайское предупреждение делать. Потому что B>>
B>>String[] x = (String[]) v.toArray(new String[v.size()]);//где v - коллекция строк
B>>
ВП>И подобное на моём компе вызывает ClassCastException на серверной стороне. Ладно бы при транспортировке... Вы думаете, я не пытался приведением типа воспользоваться? "Дык оно ж приведение! кто ж его посадит?"
Собственно, а откуда вы знаете, что v это коллекция содержащая объекты только одного типа и к тому же String. Вот я и говорю, что без женериксов ничего гарантировать нельзя, только если вы сами знаете на 100%, что в этой коллекции лежит. Странно, что ClassCast вылетает в данном примере, написано ведь правильно.
Re[8]: как отключить автобоксинг в jdk1.5.0 во время компиля
Здравствуйте, Blazkowicz, Вы писали:
B>3) А в данном примере ClassCastException может быть вызван заморочками с класслоадингом. То есть у меня в коллекции объекты класс которых загружен одним загрузчиком, а кастить приходиться к классу загруженному другим загрузчиком. Тут-то типобезопастность явы даёт трещину и мы имеем то что мы имеем.
Не, в данном конкретном случае это не тот случай. java.lang.String всегда быдет загружена одним и тем же bootstrap-загрузчиком (ну если ничего не ломать)
Здравствуйте, Lucker, Вы писали:
B>>3) А в данном примере ClassCastException может быть вызван заморочками с класслоадингом. То есть у меня в коллекции объекты класс которых загружен одним загрузчиком, а кастить приходиться к классу загруженному другим загрузчиком. Тут-то типобезопастность явы даёт трещину и мы имеем то что мы имеем.
L>Не, в данном конкретном случае это не тот случай. java.lang.String всегда быдет загружена одним и тем же bootstrap-загрузчиком (ну если ничего не ломать)
Пример со стрингами я давал просто чтобы показать как коллекции в массивы загонять, а у товарища Волка-Призрака, там точно другой класс...
Re[10]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Lucker, Вы писали:
B>>>3) А в данном примере ClassCastException может быть вызван заморочками с класслоадингом. То есть у меня в коллекции объекты класс которых загружен одним загрузчиком, а кастить приходиться к классу загруженному другим загрузчиком. Тут-то типобезопастность явы даёт трещину и мы имеем то что мы имеем.
L>>Не, в данном конкретном случае это не тот случай. java.lang.String всегда быдет загружена одним и тем же bootstrap-загрузчиком (ну если ничего не ломать)
B>Пример со стрингами я давал просто чтобы показать как коллекции в массивы загонять, а у товарища Волка-Призрака, там точно другой класс...
Я эээ на всё отвечу сразу. Заморочки с класслоадерами тут не причём. Ибо ошибка происходит на сервере, а на клиенте всё ок.
На сервере всё загружается AppClassLoader, или как там сановский стандартный называется.
Не другой, а самый обыкновенный java.lang.String.... Лажа в том, что я забыл уже когда это выскакивало — при отладке в 1.3.1 или при работе автономной (без IDE из Jar-ов)в 1.5.0... Но делать "експлоит" на эту тему я делать не буду — я не подрывник
Переключаешься на свежую траблу старую отправляешь в long persistence.
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Я эээ на всё отвечу сразу. Заморочки с класслоадерами тут не причём. Ибо ошибка происходит на сервере, а на клиенте всё ок. ВП>На сервере всё загружается AppClassLoader, или как там сановский стандартный называется.
Сановский стандарт тут не причем. И AppClassLoader тут вообще не к месту. У каждого J2EE сервера своя система загрузчиков.
ВП>Не другой, а самый обыкновенный java.lang.String.... Лажа в том, что я забыл уже когда это выскакивало — при отладке в 1.3.1 или при работе автономной (без IDE из Jar-ов)в 1.5.0... Но делать "експлоит" на эту тему я делать не буду — я не подрывник
Из этого можно сделать вывод что ты просто что-то проглядел и проблема была совсем в другом.
ВП>Переключаешься на свежую траблу старую отправляешь в long persistence.
Есть такое понятие bug tracking system...
Re[12]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Волк-Призрак, Вы писали:
B>Сановский стандарт тут не причем. И AppClassLoader тут вообще не к месту. У каждого J2EE сервера своя система загрузчиков.
Я про это упоминул только в котексте "другой класс"
B>Из этого можно сделать вывод что ты просто что-то проглядел и проблема была совсем в другом.
Самое то странное, что явное обращение к временному Object[] в рамках System.arraycopy работает нормально, а type cast Object[] -> String[] не канает.
"Покажите мне java-класс, не производный от java.lang.Object, понимаешь!...
ВП>>Переключаешься на свежую траблу старую отправляешь в long persistence. B>Есть такое понятие bug tracking system...
Мдя.... этот мордо-плэй-бой с тайпекастом наверняка мне вйдет боком в какомнить неожиданном переулке моего кода.
Здравствуйте, Волк-Призрак, Вы писали:
B>>Из этого можно сделать вывод что ты просто что-то проглядел и проблема была совсем в другом. ВП>Самое то странное, что явное обращение к временному Object[] в рамках System.arraycopy работает нормально, а type cast Object[] -> String[] не канает. ВП>"Покажите мне java-класс, не производный от java.lang.Object, понимаешь!...
Вот она лень... Мало того что не разобрался что к чему (тему уже не один раз обсуждали), так ещё и обозвал указанный выше пример нерабочим даже не опробовав.
Re[14]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Волк-Призрак, Вы писали:
B>>>Из этого можно сделать вывод что ты просто что-то проглядел и проблема была совсем в другом.
Буду думать.
B>Вот она лень... Мало того что не разобрался что к чему (тему уже не один раз обсуждали), так ещё и обозвал указанный выше пример нерабочим даже не опробовав.
Извините. Спишем на дилетантство, ладно?
Пример я попробовал, заменив String на CarCategories. Вот так:
CarCategory[] x = (CarCategory[]) temp.toArray(new CarCategory[temp.size()]);
Работает. Но без "дополнительного" массива, передаваемого в ToArray — нет.
Я могу сразу передать массив-приёмник нужного размера, а не выделять временый псевдобуфер? Если я правильно понимаю это — то да.
Returns an array containing all of the elements in this list in the correct order. The runtime type of the returned array is that of the specified array. If the list fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this list.
Но спрашиваю во избежание, т. .к мне рано быть ещё в чём либо увренным.....
Наверно нельзя мне было книгу Бъерна Страуструпа читать про С++. Там написано было что главное качество всех программеров, что именно она толкает вперёд средства разработки Видно это слишком криво на меня повлияло. Наследие C++
*надеюсь вы поняли что я шучу и надеюсь что вы уже привыкли к моему "младенческому сарказму"*
Здравствуйте, Волк-Призрак, Вы писали:
B>>Вот она лень... Мало того что не разобрался что к чему (тему уже не один раз обсуждали), так ещё и обозвал указанный выше пример нерабочим даже не опробовав. ВП>Извините. Спишем на дилетантство, ладно? ВП>Пример я попробовал, заменив String на CarCategories. Вот так: ВП>
ВП> CarCategory[] x = (CarCategory[]) temp.toArray(new CarCategory[temp.size()]);
ВП>
ВП>Работает. Но без "дополнительного" массива, передаваемого в ToArray — нет.
Ищи по форуму уже обсуждали почему.
ВП>Я могу сразу передать массив-приёмник нужного размера, а не выделять временый псевдобуфер? Если я правильно понимаю это — то да. ВП>
ВП>Returns an array containing all of the elements in this list in the correct order. The runtime type of the returned array is that of the specified array. If the list fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this list.
ВП>Но спрашиваю во избежание, т. .к мне рано быть ещё в чём либо увренным.....
Ну, криво реализованная коллекция можетм и не так работать. Но все нормальные реализации используют переданный массив если его раземр позволяет.
Re[16]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Ищи по форуму уже обсуждали почему.
Пожалуй, если бы я знал, что есть какаянить штука типа Object[] newArrayOF(Class type, int length);, это было бы хорошо, а так для гарантии придётся сделать константрые массивы 0й длины
в силу
B>Ну, криво реализованная коллекция можетм и не так работать.
B>Но все нормальные реализации используют переданный массив если его раземр позволяет.
Я и так и этак попробую.
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Blazkowicz, Вы писали:
B>>Ищи по форуму уже обсуждали почему. ВП>Пожалуй, если бы я знал, что есть какаянить штука типа Object[] newArrayOF(Class type, int length);, это было бы хорошо, а так для гарантии придётся сделать константрые массивы 0й длины
Пажалуйста:
public static <E> E[] alloc(Class<E> type, int numBands) {
return (E[])Array.newInstance(type, numBands);
}
Работает без ворнингов даже =)
Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI)
Re[18]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Trean, Вы писали:
T>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI)
Я спрашивал. Так ведь все приводятся к одному интерфейсу, значит однородны относительно этого интерфейса. А вот коллекция абсолютно разнотипных объектов у который общий только Object, это ИМХО, глупость.
Re[19]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Trean, Вы писали:
T>>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI)
B>Я спрашивал. Так ведь все приводятся к одному интерфейсу, значит однородны относительно этого интерфейса. А вот коллекция абсолютно разнотипных объектов у который общий только Object, это ИМХО, глупость.
class ParamDescriptor {
public Class type; // тип параметра
public String name; // имя параметра
public Object value; // значение
}
То есть иногда требуется иметь несколько имплементаций одного интерфейса, типы и кол-во параметров одного из методов которого в compile time не известны. Разумеется каждый из классов имплементирующих такой интерфейс должен иметь метод типа validateParams() чтобы не вызывать ClassCastException. Данная схема очень удобна, когда требуется выполнить одинаковые операции, отличающиеся какими либо параметрами, которые надо запросить у пользователя.
Re[20]: как отключить автобоксинг в jdk1.5.0 во время компил
T>То есть иногда требуется иметь несколько имплементаций ОДНОГО интерфейса, типы и кол-во параметров одного из методов которого в compile time не известны.
Блин, ну а я про что.
Re[21]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Trean, Вы писали:
T>>То есть иногда требуется иметь несколько имплементаций ОДНОГО интерфейса, типы и кол-во параметров одного из методов которого в compile time не известны.
B>Блин, ну а я про что.
Моя твоя не понимать:
B>вот коллекция абсолютно разнотипных объектов у который общий только Object, это ИМХО, глупость.
Я как раз привел пример когда, как раз коллекция разнотипных объектов не глупость =) У меня такая коллекция может содержать к примеру объекты разного типа: Double, Integer, String как параметры и это не будет глупо (хотя я не исключаю, что есть и другие подходы).
Re[18]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Trean, Вы писали:
T>Пажалуйста:
T> public static <E> E[] alloc(Class<E> type, int numBands) { T> return (E[])Array.newInstance(type, numBands); T> }
T>Работает без ворнингов даже =)
А теперь давайте объясним это Jdk1.3.1 или 1.4.2.06, например
Даже если вам то удастся, объясните тогда jbuilder7, что есть такие классные ребята, как javac.exe и com.sun.tools.javac.Main
И не надо мне говорить про обновление личного машинного парка или ПО Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
T>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI)
Если нельзя ну никак сделать это через Method.invoke && Object[] либо
Command.Execute && ParamDescriptor[], то имхо в моих дилиетентских системах координат это выглядит как ошибка дизайна.
Кстати вариант с ParamDescriptor — толстое пузатое заплывшее избыточностью безобрзие (вид в тех же координатах).
Потому что Class можно не хранить отдельно — это дело getClass().
А строковые имена-описания — debug-only requements.
я бы сделал так:
public interface CommandTemplate implements Serializable {
public String getParameterName(int index);
public Class getParameterType(int index);
public Object getDefaultValue();
public boolean isParamRequired(int index);
public int paramsCount();
}
И мэппинг сделать — класс -> CommandTemplate,
класс реализует интерфейс Command.
класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон.
а при сериализации передаются тоько чтонить вроде Object[].
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Trean, Вы писали:
T>>Пажалуйста:
T>> public static <E> E[] alloc(Class<E> type, int numBands) { T>> return (E[])Array.newInstance(type, numBands); T>> }
T>>Работает без ворнингов даже =)
ВП>А теперь давайте объясним это Jdk1.3.1 или 1.4.2.06, например ВП>Даже если вам то удастся, объясните тогда jbuilder7, что есть такие классные ребята, как javac.exe и com.sun.tools.javac.Main ВП> ВП>И не надо мне говорить про обновление личного машинного парка или ПО Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
T>>Тут еще кто-то спрашивал зачем мол могут понадобиться списки или мапы с разными типами объектов. Очень просто — переменный список параметров метода (чтобы интерфейс был общий, так например сделано в JAI) ВП>Если нельзя ну никак сделать это через Method.invoke && Object[] либо ВП>Command.Execute && ParamDescriptor[], то имхо в моих дилиетентских системах координат это выглядит как ошибка дизайна. ВП>Кстати вариант с ParamDescriptor — толстое пузатое заплывшее избыточностью безобрзие (вид в тех же координатах). ВП>Потому что Class можно не хранить отдельно — это дело getClass().
Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма)
Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>А строковые имена-описания — debug-only requements.
Ну можно еще для запросов параметра у юзера
ВП>я бы сделал так: ВП>
ВП>public interface CommandTemplate implements Serializable {
ВП> public String getParameterName(int index);
ВП> public Class getParameterType(int index);
ВП> public Object getDefaultValue();
ВП> public boolean isParamRequired(int index);
ВП> public int paramsCount();
ВП>}
ВП>
ВП>И мэппинг сделать — класс -> CommandTemplate, ВП>класс реализует интерфейс Command. ВП>класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон. ВП>а при сериализации передаются тоько чтонить вроде Object[].
Да, согласен пожалуй так красивее и правильнее, просто я видел сановскую реализацию и привел ее как пример использования гетерогенных списков =)
С паттернами у меня проблема, что есть то есть (буду благодарен за книжку GoF в эл. виде =)
Re[17]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Пожалуй, если бы я знал, что есть какаянить штука типа Object[] newArrayOF(Class type, int length);, это было бы хорошо, а так для гарантии придётся сделать константрые массивы 0й длины
Так ведь такая штука есть в классе Array, она собственно в toArray и вызывается... а массив передаваемый и служит для получения type. Наверное я чего-то не просек =) Другое дело что из Object[] не получишь String[]
Кстати кто-нить знает чем отличаются (в том числе по скорости) System.arraycopy и clone() применненный к масиву?
Re[18]: как отключить автобоксинг в jdk1.5.0 во время компил
Здравствуйте, Trean, Вы писали:
T>Кстати кто-нить знает чем отличаются (в том числе по скорости) System.arraycopy и clone() применненный к масиву?
Дело не в скорости, а в том что с помошью System.arraycopy элементы одного массива копируются в другой, а в случае с clone просто создается новый объект. Думаю что разница во времени, затраченном на создание нового объекта массива (которой, впринципе можно принебречь)
T>Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма) T>Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>>А строковые имена-описания — debug-only requements. T>Ну можно еще для запросов параметра у юзера
Когда есть шаблоны (описатели) команд, как понятие в системе, можно позволить себе даже такие извращения в них положить, как контекст для справки, значок, итп итд. Потому что такой описатель будет в 1 экземпляре храниться 91 описатель -> 1 класс).
НО! 98 классов напишешь нормально и не забудешь вызывать registerTemplate, а на 99м классе забудешь и всё, кирдык. В смысле такие шаблоны вводят сложности при кодировании, поэтому из классов объекто сообщений я это всё подобное (шаблоны сообщений) вырезал нафиг. В логгерыпишу имя класса соббщения и имя компа-источника. Мне хватает.
ВП>>я бы сделал так: ВП>>
ВП>>public interface CommandTemplate implements Serializable {
ВП>> public String getParameterName(int index);
ВП>> public Class getParameterType(int index);
ВП>> public Object getDefaultValue();
ВП>> public boolean isParamRequired(int index);
ВП>> public int paramsCount();
ВП>>}
ВП>>
ВП>>И мэппинг сделать — класс -> CommandTemplate, ВП>>класс реализует интерфейс Command. ВП>>класс при свой загрузке регестрирует себя вшаблонозранилище, генеря про себя шаблон. ВП>>а при сериализации передаются тоько чтонить вроде Object[].
T>Да, согласен пожалуй так красивее и правильнее, просто я видел сановскую реализацию и привел ее как пример использования гетерогенных списков =)
Но опять таки поскольку это лишня работа при кодинге с забытывабельными однотипными строчками, то лучше ограничится рефлексией по мере потребности в mutability.
Нука, накодь 100-200 классов команд, и к кадому нацепи шаблон-описатель... Сам такого не делал и не собираюсь.
Вместо этого лучше в бд с кэшированием востребованых хранить. Так у тебя описатели будут в одном месте, а этак — по всему коду.
Кстати в КП в бд храню описатели действий, класс формы указан как полное (с пакетом) имя. Всё никак не дотяусь чтобы сделать форму регистрацию действий.
T>С паттернами у меня проблема, что есть то есть (буду благодарен за книжку GoF в эл. виде =)
Оно мене нужнее чем вам потому как по ходу курсового проекта я постоянно изобретаю самоходные орудия на коровьих лепёшках.
ВП>>publicinterface CommandTemplate implements Serializable {
ВП>> public String getParameterName(int index);
ВП>> public Class getParameterType(int index);
ВП>> public Object getDefaultValue();
ВП>> public boolean isParamRequired(int index);
ВП>> public int paramsCount();
ВП>>}
ВП>>
И никто не заметил...... (имплементирующий интерфейс — это в хумор надо) я и то,только случайно, 6й раз перечитывая тему.ююююю
Здравствуйте, Волк-Призрак, Вы писали:
ВП>Здравствуйте, Trean, Вы писали:
T>>Ну я писал быстро и не пытался мега-шаблоны применять (обычно все на интерфейсах делаю, а тут упростил до примитивизма) T>>Согласен достаточно дефолтового значения у которого можно получить тип, либо если нет такогового, то только Class (очепятался я с Object value)
ВП>>>А строковые имена-описания — debug-only requements. T>>Ну можно еще для запросов параметра у юзера ВП>Когда есть шаблоны (описатели) команд, как понятие в системе, можно позволить себе даже такие извращения в них положить, как контекст для справки, значок, итп итд. Потому что такой описатель будет в 1 экземпляре храниться 91 описатель -> 1 класс). ВП>НО! 98 классов напишешь нормально и не забудешь вызывать registerTemplate, а на 99м классе забудешь и всё, кирдык. В смысле такие шаблоны вводят сложности при кодировании, поэтому из классов объекто сообщений я это всё подобное (шаблоны сообщений) вырезал нафиг. В логгерыпишу имя класса соббщения и имя компа-источника. Мне хватает.
Дело в том, что мне это необходимо в нескольких классах, не надо мне 98 классов писать =)
Я вообще сторонник принципа "Make recent things easy, rare things possible"
У меня всё наоборот
Меня герр Моррой обошёл стороной
Я на оффтопинге по этому поводу уже всех собак Китая сьел и скоро модераторам сниться.
