Не компилируется
 

Не хотел создавать ради этого новую тему, но после трёх часов ломания мозгов всё же решился. =) Мне стало интересно, смогу ли я декомпилировать игру и собрать её заново. Выбрал игрушку попроще, распаковал, декомпилировал, выбрал класс, над которым буду издеваться, попробовал его скомпилировать. Куча ошибок. Логически подумав над строками, в которых ошибки, пришёл к выводу, что там неправильно декомпилировались блоки try - catch, написал как надо, было ещё пара ошибок. С GOTO. Я вообще понятия не имею какой синтаксис у goto, так как юзал этот оператор только в бэйсике на БК 0100 1986 года выпуска и это было довольно давно. Но в итоге разобрался вроде, хотя там было непонятно весьма. Короче говоря, мне удалось скомпилировать класс без ошибок. Но ошибка возникла при верификации О_о
Playfield - это имя класса.
Компилировал через bat файл, который сам написал, через javac. Возможно у меня в команде bat файла ошибка, так как я до этого никогда не пытался скомпилировать классы, которые в итоге будут лежать на в корне jar. Там структура файлов в игре такая, что все классы не в корне, а в папке внутри jar лежат. Возможно я с путями что-то напутал, но мне кажется, что всё же причина в чём-то другом, так как когда я экспериментировал с путями, то ошибка не такая была. В общем, подскажите, в чём может быть дело. Если нужно, могу выложить саму игру и исходник, который получился у меня после исправлений.

Ответ: Не компилируется
 

преверификация важн для МЕ. она проверяет соответствие cldc 1.x, при компиляции какие параметры привызове javac?
а про папки, если в начале класса написано package com.mp;
то класс должен лежать в jar в папке com/mp

Ответ: Не компилируется
 

Параметры все верные написаны. Уже до этого много раз компилировал. package написан. Положил в папку, которая там написана - догадался =) Проблема не в этом. Или не совсем в этом. Мне кажется я всётаки накосячил где-то...
- - -
Вот что в bat файле написано:
cd src
..\com\bin\javac -g:none -source 1.3 -target 1.1 -classpath ..\tmpclasses;..\com\midpapi20.jar;..\com\cldcapi1 0.jar -d ..\tmpclasses bomber\Playfield.java
cd ..
com\preverify1.1.exe -classpath tmpclasses;com\midpapi20.jar;com\cldcapi11.jar -d classes bomber\Playfield

bomber - это папка. Playfield - класс. Первая часть - компиляция - работает, создаётся класс файл в tmpclasses\bomber\. Вторая часть - верификация - не работает, выдаёт вышеупомянутую ошибку.

Ответ: Не компилируется
 

Вот исходник (уже подправленный).

Ответ: Не компилируется
 

Исходник как раз нормальный. У тебя в preverify какой класс проверяется? В какой он папке лежит? В tmpclasses. А где она показана prevefiry? пиши тогда уже tmpclasses\bomber\Playfield

Ответ: Не компилируется
 

То же самое. Класс-то находит, так как если я от балды введу имя класса, то ошибка другая:
Там внутри класса объявляется ещё один небольшой класс. Может что-то с этим связано? Я такого ещё не встречал. Может на его имя почему-то ругается?

Ответ: Не компилируется
 

Вот сама игра. Там, внутри джар архива исходник Playfield лежит. Попробуй скомпилировать у себя, может получится.

Ответ: Не компилируется
 

Уахууууууууууууууууууууу!!! Получилось скомпилировать через НетБеанс!!! Только вот очень заумно! Создал новый проект, скомпилировал мидлет по молчанию. В папке с проектом создались нужные папки. Ну я тупо их открыл, положил везде, где нужно и не нужно классы от игры, положил в src\bomber исходник Playfield, закрыл проект в НетБеансе, открыл его же, скомпилировал (!!!) без ошибок, потом вручную поменял манифест в джар архиве, добавил ресурсы и т. п. И ИГРА ПОШЛА НА ЭМУЛЯТОРЕ КАК НИ В ЧЁМ НЕ БЫВАЛО!!! WOOOW!!! В такие моменты я обычно говорю: "Вот оно - счастье!" =) Если игра была обфусцирована, то я ожидал большего, если уж я все корявости сумел исправить в декомпилированном классе, значит это не так уж и сложно... Но всё таки я не понимаю, где у меня ошибка с javac...

Ответ: Не компилируется
 

Ээх... Декомпилировал какой-то мод оперы мини. Пару самых маленьких классов скомпилировать получилось, но дальше начались проблемы. Не видит переменные в других классах. Вот там видимо жёстко обфусцировано. Декомпилятор, наверно, запутался и что-то не так декомпилировал. Жаль... Я уж на радостях подумал, что теперь что угодно смогу декомпилировать-скомпилировать =)

Ответ: Не компилируется
 

Я уже спрашивал, но вроде никто не ответил. Есть у меня классы g.class и b.class. В g.class объявлен метод readRes(), а в b.class объявлена переменная Graphics g.
В итоге, если я хочу обратиться из класса b к методу readRes(), вот так:
g.readRes("/res");
то компилятор выдаёт ошибку, так как у меня в классе b есть переменная g. То есть путаница видимо происходит.
Вопрос: как мне вызвать readRes() из класса b, не меняя названий переменных и классов?

Ответ: Не компилируется
 

Метод как я понимаю статический? У тебя локальная переменная закрывает глобальную. Лучше учись давать классам и переменным осмысленные имена. А так создай экземпляр класса
g newG = new g();
newG.readRes("/res");
через ж.., но хоть что-то

Ответ: Не компилируется
 

Ы, мне знакомые говорят, что я обфускатор ходячий. Я не знаю почему, но я всегда даю переменным короткие имена 1-3 буквы. Потом все говорят, что у меня код нечитаемый =) Но для меня переменные осмысленные, гг. Просто я максимально сокращаю, например, вместо left_key я бы создал переменную l, а если она занята, то переменную lk. =)
- - -
Так, а если метод не статический объявлять (я этого никогда не делал), то что это меняет в структуре программы? Что лучше использовать (в плане потребления и фрагментирования памяти, быстродействия и т. п.)?

Ответ: Не компилируется
 

а если метод не статический, то это делать обязательно

Ответ: Не компилируется
 

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

Ответ: Не компилируется
 

если у тебя библиотека с функциями, то разумнее использовать как раз статические методы, а вот если класс наследник чей-то или интерфейсы имеет то тут без экземпляра не обойтись.
ЗЫ: Статические методы быстрее обычных.