Трябва ли Java да наруши обратната съвместимост в бъдещи версии в полза на по-чист език? [затворено]

Както вече споменах, дори в неговия Как и кога да се отхвърлят API, нищо не се казва за политика относно действителното премахване на отхвърлени API...

Броят на приложенията, базирани на по-стара JVM (1.4 например) все още е важен, отчасти поради сървърите на приложения, които отнемат много време, за да се валидират с нови версии на JVM...

Големият брой приложения, които действително се изпълняват в производство, означава, че тази политика за „обратна съвместимост“ може да не бъде нарушена скоро.

Има няколко вида обратна съвместимост:

1. Може ли старият изходен код да се компилира с новия компилатор?

   Това може да се справи с инструменти, които преобразуват стари конструкции в нови, или с нещо като "source 1.6;" директива в горната част на файла.

2. Могат ли старите клас файлове да работят в нова JVM?

   В моя свят това е пълна спирачка. Ние използваме толкова много библиотеки на трети страни, че налагането на едновременно надграждане на всички тях би било твърде скъпо.

   Това също е причината да не се премахват отхвърлени класове и методи, но в по-малка степен.

3. Могат ли старите клас файлове да извикват код, компилиран с новия компилатор?

   Това е важна част от #2, заради обратните извиквания.

4. Може ли новокомпилиран код да извиква код от стари клас файлове?

   Друга важна част от #2.

5. Кодът прилича ли значително на разработчиците?

   Това е важно за обучение и за работа с големи кодови бази, които не са напълно конвертирани. По-фин аспект е колко от новата функция може да се използва в смесена кодова база. Ако прекалите с това, имате нещо като Scala вместо Java++.

Генеричните продукти бяха добавени така, че да се запазят всички от тези видове съвместимост. Мисля, че всяка несъвместима промяна на Java трябва да запази поне 2, 3 и 4, за да има някакъв шанс да бъде приета като Java. Инструментите за работа с #1 също са минимално изискване.

Можете да направите това с езици за хоби (Ruby), езици с ниска реализация (Python), но не можете да си представите колко приложения са написани на Java по света. Просто проверете freshmeat или sourceforge. И това е само част. Така че не, не е добра идея. Всъщност би било доста глупава идея.

Няма две GUI рамки. Swing зависи и използва AWT като своя основа.

Наистина бих се радвал, ако някои остарели функции бяха премахнати - например, ако обектът Date наистина беше направен неизменен, ще бъда много щастлив. Както е, ако пишете неизменен клас, не можете да приемете, че датите са неизменни и трябва да ги копирате защитно, например, и не можете надеждно да ги използвате като ключове в Hashmaps (тъй като и в двата случая друг код може да промени датата, независимо дали методите са анотирани като остарели или не).

Когато става въпрос за добавяне на нови езикови функции, не разбирам напълно мантрата за обратна съвместимост. Според мен не е толкова голяма работа, ако кодът, написан за предишна версия, се нуждае от някои настройки, за да работи в по-късна версия. Всъщност все пак има прецедент за това; между 1.5 и 1.6 бяха добавени допълнителни методи към интерфейса ResultSet, така че кодът, който ще се компилира и работи под Java 1.5, дори няма да се компилира под 1.6.

Имайки предвид наследените приложения, разумно ли е някой да очаква приложение, което не е актуализирано от 5 години, да работи перфектно на най-новата версия на JVM? Ако организациите все още използват Java 1.4 и приложения, които са написани за него, наистина ли ги интересува какво влиза в Java 7? Нарушаването на обратната съвместимост не означава, че всички предишни версии на JVM също ще бъдат повредени. Ако приложението е насочено към по-ранна версия, можете просто да го стартирате на тази версия на JVM без притеснения.

Най-важното е, че с течение на времето и хората използват Java, грешките и пропуските във функциите стават очевидни и коригирането/прилагането им би било голяма полза. Да бъдеш осъден, когато се опитваш да подобриш езика заради това, което беше преди, ако е жалко и според мен не е основно изискване.

Разбира се, ще трябва да се помисли за пътя на надстройката. За внезапна промяна на int в Integers, например, ще са необходими маси досадни промени в кода за всички (както и добавяне на допълнителни нулеви проверки и т.н.). Въпреки това, добавянето на нова функция, която се случва да наруши обратната съвместимост (напр. затваряния), или премахването на методи, които са отхвърлени от години, няма да има голям ефект върху съществуващия код. (Ако сте използвали остарели методи, тогава е трудно, трябваше да ги премахнете преди, но сега сте принудени да го направите!)

От съображения за съвместимост те не могат да направят това със стандартните версии на Java. В момента има толкова много Java софтуер в производство, че просто не можете да го разбиете с нова версия, която премахва всички гафове.

Все пак смятам, че Sun може да направи версия на "Java X", която премахва всичко, което беше кофти, и добавя всички добри и полезни API, които съществуват, но не са включени в момента (включително замяна на Java API, които имат налични по-добри алтернативи, напр. log4j и нека не започваме с дата и календар). Това издание няма да бъде предназначено да замени Java, но може да съществува като цел за нови софтуерни проекти. Предполагам, че биха могли също така да поправят езика, за да включват функции, които липсват и които карат Java да изглежда малко кофти в сравнение с най-новите версии на C# и т.н. Ако създадат и инструмент за пренасяне на код, който може да поправи или поне да добави "FIXME" към всички проблемни области в кодова база ...

Трябва да призная, че Microsoft върши добра работа, като насочва хората към по-новите версии на .NET, когато излязат. Sun се провали напълно тук, като се има предвид броят на приложенията, които все още работят на 1.4, и летаргичните политики за версията на Java на много компании (които изглеждат щастливи да позволят на своите .NET хора да използват най-новите и най-добрите по някакъв начин). Като се има предвид, че е лесно да имате множество инсталации на Java на машина, мисля, че трябва да се направи повече, за да се насърчат компаниите и софтуерните къщи да надграждат по-рано.

Бих казал, че нарушаването на обратната съвместимост е глупаво нещо за java. Ако е така, можете да го наречете Java++, това вече не е Java. От друга страна, за бъдещите версии на java трябва да се учи от динамичния език за функции като простота на синтаксиса. Тъй като мощността на хардуера нараства толкова бързо, абстрактното ниво трябва да е по-високо за компилиращ език. Сравнявайки някои характеристики на текущите версии на Java с динамични езици, той е твърде тромав и многословен, следователно по-малко продуктивен за разработка. Изглежда, че C# се превръща в динамичен език?

С много страхотни алтернативни езици на JVM, наистина не виждам причина защо. Предпочитам да имам стабилна Java и да продължа към страхотните нови неща (и пак да остана съвместим с Java).

Тъй като голяма част от пазарния дял все още използва по-стари jdk/jre, не мисля, че ще бъде прагматично да се наруши обратната съвместимост.

Както каза Пат, приемането на най-новата версия на JDK е доста бавно и много приложения в момента работят с помощта на стари (понякога наистина стари) версии на Java.

Следователно не мисля, че има реална полза от това да не се гарантира обратната съвместимост.

За вашите предложения, аз наистина не виждам интерес от премахване на примитивите. Разбира се, има autoboxing от Java 5. Но примитивите все още имат своите интереси...

Нарушаването на съвместимостта би имало смисъл, ако JVM запази същото. В този случай „новата“ Java ще стане нов, различен език, работещ на JVM, като изброените там. За щастие начинът, по който е проектирана JVM, гарантира оперативна съвместимост между езици и версии, така че мисля, че въздействието ще бъде ограничено.

Мисля, че разклонението би било по-подходящо, за да се преработи правилно езикът. Начинът, по който работят генериците на Java, започва да ме ядосва, честно казано.

Причината да напусна PHP е, че те променят API/наличните функции между основните надстройки на версията. Истинският проблем е, че PHP не може да работи в режим на съвместимост за по-стари скриптове. Не искам да бъда ПРИНУДЕН да надграждам кода си.

Java е на същото място. Просто се уверете, че можете да използвате старите неща от 1.4 в новите версии. Добре е да изисквате новите програми да използват нов xyntax, но накарайте старите неща да работят!

Що се отнася до примитивите, те винаги ще бъдат там, харесва или не, защото те са основните градивни елементи на обектите. Разбира се, бихте могли вместо това да използвате класовете обвивки, но това просто претоварва компилатора, което в крайна сметка се превежда обратно към примитиви в повечето случаи.

Обратната съвместимост е много важна и както хората вече споменаха тук, има много потребители, които все още изпълняват код 1.3 и 1.4. Като казах това, мисля, че ако някой все още изпълнява код на Java 1.0 или 1.1 в някаква наследена система, няма вероятност скоро да мигрира към Java 7, а дори и да го направи, най-вероятно ще трябва да пренапише своя код все пак. Мисля, че отхвърленият API от версии >1.2 може безопасно да бъде премахнат.

Друг аспект на обратната съвместимост е добавянето на ключови думи, което винаги се обезсърчава. в Java 5 основните езикови промени бяха управлявани с добавянето на една единствена нова ключова дума, 'enum', и дори това предизвика възмущение, тъй като всяка част от кода с променлива, наречена 'enum', вече беше несъвместима. Доколкото знам, промените в Java 7 са планирани без нови ключови думи (фу!).

Ювал =8-)

Ще бъде добре, в зависимост от това Sun да не набутва нови JDK надстройки на всички свои клиенти. Тези, които използват стари API, няма да надстроят и ще използват стара версия JDK за известно време.

Или може би чрез прилагане на режим на обратна съвместимост.

Мисля, че някои API, например дата и час, трябва да бъдат пренаписани. Ако текущата версия го получи EOL, тогава старият API трябва да бъде премахнат. Нашата статистика показва, че 99,3% от нашите клиенти използват Java 6 или по-нова версия. Няма нужда от много стар API за съвместимост. Но трябва да има ясна времева рамка, ако API ще бъде премахнат.