Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2006.03.05;
Скачать: [xml.tar.bz2];

Вниз

Java   Найти похожие ветки 

 
iZEN ©   (2006-02-04 01:52) [40]

programania ©   (03.02.06 21:52) [39],
по Java много русской документации и книг по РАЗНЫМ темам. Нужно просто уметь искать.
По J2EE книг очень много (EJB, JSP, JDBC, JMS, JAXP, SOAP  и т.д.).
По J2SE книг столько же, сколько по Delphi (основы и подробные справочники, спец. издания по AWT/JFC/Swing, Securiy).
По J2ME книг практически нет (я знаю всего три книги на русском языке, одна из которых уже не издаётся).

По Delphi книг много, но все они ОДИНАКОВЫ, только способ изложения отличается от примитивного до въедливого.


 
pasha_golub ©   (2006-02-04 18:56) [41]


> Могу дать ссылку на проект друга, может заодно кого заинтересует:
>  http://www.fourthelephant.com/


GUI явно понравился. Видимо, все что рисуется руками, можно сделать красиво, а все что "стандартно", то стандартно и по виду...


 
Firefly ©   (2006-02-04 18:58) [42]

>[40] iZEN ©   (04.02.06 01:52)
Можете дать ссылки?


 
iZEN ©   (2006-02-04 20:06) [43]

Firefly ©   (04.02.06 18:58) [42]

Список издательств, выпускающих книги, говорит сам за себя:
www.bhv.ru
www.binom-press.ru
www.dialektika.com
www.dmk-press.ru
www.lory-press.ru
www.okc.ru:8080
www.piter.com
www.williamspublishing.com
www.wnk.biz
Воспользуйтесь поиском на них и всё найдёте.


 
Firefly ©   (2006-02-05 17:36) [44]

Спасибо.
По поводу ГУИ - в java он создается через ?:%?%. ИМХО(сейчас сижу рисую оконные элементы).


 
kaif ©   (2006-02-05 22:55) [45]

Если попытаться в середине текста на JAVA поднять исключение, то компилироваться такой проект не будет. Это нормально?

try {
 //здесь код
 throw new Exception("Здесь мне шиза в голову ударила проверить, как все будет работать на практике, если здесь возникнет исключительная ситуация")
 //и здесь код
}
catch (Exception e) {
 //здесь вывод сообщения
}

Так вот компилятор скажет, что код после строки, в которой я искуственно поднял исключение, никогда не будет выполнен и откажется компилировать программу. Почему JAVA за меня решает, что мне нужно, а что нет? Это у джавистов так принято, что ли?
Например, Tomcat позволяет себе давать сообщения в таком духе
"это слово неправильное - удали это слово".
Почему Джава или Джаваобразные продукты не могут просто сказать "не понимаю, не нашла, не вижу"? (Как это делают скромные, но весьма шустрые компиляторы с языка Паскаль, например)
Почему вместо этого Джава говорит "неправильно написал, выкинь, удали, здесь нет того, здесь должно быть это..."?

Если бы она при этом поминутно не говорила чушь, то я бы это еще как-то готов был терпеть. Но когда она говорит "такого метода нет", а на самом деле имеется в виду "чувак, ты, возможно, забыл параметр, так как я не могу найти перегружаемого метода с таким набором параметров", то это иногда начинает просто раздаражать.

А вот как вам такая конструкция?

     String anyName = g == 5 ? "Вася" : "Маша";

Это работает так: если g равно 5, то правая часть вернет "Вася", а в противном случае - "Маша".
Замечательно.
JAVA это съест и вовсе не будет возражать. Скобок перед ? она не потребует. Хотя требует их после любого if

Так вот теперь самое интересное. Давайте вместо "Маша" подставим еще еще один такой оператор.

    String anyName = g == 5 ? "Вася" : b == 10 ? "Киса" : "Маша";

Если не ставить скобки в таких местах легко можно получить сообщение о том, что в строке ожидается тип boolean, а найден String.

ИМХО, правильнее было бы требовать скобок изначально.

     String anyName = (g == 5) ? ("Вася" ) : ("Маша");


 
Petr V. Abramov ©   (2006-02-06 00:47) [46]

> Так вот компилятор скажет, что код после строки, в которой я
> искуственно поднял исключение, никогда не будет выполнен и откажется
> компилировать программу.
 А у кода "после строки "есть шанс выполниться? Если нету, то, может,  это передний фронт борьбы с программами с warning`ами компилятора? При использовании Delphi с хинтами и варнингами приходится бороться административными методами, что чего-то стОит. А тут идея " в корне зло пресечь"?


 
Sandman29 ©   (2006-02-06 09:25) [47]

try {
//здесь код
throw new Exception("Здесь мне шиза в голову ударила проверить, как все будет работать на практике, если здесь возникнет исключительная ситуация")
//и здесь код
}
catch (Exception e) {
//здесь вывод сообщения
}


Попробуйте заменить на

try {
//здесь код
KaifUtils.throwNewException();
//и здесь код
}
catch (Exception e) {
//здесь вывод сообщения
}

и
public KaifUtils (){
 public static void throwNewException() throws Exception{
    throwNewException("Здесь мне шиза в голову ударила проверить, как все будет работать на практике, если здесь возникнет исключительная ситуация");
 }
 public static void throwNewException(String exceptionMessage) throws Exception ()
    throw new Exception(exceptionMessage);
 }
}


 
Lamer@fools.ua ©   (2006-02-06 11:08) [48]

>String anyName = g == 5 ? "Вася" : b == 10 ? "Киса" : "Маша";

И кто Вас заставляет писать плохочитаемый код?


 
iZEN ©   (2006-02-06 19:26) [49]

kaif ©   (05.02.06 22:55) [45].

В Java есть такие понятия: Checked Exceptions и Unchecked Exceptions.
Они РАЗНЫЕ и используются по-разному.

В Delphi и .Net есть одно понятие: Unchecked Exceptions.
Этим всё сказано.

Вы не знаете многого, но это не повод обвинять Java в своих "непонятках".


 
Firefly ©   (2006-02-06 21:57) [50]

Здравствуйте  еще раз.
А какую литературу(в смысле авторов) посоветуете.


 
DiamondShark ©   (2006-02-06 22:27) [51]


> И кто Вас заставляет писать плохочитаемый код?

А зачем нужны языковые излишества, которые порождают плохочитаемый код?

Оператор ?: явно лишний в языке.


> В Delphi и .Net есть одно понятие: Unchecked Exceptions.
>
> Этим всё сказано.

вот именно: всё.
Лишние языковые конструкции, зачем их городить?


 
pasha_golub ©   (2006-02-06 23:08) [52]


> DiamondShark ©   (06.02.06 22:27) [51]


> Лишние языковые конструкции, зачем их городить?

Иногда было бы неплохо. Например, я жутко тоскую по такой конструкции:

Case StringVar of
"vasya": ...
"petya": ...
else
...
end;


 
Lamer@fools.ua ©   (2006-02-06 23:32) [53]

>>DiamondShark ©   (06.02.06 22:27) [51]

>Оператор ?: явно лишний в языке.
По моему мнению не лишний, а весьма даже удобный. А моё замечание относилось к одному конкретному применению этого оператора.

З.Ы. А вот и не подерёмся...


 
iZEN ©   (2006-02-07 00:09) [54]

>DiamondShark ©   (06.02.06 22:27) [51]

>> В Delphi и .Net есть одно понятие: Unchecked Exceptions.
>> Этим всё сказано.

>вот именно: всё.
>Лишние языковые конструкции, зачем их городить?
Они не лишние (насчёт Exceptions), они взаимодополняющие, одно является более сильной формой другого.
Компилятор на этапе компиляции откажется компилировать класс с методом, в котором не обработано (try/catch) или не объявлено (throws) Checked Exception предка, но с чистой совестью откомпилирует код с Unchecked Exception. Это заставляет программиста более серьёзно отнестись к обработке исключений в приложении и соблюдать контрактное программирование.


 
Evgeny V ©   (2006-02-07 07:23) [55]


> Firefly ©   (06.02.06 21:57) [50]
> Здравствуйте  еще раз.
> А какую литературу(в смысле авторов) посоветуете.

Мне очень понравился двухтомник авторов Кей С. Хорстманн и Гари Корнел

книга JAVA 2  том 1 "Основы" и том 2 "Тонкости программирования."
Но сам начал учить относительно недавно язык  и может кто подскажет и лучшие книги.
Но для начинающего  на мой взгляд(для меня например) - это очень хороший учебник основ.


 
pasha_golub ©   (2006-02-07 10:38) [56]

Друзья, а есть ли для Java наборы компонентов, подобные этому:
http://www.devexpress.com/Products/VCL/ExQuantumPack/

Я не с целью обкакать, действительно интересно. Прикидываю в уме возможность и трудозатраты на портирование некоего приложения, если честно.


 
DiamondShark ©   (2006-02-07 11:30) [57]


> Например, я жутко тоскую по такой конструкции:

А я наоборот, никогда не испытывал потребности в такой конструкции.

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


> По моему мнению не лишний, а весьма даже удобный.

Чем удобный-то? Строки исходника экономить?


 
Sandman29 ©   (2006-02-07 11:41) [58]

DiamondShark ©   (07.02.06 11:30) [57]

Одной из приятных ваозможностей С#: в операторе switch можно использовать строковую переменную, сравниваемую в операторах case со строковыми константами...[skipped] На самом деле, благодаря технологии интернирования строк, заключающейся в поддержке таблицы всех уникальных строк, используемых программой, он работает гораздо быстрее, чем может показаться.Петцольд.

Чем удобный-то? Строки исходника экономить?

1. Более читабельный.
MaximumNumberOfBuiltUnits = a > b? a: b;

if (a > b)
 MaximumNumberOfBuiltUnits = a;
else
 MaximumNumberOfBuiltUnits = b;

2. Не требующий заведения локальных переменных в случае
MyObjectArray[I].MyObject.MaximumNumberOfBuiltUnits = a > b? a: b;


 
Lamer@fools.ua ©   (2006-02-07 13:03) [59]

>>DiamondShark ©   (07.02.06 11:30) [57]

>Чем удобный-то? Строки исходника экономить?
Удобство — вещь в большОй мере субъективная. Спорить о субъективных вещах я не намерен.


 
iZEN ©   (2006-02-07 14:48) [60]

>pasha_golub ©   (07.02.06 10:38) [56]

>Друзья, а есть ли для Java наборы компонентов, подобные этому:
>http://www.devexpress.com/Products/VCL/ExQuantumPack/

>Я не с целью обкакать, действительно интересно. Прикидываю в уме >возможность и трудозатраты на портирование некоего приложения, если честно.

Да и не только. На основе Swing можно сконструировать какие угодно виджеты со скинами разных операционных систем (MacOS Aqua, UNIX CDE/Motif, Windows/XPTheme, Java/Metal, Java/Ocean).


 
pasha_golub ©   (2006-02-07 14:59) [61]


> iZEN ©   (07.02.06 14:48) [60]


> На основе Swing можно сконструировать

Ключевое слово "сконструировать". А чтобы не конструировать, а использовать сторонее? Ибо конструирование - это время которого обычно нету.


 
iZEN ©   (2006-02-07 16:37) [62]

pasha_golub ©   (07.02.06 14:59) [61], там не так много конструировать.


 
pasha_golub ©   (2006-02-07 18:13) [63]


> iZEN ©   (07.02.06 16:37) [62]


Да ну... Хорошо, давай примерчик попробуем разобрать (не портировать) ). Например, TcxTreeList. Вот список его фич: http://www.devexpress.com/Products/VCL/ExQuantumTreeList/Features.xml

Хотя, конечно, сухой текст врядли предоставит всю информацию. Было б замечательно его попробовать самому.


 
iZEN ©   (2006-02-07 18:27) [64]

pasha_golub ©   (07.02.06 18:13) [63]

См. http://izen.dev.juga.ru/downloads/swingexamples.zip


 
kaif ©   (2006-02-07 21:43) [65]

2 iZEN ©  
Странно, но в Delphi непонятки у меня просто не возникают.
А в JAVA постоянно сталкиваюсь с непонятками и преодолеваю трудности там, где их, казалось бы, не должно было быть вообще.
Вот. например, как получилось, что класс Date существует как в пакете java.util.Date, так и в пакете java.sql.Date ?

То есть если разработчик многократно использовал в тексте конструкции вроде Date d = new Date(), то как только ему понадобится заюзать sql-запрос и он проимпортирует пакет java.sql.*, компилятор начнет ругаться на весь предыдущий код, сообщая, что Date - двусмысленное понятие. И все места в тексте придется переделывать на

java.util.Date d = new java.util.Date().

Разумеется, такому разработчику можно сказать "ну дык ты дурак, ты сначала джаву изучи, а потом начинай на ней программировать". вопрос лишь в том, как не программипруя реальные задачи научиться программировать. И и нтересно, почему другие языки подобные фортели  не выкидывают. По крайней мере в классах своих основных системных библиотек.

Для того чтобы просто правильно отформатировать дату сегодня я потерял более двух часов. В конце концов я пришел к выводу, что использовать константу Calendar.MONTH нельзя вообще, так как метод get(Calendar.MONTH) класса Calendar работает не так, как сказано в документации (для любой даты возвращает 1). А DateFormat на строку вида "yyyy-MM-dd" вернул для 7-го февраля 22-й месяц (2006-22-07).
В результате мне пришлось для надежности переделать все SQL-запросы на параметрические и передавать в них параметрами даты, так как я не мог быть уверен, что смогу правильно сформатировать простейшее "2006-02-07" для прямой подстановки в текст запроса для ORACLE (у меня запросы создаются динамически).

еще хотелось бы понять, зачем изучать эту самую Джаву, если методы в ней устаревают со скоростью света. Чтобы не быть голословным приведу хотя бы список методов того же класса Date (который в sql), который у меня сейчас перед глазамив в JAVADOC:

getHours()
         Deprecated.  
int getMinutes()
         Deprecated.  
int getSeconds()
         Deprecated.  
void setHours(int i)
         Deprecated.  
void setMinutes(int i)
         Deprecated.  
void setSeconds(int i)
         Deprecated.  
void setTime(long date)
         Sets an existing Date object using the given milliseconds time value.
String toString()
         Formats a date in the date escape format yyyy-mm-dd.
static Date valueOf(String s)
         Converts a string in JDBC date escape format to a Date value.


 
iZEN ©   (2006-02-08 02:00) [66]

>kaif ©   (07.02.06 21:43) [65]
>еще хотелось бы понять, зачем изучать эту самую Джаву, если методы в ней >устаревают со скоростью света. Чтобы не быть голословным приведу хотя бы >список методов того же класса Date (который в sql), который у меня сейчас >перед глазамив в JAVADOC:
>
>getHours()
>         Deprecated.  
>int getMinutes()
>         Deprecated.
Вам надо книжку Джеймса Гослинга почитать.
Deprecated-методы — это т.н. "устаревшие" методы, которые возможно не будут поддерживаться в новых версиях Java, но вполне корректно работают сейчас (если почитать исходники, то можно увидеть, что вызовы этих методов часто подменяют "новыми" методами). Это нужно для обратной совместимости новых JRE со старыми приложениями, которые были написаны до 2000г.

В учебнике Гослинга, а так же в JDBC-руководстве есть раздел, посвящённый работе с датами. Там объясняется, почему есть два класса java.util.Date и java.sql.Date. Об этом нужно помнить.

И ещё.
java.util.Date — это несовсем подходящий класс для манипулирования временными отрезками и форматирования. Везде советуют использовать java.util.Calendar. Не будет проблем с временными зонами.


 
Evgeny V ©   (2006-02-08 09:04) [67]


> >kaif ©   (07.02.06 21:43) [65]
> >еще хотелось бы понять, зачем изучать эту самую Джаву,
> если методы в ней >устаревают со скоростью света.

Думаю это нормальное эволюционное явление, язык, система развивается, растет, исправляются недочеты. То можно сказать и об АПИ Windows, в MSDN можно встретить функции, о которых написано, что они оставлены для совместимости и лучше пользоваться другими. Тут скорее психологический момент, просто когда пишу на дельфи, то с этим обычно не сталкиваюсь, поскольку проблему выбора той или иной АПИ функции ОС как правило за меня решили разработчики языка программирования.   В JAVA выбираешь сам.


 
Lamer@fools.ua ©   (2006-02-08 09:14) [68]

>Тут скорее психологический момент, просто когда пишу на дельфи, то с этим обычно не сталкиваюсь

"Ага, конечно!" ©

Forms.pas:
function MakeObjectInstance(Method: TWndMethod): Pointer; deprecated; { moved to Classes.pas }
{$EXTERNALSYM MakeObjectInstance}
procedure FreeObjectInstance(ObjectInstance: Pointer);    deprecated; { moved to Classes.pas }
{$EXTERNALSYM FreeObjectInstance}

function  Subclass3DWnd(Wnd: HWnd): Boolean;     deprecated;  { obsolete }
procedure Subclass3DDlg(Wnd: HWnd; Flags: Word); deprecated;  { obsolete }
procedure SetAutoSubClass(Enable: Boolean);      deprecated;  { obsolete }
function AllocateHWnd(Method: TWndMethod): HWND; deprecated;  { moved to Classes.pas }
{$EXTERNALSYM AllocateHWnd}
procedure DeallocateHWnd(Wnd: HWND);             deprecated;  { moved to Classes.pas }
{$EXTERNALSYM DeallocateHWnd}
procedure DoneCtl3D;                             deprecated;  { obsolete }
procedure InitCtl3D;                             deprecated;  { obsolete }


 
Sandman29 ©   (2006-02-08 09:19) [69]

kaif ©   (07.02.06 21:43) [65]

Я как-то в модуль добавил uses Graphics и стал получать кучу ошибок о несовместимости TBitmap.
Но это еще фигня.
Если в unit2 есть procedure F и в unit3 есть procedure F, то в unit1 становится очень важен порядок перечисления этих модулей в uses. Причем даже warning не выдается!


 
Evgeny V ©   (2006-02-08 10:03) [70]

Lamer@fools.ua ©   (08.02.06 09:14) [68] LOL
Это только подтверждает - что все развивается,  в том числе и дельфи:-)))
пользуйтесь другим.:-)))


 
kaif ©   (2006-02-08 10:05) [71]

Я всего лишь делюсь своими впечатлениями от Джавы. Если бы я был адептом джавы, то, разумеется, нахваливал бы ее, так как вряд ли кто-то может стать адептом в области, которая ему не нравится. Поэтому для меня мнение "непрофессионалов" в каком-то смысле объективнее, чем мнение адептов, если речь идет о предпочтениях.

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

Дело в том, что в основном я работаю в связке Delphi+Firebird. Но возникла срочная и очень сложная (по самой задаче) работа, в которой требованием заказчика была связка JAVA + ORACLE (сервлетное приложение для Tomcat). Так что мне пришлось в сжатые сроки (полтора месяца) осваивать практически с нуля как JAVA, так и ORACLE.

Так вот против JAVA у меня не было никакого предубеждения. Более того, читая книгу Хортона, я проникся восхищением к ряду моментов (DAVADOC, поддержка UNICODE, стиль объявления и имплементирования интерфейсов и т.п.). А к ORACLE у меня было предубеждение, так как я не очень люблю монстрические и дорогие продукты.

Однако когда я стал реализовывать саму задачу, с каждым днем ORACLE у меня вызывал все больший восторг, как по своим возможностям, так и по логике, которая заложена в ORACLE, как технологию.  А с JAVA происходило нечто прямо противоположное. Ряд разочарований, осложнений и изматывающая борьба с простыми вещами, несовместимость версий, плохая переносимость, несмотря на все заверения, невнятные сообщения об ошибках, глупости реализации простейших типов (вроде той же даты в миллисекундах) в какой-то момент стали переполнять чашу моей терпимости и позитивности, которая, видит Бог, достаточно глубока.

Не скажу, что мне не нравится JAVA. Просто я вижу целый ряд неудобств, просчетов и недостатков, от которыъх свободны многие коммерческие продукты.

Например, что касается обработки событий, то в Object Pascal это организовано намного изящнее. Я могу в Object Pascal, как, впрочем и в СИ, объявить прототипы структур или типизированные указатели на процедуры и методы:
type
 PMyRecord = ^TMyRecord;
 TMyRecord = record
    a: integer;
    b: array [0..3] of byte;
 end;

 myprocedure = procedure(a: integer; b: PChar);

И вообще предварительные определения в интерфейсах или заголовочных файлах (прямо в модуле), возможность объединять тексты классов в модули (файлы), все это мне кажется удобным и логичным.

В JAVA все это (или почти все) запрещено. К сожалению.
Непонятно, что препятствует, например, тому, чтобы ряд классов объявлялся в одном текстовом файле? Неужели хранение каждого класса в отдельном файле это требование ООП? Это же кошмар какой-то... А эти "дружественные" классы в пределах пакета?... Когда при попытке создать потомка от какого-нибудь "внутреннего" для пакета класса сталкиваешься с проблемой того, что ряд вещей доступен из пакета, но не доступен извне, только потому что они "вне пакета". Это что, парадигма ООП? Очень сомневаюсь.

Если бы джависты занялись издательством книг, то неужели они потребовали бы писателей помещать каждый абзац (или каждое предложение) в отдельную книгу с переплетом, а затем еще все это переплетать вместе, засовывая в целлофан марки "zip", переименованный в марку "jar" ?

Так что к джава у меня как ряд одобрений, так и ряд нареканий. Мне кажется, что в джава часто скудность мышления и убогость маскируется громким термином ООП. Я не вижу изящества в JAVA, особенно в синтаксисе, предложенном в JDK 1.5 с их типизациями в объявлениях(<String>,<Key>) и т.п. Вообще проникновение угловых скобок в программирование, ИМХО, портит все, что только можно было испортить. Когда смотришь на такие вещи, не очень-то понимаешь, какого черта это все понадобилось. Не проще ли было смириться и ввести тип variant? У меня код, работающий под JDK1.4 компилируется под JDK1.5 со страшными хинтами вроде "unsafe methods", а при переделке под JDK 1.5 (вставляю все эти уродские <String> в простые команды типа new ArrayList()), перестает компилироваться под 1.4


 
Sandman29 ©   (2006-02-08 10:20) [72]

kaif ©   (08.02.06 10:05) [71]

1. Я не адепт Java и знаю его гораздо хуже Delphi.
2. Почитайте про protected. Доступно и из пакета, и из потомков.
3. Дублирование объявлений в interface и implementation - очень плохая идея. Даже в C# от нее отказались.
4. В одном файле можно объявлять кучу классов. И вложенных, и обычных. Только они будут private.
5. <type> - мощнейший контроль типов. Delphi с его Variant отдыхает.
6. А при переводе проекта с Delphi 3 на Delphi 7 Вы тоже требуете, чтобы новую версию можно было загружать в старом IDE?


 
Evgeny V ©   (2006-02-08 10:46) [73]


> kaif ©   (08.02.06 10:05) [71]
>
> Вообще проникновение угловых скобок в программирование,
> ИМХО, портит все, что только можно было испортить


Ну вообще-то это было еще и до JAVA, в том же С++ шаблоны templates. библиотека STL например. Кстати шаблоны (Generic классы) просто стали поддерживаться с версси 1,5 в JAVA, если конечно не ошибаюсь.

Кстати я так же как и Вы сталкиваюсь со многими из тех проблем, что вы описали. Но пока считаю их все же больше своими проблемами плохого знания языка. Но честно говоря мне нравится язык, меня больше беспокоит то, что мне еще трудно ориентироваться в технологиях JAVA, J2EE в частности. Очень много разнообразных продуктов и мне как мало знающему в этой области просто невозможно оценить эффективность того или иного. С MS продуктами в этом плане проще, тут просто нет выбора (шутка, выбор есть конечно):-)).  Советы профессионалов отличаются друг от друга зачастую, но оно и понятно, вкусы у всех разные.
Мне кажется, что так же много можно услышать нареканий и тех, кто после дельфи переходит например на MFC и С++, и как я и говорил про скобки <> тоже:-))


 
seg   (2006-02-08 10:55) [74]

kaif ©   (08.02.06 10:05) [71]

Согласен полностью.


 
Evgeny V ©   (2006-02-08 11:29) [75]

Кстати, увлекся и забыл

> kaif ©   (08.02.06 10:05) [71]
> Непонятно, что препятствует, например, тому, чтобы ряд классов
> объявлялся в одном текстовом файле?
</I

Можно объявить в одном файле несколько классов, ограничение есть на то, что public один класс в этом файле.  Кстати, думаю что все равно не смогу убедить проивников языка, но объяснение почти всех выше приведенных Вами вопросов к языку JAVA, ну кроме <> , рассматриваются в книге Кея Хорстманна и Гарри Корнелла "Библиотека профессионала JAVA2 " Том1 "Основы". Буквально на первых 130 страницах (ну побольше конечно)рассматривается большинство их перечисленного вами. Когда я сам читал, что и как и почему решили убрать из языка- сожалел (сам начинал писать на С, потом С++), что нет того или иного, но тут или смириться или понять, или писать на другом языке, другой платформе.:-))


 
Sandman29 ©   (2006-02-08 11:46) [76]

Evgeny V ©   (08.02.06 11:29) [75]

Настолько увлеклись, что не заметили [72].4 :)


 
kaif ©   (2006-02-08 11:51) [77]

Вот со вчерашнего дня бьюсь с кодировкой.

jsp-страница под Tomcat 4.1. Специально оговариваю версию, так как с "переносимостью" в JAVA дело выглядит примерно так: если у тебя и у заказчика не стоят идентичные версии Tomcat и jdk, а также идентичные настройки локалей - жди больших проблем.

Итак, Tomcat + jdk 1.4.
Нужно получить кодировку UTF-8. Вообще я использую на всех страницах

<%@ page contentType="text/html;charset=windows-1251" %>

Но конкретно эта страница должна быть в UTF-8, так как она создает поток типа xml-файла для Excel:

response.addHeader ("Content-Disposition", "attachment; filename=report.xml");


А этот Excel свой родной ANSI не ест в этом типе файла, а требует именно UTF-8.

Танцы с бубнами продолжаются со вчерашнего вечера.

<%@ page contentType="text/html;charset=UTF-8" %>

превращает весь русский текст в квадраты. Оно и понятно. Откуда JAVA может знать. в какой кодировке у меня символы в тексте jsp?
Пытаюсь сделать так:


<%
String aaa = "Вася";
byte[] utf8Bytes = aaa.getBytes("UTF-8");
String aaa2 = new String(utf8Bytes, "UTF-8");
out.print(aaa2);
%>


Ура!!! Вместо квадратов теперь вопросы.
Перебираю разные варианты, но добиться результата пока так и не удалось.

Уважаемые поклонники джава!
Я не прошу объяснять мне решение.
Я лишь прошу дать ссылку на источник, где описано ясное, внятное и надежное решение этой проблемы.
Можно на английском.


 
DiamondShark ©   (2006-02-08 11:54) [78]


> Непонятно, что препятствует, например, тому, чтобы ряд классов
> объявлялся в одном текстовом файле? Неужели хранение каждого
> класса в отдельном файле это требование ООП? Это же кошмар
> какой-то... А эти "дружественные" классы в пределах пакета?
> ...

Если когда-то изобретут машину времени, то первого, кого надо придушить на стадии бластулы -- это Страуструп.
Героин и порнография не погубили столько невинных душ, сколько эта гнусная зараза с плюсами.


 
Sandman29 ©   (2006-02-08 12:03) [79]

kaif ©   (08.02.06 11:51) [77]

http://forum.java.sun.com/thread.jspa?threadID=539309&tstart=0
4 и 5 ответ пробовали?

PS. Никогда не работал с jsp :)


 
pasha_golub ©   (2006-02-08 12:04) [80]


> См. http://izen.dev.juga.ru/downloads/swingexamples.zip


> iZEN ©   (07.02.06 18:27) [64]

Прошу прощения, у меня таймаут. Это я так понимаю код? Я бы очень был благодарен за скриншоты, ну прямо "безмежно" (укр., "безгранично").
Спасибо



Страницы: 1 2 3 вся ветка

Форум: "Прочее";
Текущий архив: 2006.03.05;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.67 MB
Время: 0.271 c
15-1139542859
Бугага
2006-02-10 06:40
2006.03.05
Barry Manilow - Mandy


1-1138535882
Igor_thief
2006-01-29 14:58
2006.03.05
Photoshop brushes


2-1139161960
CMOS
2006-02-05 20:52
2006.03.05
Начала ООП


2-1140072156
Wolferio
2006-02-16 09:42
2006.03.05
Ошыбка открытия базы


15-1138282786
Dec
2006-01-26 16:39
2006.03.05
Точка прерывания





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский