Вот натолкнулся на файлик, примерно понятно что хотят, но как это перевести на C# не доходит. Ну нельзя в интерфейс кроме определения засунуть имплементацию. Как тогда понимать этот интерфейс с точки зрения Явы?
И как в Яве различают: public String name() и private String name?

public interface RelationalOperator {
    public static abstract class RelationOperatorImpl implements RelationalOperator {
        private String name;
        private RelationOperatorImpl(String name) {
            this.name = name;
        }
        
        public String name() {
            return name;
        }
    }
    
    public final static RelationalOperator EQUALS=new RelationOperatorImpl("=") {
        public void apply(Constraint constraint) {
        }        
    };
    public final static RelationalOperator IDENTITY=new RelationOperatorImpl("ID") {
        public void apply(Constraint constraint) {
            constraint.identity();
        }        
    };
    public final static RelationalOperator SMALLER=new RelationOperatorImpl("<") {
        public void apply(Constraint constraint) {
            constraint.smaller();

        }        
    };
    public final static RelationalOperator GREATER=new RelationOperatorImpl(">") {
        public void apply(Constraint constraint) {
            constraint.greater();
        }        
    };
    public final static RelationalOperator LIKE=new RelationOperatorImpl("~") {
        public void apply(Constraint constraint) {
            constraint.like();
        }        
    };
    
    public static RelationalOperator[] OPERATORS= {
        EQUALS,IDENTITY,GREATER,SMALLER,LIKE
    };
    String name();
    void apply(Constraint query);
}

А тут и не засунута в интерфейс имплементация. Тут просто очередной говнокодер впихнул в интерфейс "внутренний" класс и кучу анонимных подклассов этого внутреннего класса (ну и заодно на соглашения об именах наплевал)
по-человечески здесь один интерфейс с 6-ю константами и двумя методами:
public interface RelationalOperator {
public final static RelationalOperator EQUALS=...
public final static RelationalOperator IDENTITY=...
...
public static RelationalOperator[] OPERATORS= {
EQUALS,IDENTITY,GREATER,SMALLER,LIKE
};
String name();
void apply(Constraint query);
}
Абстрактный класс, реализующий метод name() (и оставляющий метод apply(Constraint) абстрактным):
public static abstract class RelationOperatorImpl implements RelationalOperator {
private String name;
private RelationOperatorImpl(String name) {
this.name = name;
}

public String name() {
return name;
}
}
И при определении всех констант еще и создается для каждой константы анонимный внутренний класс (компайлер его потом обзовет вроде RelationalOperator$1) - подкласс RelationalOperator.RelationOperatorImpl
Фсё.
А отличается обращение к методу и к полю в яве - по скобочкам. Напишешь name() - значит метод, напишешь name, значит поле. Делать имена методов одинаковыми с имена полей в яве не приветствуется.

Ну у "нас" и константы не положены, не говоря уже о "внутренних" классах.
Да и анонимный класс при определении readonly поля не проканает.

$1 - эти фиговины тоже вызывали вопросы, но с ними можно было бороться...

То бишь, у "вас" можно теоретически совмещать имена методов и полей?
У "нас" так будет прокол при использовании "указателя" на фукнцию, там только имя функции положено.

Так как интерфейс тоже класс, а внутри класса можно определить новые классы...
Эт что, в 8-й яве теперь для методов в интерфейсах можно "дефолтную" реализацию делать. Да здравствует множественное наследование, так сказать.

В яве - где угодно. Если можно написать new, то в этом месте можно анонимный класс определить.

да хоть с именем класса. Как заставить всех себя ненавидеть:

public class a {
  public int a = 0;
  public int a() {
    return a;
  }
  public void b(){
    a a = new a();
    this.a = a.a();
  }
}

Но все же до перла яве далеко...

Вот, указатели - зло :)

Не зря я все таки Яву недолюбливаю.
Так а чем же тогда отличается Ява интерфейс от Ява класса?

ну в манагед "привычных Си" указателей всеже нет. Все происходит "за забором".
a.OnReady+=FunctName;

Вот, указатели - зло :)
-----
Нее, указатели это - хорошо... плохо - это когда с ними работают не те кто должен...

Писать на шарпе и недолюбливать яву, с которого он содран чуть более чем полностью, это нормально, в стане сионистов все малохольные :) Когда после с++ и дельфей я начал на яве писать (даже без ide)... Это было щастье. А потом допилили java-mode для имакса, и все стало еще лучше.

А ничем. Он же ж и так класс. Но особенный! :)
Интерфес (до 8-й) - полностью абстрактный класс. header. В нем только определения методов и констант. Никаких реализаций методов. Логику нельзя запихать даже в блок инициализации, только в инициализации констант может быть вызов метода или конструктора.
Интерфейс - только public. Все методы - public abstract, все поля, декларируемые в интерфейсе - public static final.
Интерфейс может наследовать от нескольких интерфейсов. Класс - только от одного класса (так как реализаций методов в интерфейсах нет, то и не важно если у двух предков есть методы с одинаковым именем, коллизий не возникает). Класс может реализовывать несколько интерфейсов.
Что еще... Интерфейс не может быть final, иначе он не имел бы смысла, зачем определять интерфейс если его реализовывать нельзя.
Что они в 8-ке сделали с дефолтными методами пока руки не дошли разобраться.

Это высказывание, что то типа картинки медведя в шапке ушанке со звездой
Недавно где то видел слайды какие языки разработчики рассматривали подробно при создании с# и вроде Явы там не припомню.
Ну да ладно, религиозные войны вроде нам ни к чему.

Было бы нормально, (хотя о наличии констант можно было и подискутировать) если бы в качестве констант можно было пользовать только примитивные типы.
Но константа с "new" - сорри.
А каким местом тогда разрешено в интерфес впихивать другой класс?

Какого писать публик если другой модификатор невозможен?
И эти комбинации, особенно со static и final запутывают полностью, так как лепят их куда попало.
Пока запомнил только правило перевода для полей: static final <primive type> ----> const остальное readonly

А то. И с балалайкой :) А если честно, синтаксис первой версии шарпа сильно напоминал яву. Казалось, что облажавшись с J++ мелкомягкие пытаются хоть тут отыграться.

А какая логическая разница? неизменяемое значение и все тут. Разница в реализации в яве есть. Константы примитивных типов и String в ней инлайнятся.

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

А его не надо писать. Компилятор автоматически расширяет описание полей и методов. Пишется часто просто по привычке, пальцы сами public набирают.
Сделали так - методы всегда public abstract поля - public static final. Напишешь что-то другое - получишь ошибку. Хочешь явно написать - пожалуйста, не запрещено.

Вот тут не понял. Что запутывает и кто лепит?

Где-то так. На всякий случай, вдруг в шарпе поведение у const другое, хотя врядли понадобится, но на всякий случай...
Я уже упоминал что в яве "константы" примитивных типов (и строки) инлайнятся. Если чуть глубже копнуть, то это не совсем так. Инлайнится только те, поля, значение которых можно просчитать во время компилирования. Называют такие инициализации "constant initializer" или "compile-time initializer". Т.е. если есть final int x = 10; то компайлер везде обращение к этому x поменят просто на 10. А если final long x = System.currentTimeMills(); то везде ссылка на поле x останется, потому как во время компиляции компайлер не может посчитать чему будет равно System.currentTimeMills().

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

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

Да все теже Ява проггеры, сиди потом и думай как это перевести, то там поставят то сям.
private static final int DEFAULT_REFRESH_DEPTH = 5;
public final static RelationalOperator EQUALS=new RelationOperatorImpl("=") {
public static abstract class RelationOperatorImpl implements RelationalOperator {
private static transient - -Container db;
private static transient final String preferencesFile = new File(new File(System
private void initControl() {
final String converted = input == null ? "" : (String)converter2String.convert(input);
ui.setText(converted);
}
public static InputStream construct(final String rawMaterial) {

Воо - вот это и есть константы, все остальное от дяъвола

Строго говоря констант в яве нет вообще. Есть "поля, инициализируемые один раз" - final (readonly). Константами принято называть static final-ы. То что часть из них и правда константы, к которым мы привыкли во многих других языках, от "нормального" разработчика скрыто. Так что да, финальное поле может быть проинициализированно не цифрой 5 а, например, списком.
public static final List<String> ICE_CREAM_NAMES = new ArrayList<String>(); // в поле класса хранить изменяемый список - фи. Опасность утечки памяти. Но синтаксис позволяет.
Такая конструкция - не константа "список из 5 имен мороженного" (хотя можно добиться и такого с помощью неизменяемых списков, лучше все равно enum сделать), а просто подсказка - что это ссылка на список, хранящаяся в этом поле, никогда не изменится. Так что можно смело ее использовать, null-ем она не станет никогда. Ну и запрет ее менять, чтобы не получилось что у кого-то осталась ссылка на другой, старый список. Ну и многопоточный доступ к final-ам оптимизируется, но это уже технические подробности.

Не, не так. Такой вложенный класс это простой отдельный класс. С необычным именем. Если в интерфейсе a.b.c.X определить внутренний класс Z то его полное имя - a.b.c.X.Z
Такие классы - указание на то, что они нужны только для класса - родителя. Еще один способ группировать классы - не только по пакетам, но и по классам (опять же только если внутренний класс нужен исключительно родителю). Если такой вложенный класс еще и публичный - то доступ к нему имеют все остальный классы. Представлены такие классы таким же обычным объектом типа Class как и все остальные. Так что с точки зрения компилятора определение такого статического вложенного класса можно было смело выносить в другой файл - разницы (кроме имени) не будет.
Для обычных классов такие внутренние и вложенные (да, есть разница :) см. nested и inner) классы - удобны. Например, если если интерфейс IListener, с методом, например, IProcessor getProcessor() и этот процессор имеет смысл только для конкретного листенера, вот тогда и делаем в классе MyListener вложенный класс Processor, и в классе AnotherListener тоже Processor. И получаем два процессора - MyListener.Processor и AnotherListener.Processor уже из имени которых понятно кому они принадлежат, и где используются.
ИМХО, было бы лучше если бы в интерфейсах внутренние классы (но не интерфейсы) были бы запрещены. Как и вообще анонимные классы. Но, для агильных вьюношей "а дайте мне возможность писать 1 нечитаемую строчку вместо 3-х понятных" - оставили и такое.

Ну это несерьезно. Это как жаловаться на сионистов, которые то там то сям своих звездочек с амперсандами поналепят. (а вот на перлистов с их $??!$_$@$?!$? и прочими красотами - надо жаловаться :))
во всем этом есть смысл. И разобраться не сложно.
public - protected - <default> - private - ограничение доступа, тут все просто. static или нет, final или нет и пара модификаторов вроде transient, volatile для полей и strictfp для методов. И еще abstract для методов и классов - всё.
private static final int DEFAULT_REFRESH_DEPTH = 5; // Внутренняя константа для класса. Даже подклассы ее не видят (и никаких friend-ов!)
public final static RelationalOperator EQUALS=new RelationOperatorImpl("=") {..} // доступное всем ro поле класса инициализированное объектом анонимного класса (подкласс RelationOperatorImpl)
private static transient - внутреннее поле класса, которое не сохраняется при сериализации.
private void initControl() { // обычный приватный метод
final String converted = input == null ? "" : (String)converter2String.convert(input); // ro переменная, с областью применения внутри метода. (а вот (String)converter2String.convert(input) - некрасиво. Если уже converter2String то могли бы и Generic-и использовать)
}
public static InputStream construct(final String rawMaterial) { // - обычный публичный метод класса
Никаких чудес. Что тут запутанного-то?
Если что-то конкретное непонятно - спрашивай, расскажу.

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

Об этом я как то и не подумал - важный момент.
А с мороженным имелось в виду немного другое. Что то типа этого
public static final List<IceCream> ICE_CREAMS = new ArrayList<IceCream>()
public class ICeCream
{
....
public Color GetColor() { return RandomColor();}
}
Похоже можно уже составлять кратуий справочник по Яве:
final - "поля, инициализируемые один раз" - (readonly)

Во, вот это и есть хреново Потому как кто то обязательно сделает фи раз можно. Хотя не исключен вариант "сделать фи" когда нельзя, но это уже другое будет.

Может я не совсем правильно понял но тогда процессору нефиг делать в интерфейсе. Или имелось в виду private/protected вложенные классы, где класс доступен только определенному классу/группе классов?

ну вот я и о чем - нефиг засорять интерфейс ненужными шмотками.

Ну этот типа как приезжаешь в другой город, а там постоянно получается в это время плохая погода. Разобраться то конечно можно, но когда Ява попадается раз в несколько лет для частных нужд, то искать часами что означает конкретная комбинация как то не имеет большого смысла. Это нужно постоянно писать на Яве хотя бы какое то время.
Иногда вот интересно взглянуть на внутренности apk, А сейчас вот ошибку ищу в использовании db4o, нужен нормальный редактор базы. Исходники вроде есть, но как обычно, "Ява" у меня не запускается с исходников, так решил просто на шарп перекинуть.
А там было несколько иное
static final - final static: Есть разница или нет?
static abstract class - нафига абстрактному классу статик? И не вижу аналога на шарпе.
final/static внутри функции - фиг переведешь
final для аргументов - зачем? Хотя пожалуй для классов можно было добавить readonly.

Каждому инстрУменту - свое место. Брюнетку - домой, блондинку - в клуб :)

Угу, я понял. Пример со стрингом чтобы понагляднее, покороче было.

Именно так. Потому и final - "окончательное значение".

Тут такое дело... Что мне в яве нравится - у нее есть своя логика. И не так много мест где "вообще-то так, но в случае если ... при условии что..." и те де. Поэтому если решили что final-ы можно инициализировать вызовом методов или конструкторов, то ограничивать типы, какие могут быть final, а какие нет - не разумно.
Ну а что уже "фи" выяснилось со временем. Те же списки, мэпы, множества и прочие контейнеры создают проблемы в static final-ах только если не контролировать как он наполняется. Привыкнув к тому, что в яве со всем ненужным мусором справляется GC, мало кто вспоминает что не надо пихать кучу объектов в поле класса - пока загрузчик классов не уничтожится, эту память не освободить. А контролировать можно, например, используя "неизменяемые" контейнеры. Делаешь, например, неизменяемый мэп от имени к объекту, и быстрый доступ - O(1) - к объекту по его имени.

Не совсем. IListener и IProcessor в моем примере были два разных интерфейса. В примере были классы, реализующие эти интерфейсы.
Но. Интерфейс вложенный в интерфейс - тоже имеет право на жизнь. Например, в яввской стандартной библиотеке в java.util.Map если внутренний интерфейс Entry. И четко понятно что написав Map.Entry мы имеем в виде запись в мэп. Можно было бы добиться того же сделав java.util.map.Map и java.util.map.Entry, но зачем.
А так да - классам, логике в интерфейсах делать нечего. В изначально примере, с которого мы начали, вообще интерфейс лишний. Я бы сделал enum :)

нет

Хе. А вот тут мы подходим к вложенным и внутренним классам :)
Такое определение возможно только у вложенного класса (определенного внутри тела другого класса). static class говорит нам что этот класс вложенный (определен внутри другого) но не внутренний (внутренний был бы без static). Разница - в доступе к полям класса-родителя. У вложенного (static nested) класса никаких преимуществ нет. У внутреннего (inner) - есть. Внутренний существует только внутри объекта, и имеет доступ к полям объета, даже если они приватные.
Так что тут определен вложенный абстрактный класс.

static внутри методов - иззя. final означает то же самое что и не в функции - что переменная инициализируется один раз. Еcли надо контролировать что это значение случайно сам не перепишешь.
Или если надо проконтролировать что ты не забыл проинициализировать переменную.

final boolean isEqual;
if(...){ // 1
  if(...){ // 2
    isEqual = true;
  } // <-- а вот тут мы забыли else и если (2) будет false, то наш isEqual не проинициализируется. Компайлер сообщит об ошибке.
// а если мы тут напишем isEqual = true, то компайлер опять ругнется = скажет что переменная уже возможно проинициализирована.
} else {
  isEqual = false;
}

Для аргументов методов? Чтобы случайно не переопределить. Лично я часто использую (почти везде, где значение аргумента не должно меняться). Помогает тупых ошибок избегать.

class X {
  private int a;
  public void setA(int a){
    a = a; // ничего не произойдет. поле a класса не изменится, мы забыли this.a написать.
  }
  public void setA2(final int a){
    a = a; // а тут компайлер кинет ошибку.
  }
}

очень похоже что static имсеет в Яве совсем другое значение чем мне кажется.
То бишь у нас static класс означает, что него нет this и все методы у него static также (также нет доступа к this ). Иначе говоря просто контейнер функций.
static переменная класса означает что на все инстансы у нее будет одно и тоже значение и для доступа к ней this также не нужен.

Да нет, почему. Static показывает что поле, метод или внутренний класс принадлежат классу, а не объектам класса.
static поле - как и в шарпе, "означает что на все инстансы у нее будет одно и тоже значение и для доступа к ней this также не нужен".
static метод - для его вызова не нужен объект, вызывается у класса, у него нет доступа к не-static полям и методам класса.
А вот static класс отличается от шарпа. В яве static класс может быть только у вложенного класса, "нормальный" класс в яве static быть не может. У вложенного класса static означает примерно как у метода - такой класс имеет доступ только к статическим полям класса-родителя. Не-статический вложенный (внутренний) класс существует в рамках объекта, он "внутри" объекта, потому имеет доступ к объекту - к его приватным полям, приватным методам.

Все таки есть отличия, но теперь ты меня подковал и надеюсь что эти "подлые" Ява программисты не будут меня больше терзать static-ом и final

Корни С# растут из Борланда и Дельфи.
С жабы он содран только тем, что команда разработчиков перебирала синтаксис наиболее известных языков, в том числе и жабы, и рассуждала, что нравится, а что нет.
Например, определение всех возможных исключений в throws, было признано избыточным и не всегда работающим.

Так получилось что я писал и на борландовском с++ и на дельфях (и даже на Turbo Pascal-е...) и на яве. Но когда я первый раз увидел шарповый код... Вопрос был один - "кто вместо import using написал?".
Вот шарповый и явовский HelloWorld, найдите три отличия, называется.

using System;                                                 
public class Hello2                                            public class Hello2
{                                                              {
   public static void Main(string[] args)                        public static void main(String[] args)
   {                                                             {
      Console.WriteLine("Hello, World!");                          System.out.println("Hello, World!");
   }                                                             }
}                                                              }

В смысле? Явовское

public void doSomething() throws MyException, YourException, AnotherException

не всегда работает? А что вы понимаете под "не работает", и когда именно это не работает?

Не могу вспомнить подробности, но при каких-то сложных наследованиях в Яве, можно не перечислять некоторые исключения, которые может "выкинуть" метод.

Ерунда. Просто вы не поняли что такое checked и unchecked Exception. Подклассы RuntimeExeption и Error в throws перечислять не надо. Можно но не обязательно.
Во всех остальных случаях попытка в методе бросить Exception не перечисленный в throws приведет к ошибке при компиляции.