• Суть виртуальной машины Java?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Тут дали уже много хороших и правильных ответов, но хотелось бы уточнить, что вот эта метафора:
    Виртуальня машина java это тоже интерпретатор по сути

    может направить по весьма ложному пути!

    У слов в названиях есть достаточно точный смысл, и JVM называется именно машиной, а не интерпретатором, и не компилятором совершенно не случайно. Компилятор в Яве есть (javac), и он нужен не для выполнения программы, а именно для ее компиляции (в байткод). Имено поэтому он не входит в состав JRE (среды выполнения), а содержится в JDK (среде разработки). В самой JVM есть еще один, JIT-компилятор, который компилирует байткод в инструкции процессора во время выполнения программы, но это уже другая история, и его тоже никак не назвать интерпретатором.

    По сути JVM - это процессор, только виртуальный. И как у любого процессора (железного, типа x86, или виртуального, типа CLR в .NET), у него есть свой набор опкодов, называемый байткодом. Так же точно, как на х86 может выполняться код, порожденный компилятором с C++, или Pascal, или Go, так же и на JVM может выполняться байткод, скомпилированный из Java, или Scala, или Kotlin (или даже написанный вручную), а .class -файл, это, по сути, тот же .exe (точнее .so), скомпилированный под "процессор JVM". В этом и заключается кроссплатформенность. Так же, как код, скомпилированный под х86 будет выполняться на процессоре от Intel или AMD, так же и байткод JVM будет выполняться на JVM от Oracle, IBM, OpenJDK и т.д. И даже наличие JIT, компилирующего байткод в опкод конкретного железного процессора во время выполнения, все еще не дает повода обзывать честную стековую (SUN) или регистровую (Dalvik) VM интерпретатором, пусть даже и по сути :)

    Дело в том, что сама эта классификация (интерпретируемый/компилируемый ЯЗЫК) последние лет эдак 25 уже практически лишена смысла. Языкам, изначально ориентированным на реализацию в виде интерпретатора (с просто анализируемой лексикой, чтоб интерпретатор был поменьше и мог оставить самой программе достаточно места в ограниченной по объему памяти) типа APL или BASIC, сейчас (кроме, разумеется, очень узкоспециального применения) почетное место разве что в старых учебниках, из которых эту самую классификацию, с достойным лучшего применения упорством, продолжают дословно переписывать в новые. При этом, почему-то, забывают уточнить, что эти два понятия уже давно не про сами языки, а всего лишь про некоторые методы их реализации, и что с тех пор помимо этих методов появилось еще много других хороших и разных концепций на эту тему (типа VM, JIT, сборщиков мусора, да и хотя бы тех же OOП, разных видов типизации и еще миллион чего), которых в тех учебниках еще просто не было в силу их года издания. И что на сегодня уже даже для языков, принципиально заточеных для компиляции под регистровую архитектуру, типа С, есть пруд пруди интерпретаторов (раз, два, три)... которые, опять же, никто не называет виртуальными машинами, т.к. это все суть разные понятия. Короче, это все равно что пытаться понять, где в квантовой механике огонь, вода, земля и воздух, в том виде, как их понимали Платон и Аристотель :)

    P.S. Чтоб осознать, когда эта классификация еще была актуальна, рекомендую вот это . Там создатели APL, одного из первых настоящих интерпретируемых языков, обсуждают насущные проблемы языкостроения того времени. Если туго с английским, посмотрите хотя бы вступление... в тех железяках было меньше памяти и вычислительной мощности, чем в современной симке :)
    Ответ написан
    Комментировать
  • Суть виртуальной машины Java?

    ruFelix
    @ruFelix
    Предсказание будущего по руке, таро, кофе.
    Ну смотрите процессор компьютера понимает опкоды, для разных процессоров свои опкоды, x86 , AMD64, ARM и т.д.

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

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

    Виртуальня машина java это тоже интерпретатор по сути, но ему на вход идёт не сама java программа, а её трансформированный вариант, т.е. уже проверенный и более удобный для VM.

    Да вы всё правильно поняли, без JVM программа на java не запуститься не где. Замечу что например в симкарте вашего телефона есть процессор на котором запущена JVM и софт который на ней исполняется, это я к тому, что кроссплатформенность у java действительно широка.
    Ответ написан
    Комментировать
  • Системный vs Прикладной программист?

    uvelichitel
    @uvelichitel
    habrahabr.ru/users/uvelichitel
    Очень личное мнение -
    • gamedev закрытый мир, нужна толика удачи что бы туда для начала попасть(инди сектор не берем в расчет за полное отсутствие гарантий)
    • системное программирование с другой стороны - это понятное, повсеместно востребованное ремесло(в том же gamedev очень много низкоуровневого кода)
    Ответ написан
    3 комментария
  • Системный vs Прикладной программист?

    @Archusha
    https://agaltsovav.ru/
    Ну для студента 2 курса, без опыта, слишком уж категорично откинули WEB.

    Так или иначе все основные системы выходят в web.

    Смотрите сами, выбирайте сами, но не рубите с горяча.
    Ответ написан
    Комментировать
  • С чего начать создание приложения для Android?

    @protven
    Я бы советовал начать разучивать строевую подготовку и военные маршы. Ну это при условии что вы не найдете 3-5 тысяч для того, кто сделает за вас этот диплом.
    Ответ написан
    7 комментариев