Вопрос по java – Почему метод main в Java всегда нуждается в аргументах?

24

Почему основной метод в Java всегда нуждается в аргументах? Почему мы должны писатьString[] args каждый раз, вместо того, чтобы просто писать это, когда мы используем какие-либо аргументы?

Такой метод генерируетMain method not found ошибка компилятора. Поскольку мы никогда не используем аргументы для метода main, это должно быть разрешено.

public static void main()
{
}

Это не вопрос интервью. Это просто пришло мне в голову во время программирования.

Он скомпилируется, но выдаст ошибку времени выполнения. Pooja
Кстати, JAVA это не аббревиатура. Они (Солнце) назвали язык в честь кофе Ява. Хотя некоторые люди переводят аббревиатуру на Java, например, Просто еще одна смутная аббревиатура Michael Buen
С наследством. Вы могли бы использоватьmain(String... args) так что вы можете позвонитьmain() но это не твой вопрос. Joop Eggen

Ваш Ответ

8   ответов
-1

Он может быть таким, как большинство входных данных поступают извне main (), например, из аргументов командной строки, поэтому, чтобы перехватить эти значения, он имеет сигнатуру аргумента String [].

-1

Я думаю, что Java "скопирована" эта привычка из c / c ++ и жестко запрограммирована в java.c:

  /* Get the application's main method */
  mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
                                     "([Ljava/lang/String;)V");
  if (mainID == NULL) {
      if ((*env)->ExceptionOccurred(env)) {
          ReportExceptionDescription(env);
      } else {
        message = "No main method found in specified class.";
        messageDest = JNI_TRUE;
      }
      goto leave;
  }
-1

когда вы пытаетесь запустить программу Java, JVM будет искать основной метод сString array в качестве аргумента, чтобы начать выполнение программы оттуда. Поскольку метод, который вам дан, не имеет этой подписи, он вызовет исключениеNo main method found

0

Когда JVM начинает выполнять программу Java, она ищет метод main, имеющий эту сигнатуру (т. Е. Массив строк).

31

В основном, есть четыре ответа:

  1. Because that's the way it was designed. Yea, I know that's a circular reason. But the point is that this is the way it is and it ain't going to change. So unless you are planning on designing your own language, the question is moot.

  2. Cleanness of design (aka the DRY principle). Don't specify two entry point signatures when one can do the job. And clearly, it can.

  3. Semantic simplicity. Suppose (hypothetically) that Java did support both void main(String[]) and void main() entry points. What would happen if a class defined both methods? Is that an error? If not, which one takes precedence when there is ambiguity? Is this confusing yet?

    By only allow void main(String[]), the JLS avoids the problem.

  4. This is analogous to the standard C and C++ entrypoint signatures. (Admittedly, some C / C++ runtimes support other non-standard entrypoints as well ... but that's not exactly a good thing ... IMO.)

Ничто из этого не означает, что было бы однозначно неправильно делать это по-другому. Например, C # предоставляет альтернативные подписи и решает проблему неоднозначности, требуя от разработчика обозначить точку входа другим способом.

FWIW,эта страница википедии описывает «основной» метод на нескольких языках.

Error: User Rate Limit Exceededmain()Error: User Rate Limit Exceeded
5

Посколькуjava инструмент, который запускает приложение ищетmain с определенной подписью, поэтому он знает, что он называет правильную. В Java есть перегрузка методов, поэтому при поиске метода необходимо указать довольно полную сигнатуру. Предоставилjava инструмент может сделать что-то более сложное (искать конкретную подпись и, не найдя ее, искать любуюmain и назовите его, если он только найдет один), но это не то, что разработчики Java решили сделать (иsubjectively, FWIW, я думаю, что это к лучшему & # xA0; & # x2014; будь проще).

Вы можете найти подробности в спецификации языка Java,Глава 12: Выполнение, И обратите внимание, что с тех пор, как Java получила списки переменных аргументов, стало возможным объявитьmain двумя разными способами:

public static void main(String[] args)
// or
public static void main(String... args)
Error: User Rate Limit ExceededjavaError: User Rate Limit ExceededmainError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded dejavu
0

Это просто так, как они это спроектировали. Вследствие этого вы можете спросить, почему его двоюродный брат (C #) допускает метод Main с параметрами или без параметров, просто так, как они его разработали.

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

Хм ... это напоминает мне об ОС, которую я сейчас использую. До OS X Lion вы можете изменить размер только в правом нижнем углу окна. Это более 28 лет ожидания, прежде чем они, наконец, установят возможность изменения размера в любых углах окна своей ОС.

Даже если я слишком люблю Mac OS, я бы не стал защищать их позицию до того, как размер окна можно будет изменять только в одном углу. Фанатизм - это одно, а слепая приверженность - другое.

Так что хорошо, что вы практикуете критическое мышление и не слепо верите, что сигнатура основного метода Javathe only right way


Отступление, ожидая, что Mac будет иметь изменяемые размеры краев в любом углу, сродни мне, ожидающему, что у Java будет первоклассное свойство. Несмотря на имя JSON (JavaНотация объекта сценария, хотя, конечно, Javascript не является Java), инициализатор объекта C # (через инициализатор его свойства и инициализатор коллекции) имеет большее сходство с JSON по сравнению с инициализатором объекта Java с JSON. C # инициализатор объекта очень аккуратен и очень похож на JSON.

C #

var p = new {
    Lastname = "Lennon",
    Firstname = "John",
    PlacesBeen = 
        new[]
        {
            new { City = "Liverpool", Country = "England" },
            new { City = "New York", Country = "US" },
            new { City = "Tokyo", Country = "Japan" }
        }
};

return Json(p);

Javascript:

var p = {
    "Lastname" : "Lennon",
    "Firstname" : "John",
    "PlacesBeen" :             
        [
            { "City" : "Liverpool", "Country" : "England" },
            { "City" : "New York", "Country" : "US" },
            { "City" : "Tokyo", "Country" : "Japan" }
        ]
};

Следовательно, благодаря первоклассному свойству C # (не привязанному к методу) и инициализатору коллекции не только код становится лаконичным и аккуратным, но теперь он очень похож на то, что большинство разработчиков используют сейчас для формата обмена данными, то есть JSON.

Синтаксис инициализатора объектов Java далек от стиля JSON. Я не буду защищать решение проекта Java (например, синтаксис / дизайн свойства) в этом отношении :-)

Таким образом, в том же духе, в котором я не буду защищать дизайнерское решение разработчика языка Java относительно синтаксиса / дизайна свойств Java, я не буду защищатьpublic static void main(String[] args) & # X30C4;

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededideone.comError: User Rate Limit Exceededideone.com/rS1pkError: User Rate Limit Exceededideone.com/3lQjd
Error: User Rate Limit Exceeded dejavu
-1

Ява разработана таким образом. если мы не будем писать строковые аргументы [], то программа будет скомпилирована но это не будет работать.

Похожие вопросы