10 أشياء لا تعرفها عن جافا

إذن، هل بدأت مؤخرًا العمل مع Java؟ هل تتذكر الأيام التي كانت تسمى "Oak"، عندما كان التوجه الكائني لا يزال موضوعًا ساخنًا، عندما اعتقد الأشخاص في لغة C++ أن Java ليس لديها فرصة، وعندما لم يسمع أحد عن التطبيقات الصغيرة؟ أستطيع أن أفترض أنك لا تعرف حتى نصف الأشياء التالية. لنبدأ الأسبوع ببعض المفاجآت الرائعة حول طريقة العمل الداخلية لجافا. 10 أشياء لا تعرفها عن جافا - 1

1. لا يوجد شيء اسمه استثناء محدد. صحيح! ليس لدى JVM أي فكرة عن هذا الأمر، فقط لغة Java هي التي تعرف ذلك. يتفق الجميع اليوم على أن الاستثناءات المحددة كانت خطأ. كما قال Bruce Eckel في حديثه الأخير في GeeCON في براغ، لا توجد لغة أخرى منذ أن تستخدم Java استثناءً محددًا، حتى Java 8 لم تعد تغطيها في Streams API الجديدة (والتي يمكن أن تكون إزعاجًا بسيطًا عندما تستخدم أجهزة lambda IO أو JDBC). هل تريد دليلاً على أن JVM لا يعرف شيئًا كهذا؟ جرب الكود التالي: لن يقوم هذا التجميع فقط، بل سيطرح أيضًا SQLException، ولا تحتاج حتى إلى استخدام Lombok'sSneakyThrows لهذا الغرض. 2. يمكن أن يكون لديك أساليب مثقلة تختلف فقط في أنواع الإرجاع

public class Test { // No throws clause here public static void main(String[] args) { doThrow(new SQLException()); } static void doThrow(Exception e) { Test.
  doThrow0(e); } @SuppressWarnings("unchecked") static 
  
   void doThrow0(Exception e) throws E { throw (E) e; } }

Это не откомпorруется, верно? class Test { Object x() { return "abc"; } String x() { return "123"; } } Верно. Язык Java не позволяет одновременно двум методам быть эквивалентно переопределенными в пределах одного класса, не обращая внимания на их отличая в throws либо return типах. Но подождите minutesку. Проверьте еще раз documentацию по Class.getMethod(String, Class…). Там написано: Отметьте, что, возможно, есть более одного соответствующего метода в классе, потому что, пока язык Java запрещает множество методов с одинаковой сигнатурой но разными возвращаемыми типами, виртуальная машина Java этого не делает. Эта гибкость в виртуальной машине может использоваться для реализации различных функций языка. Например, ковариантные возвраты могут осуществляться с bridge методами; bridge метод и переопределенный метод, имели бы одинаковую сигнатуру но разные возвращаемые типы. Ничего себе, да это имеет смысл. На самом деле это довольно много что происходит, когда вы пишете следующее:

abstract class Parent
   { abstract T x(); } class Child extends Parent
   
    { @Override String x() { return "abc"; } }

Посмотрите на сгенерированный byte code:

// Method descriptor #15 ()Ljava/lang/String; // Stack: 1, Locals: 1 java.lang.String x(); 0 ldc 
   [16] 2 areturn Line numbers: [pc: 0, line: 7] Local variable table: [pc: 0, pc: 3] local: this index: 0 type: Child // Method descriptor #18 ()Ljava/lang/Object; // Stack: 1, Locals: 1 bridge synthetic java.lang.Object x(); 0 aload_0 [this] 1 invokevirtual Child.x() : java.lang.String [19] 4 areturn Line numbers: [pc: 0, line: 1]

Итак, t на самом деле an object в byte codeе. Это хорошо понимается. Синтетический bridge метод на самом деле генерируется компилятором потому что тип возвращаемого значения Parent.x() можно ожидать на определенных участках вызовов. Добавление generics без таких bridge методов перестанет быть возможным в двоичном представлении. Итак, изменения в JVM чтобы позволить такую функцию произвело меньше боли (которая также позволяет ковариантное переопределение метода в качестве побочного эффекта…) По умному правда? 3. Все следующее – двумерные массивы.

class Test { int[][] a() { return new int[0][]; } int[] b() [] { return new int[0][]; } int c() [][] { return new int[0][]; } }

Это на самом деле так. Даже если ваш умственный анализатор, не может сразу понять возвращаемый тип из описанных выше способов, все они одинаковы! Как и следующий кусок codeа. class Test { int[][] a = {{}}; int[] b[] = {{}}; int c[][] = {{}}; } Вы думаете, что это безумие? Количество возможностей написать тоже просто взрывает воображение!

@Target(ElementType.TYPE_USE) @interface Crazy {} class Test { @Crazy int[][] a1 = {{}}; int @Crazy [][] a2 = {{}}; int[] @Crazy [] a3 = {{}}; @Crazy int[] b1[] = {{}}; int @Crazy [] b2[] = {{}}; int[] b3 @Crazy [] = {{}}; @Crazy int c1[][] = {{}}; int c2 @Crazy [][] = {{}}; int c3[] @Crazy [] = {{}}; }

Type annotation. Устройство загадочность которого уступает только его мощи. Или другими словами: Когда я делаю последний коммит How раз перед моим 4-х недельным отпуском. 10 أشياء لا تعرفها عن جافا - 2

Я разрешаю вам пользоваться любым понравившимся вам способом. 4. Вы не получите условное выражение Итак, вы думали, что уже знаете все про условные выражения, когда начали их использовать? Позвольте вас огорчить – вы ошибались. Большинство из вас подумает что следующие два примера эквивалентны: Object o1 = true ? new Integer(1) : new Double(2.0); эквивалентно этому? Object o2; if (true) o2 = new Integer(1); else o2 = new Double(2.0); Нет. Давайте используем быстрый тест System.out.println(o1); System.out.println(o2); Программа выведет следующее: 1.0 1 Да! Условный оператор будет осуществлять приведение типов, если понадобится. Поскольку в ином случае вы ожидали бы что программа бросит NullPointerException?

Integer i = new Integer(1); if (i.equals(1)) i = null; Double d = new Double(2.0); Object o = true ? i : d; // NullPointerException! System.out.println(o);

5. Вы также не получите составной оператор назначения. Изворотливости достаточно? Давайте рассмотрим следующие два фрагмента codeа: i += j; i = i + j; Интуитивно, они должны быть равняться правда? Но знаете что – они разные. Спецификация JLS говорит: Составное выражение типа Е1 ор = Е2 эквивалентно Е1 = (Т) ((Е1) ор (Е2)), где Т это тип Е1, за исключение что Е1 вычисляется только один раз. Хороший пример это использовать *= or /= : byte b = 10; b *= 5.7; System.out.println(b); // prints 57 or: byte b = 100; b /= 2.5; System.out.println(b); // prints 40 or: char ch = '0'; ch *= 1.1; System.out.println(ch); // prints '4' or: char ch = 'A'; ch *= 1.5; System.out.println(ch); // prints 'a' Итак, это до сих полезный инструмент? 6. Случайные целочисленные числа Теперь более трудное задание. Не читайте решение. Посмотрите сможете ли вы найти ответ самостоятельно. Когда я запущу следующую программу: for (int i = 0; i < 10; i++) { System.out.println((Integer) i); } иногда я получаю следующий вывод: 92 221 45 48 236 183 39 193 33 84 Но How такое вообще возможно? Ок, ответ в кроется в переопределении JDK кеша Integer через рефлексию, и затем в использовании auto-boxing и auto-unboxing. Не делайте этого без разрешения взрослых! Или другими словами: 10 أشياء لا تعرفها عن جافا - 3

7. GOTO Одно из моих самых любимых. У Java есть GOTO! Напишите это: int goto = 1; и вы получите это:

Test.java:44: error: 
   expected int goto = 1; ^

Это потому что goto это неиспользуемое зарезервированное слово, просто на всякий случай… Но это не самая захватывающая часть. Самое интересное то что вы можете включить goto в паре с break, continue и помеченных блоков: Прыжки вперед label: { // do stuff if (check) break label; // do more stuff } В byte codeе: 2 iload_1 [check] 3 ifeq 6 // Jumping forward 6 .. Прыжки назад label: do { // do stuff if (check) continue label; // do more stuff break label; } while(true); В byte codeе: 2 iload_1 [check] 3 ifeq 9 6 goto 2 // Jumping backward 9 .. 8. У Java есть псевдонимы типов В других языках (например Ceylon), мы можем определять псевдонимы типов очень легко:

interface People => Set
   ;

Класс People здесь построен таким образом, что может взаимозаменяться множеством Set :

People? p1 = null; Set
    ? p2 = p1; People? p3 = p2;

В Java мы не можем просто так определить псевдоним на верхнем уровне. Но мы можем сделать так для потребностей класса либо метода. Давайте предположим что нас не устраивают такие имена How Integer, Long и т.д. и мы хотим имена по короче: I и L. Да легко:

class Test { 
     void x(I i, L l) { System.out.println( i.intValue() + ", " + l.longValue() ); } }

В примере выше, Integer преобразован в I для видимости класса Test в то время How Long преобразован в L для нужд метода х(). Теперь мы можем вызвать этот метод следующим образом: new Test().x(1, 2L); Конечно эту технику не следует воспринимать всерьез. В данном случае Integer и Long final типы, что означает что I и L – эффективные преобразования (почти, преобразование идет только в одну сторону). Если бы мы решor использовать non-final типы (к примеру Object), тогда мы могли бы обойтись обычными дженериками. Поигрались немного и хватит. Давай перейдем к чему-то по настоящему интересному. 9. Некоторые отношения типов неразрешимы! Хорошо, сейчас будет действительно интересно, так что возьмите чашку концентрированного кофе и давайте рассмотрим следующие два типа: // A helper type. You could also just use List interface Type {} class C implements Type > {} class D
implements Type >>> {} فماذا يعني C و D حتى؟ بمعنى أنها متكررة، على غرار العودية في java.lang.Enum. خذ بعين الاعتبار: بالنظر إلى المواصفات المذكورة أعلاه، فإن التنفيذ الفعلي للتعداد هو مجرد سكر نحوي: مع أخذ ذلك في الاعتبار، دعنا نعود إلى النوعين لدينا. هل سيتم تجميع الكود التالي؟ سؤال صعب...ولم يتم حله فعليا؟ هل C نوع فرعي من النوع ؟ حاول تجميع هذا في Eclipse أو Idea الخاص بك وسيخبرونك برأيهم. اغسلها في البالوعة... بعض علاقات الكتابة في Java غير قابلة للتقرير! 10. تقاطع النوع تمتلك Java ميزة مثيرة جدًا تسمى تقاطع النوع. يمكنك الإعلان عن نوع (عام) وهو في الواقع تقاطع نوعين. على سبيل المثال: يجب أن تتضمن معلمة النوع المخصص T التي تربطها بمثيلات فئة الاختبار كلا من الواجهات القابلة للتسلسل والقابلة للاستنساخ. على سبيل المثال، لا يمكن تقييد السلسلة، ولكن يمكن تقييد التاريخ: هذه الميزة لها استخدامات متعددة في Java8، حيث يمكنك إرسال الأنواع. كيف يساعد هذا؟ لا شيء تقريبًا، ولكن إذا كنت تريد تحويل تعبير لامدا إلى النوع الذي تحتاجه، فلا توجد طريقة أخرى. لنفترض أن لديك مثل هذا القيد المجنون في طريقتك: فأنت تريد Runnable والذي يكون في نفس الوقت قابلاً للتسلسل فقط إذا كنت تريد تنفيذه في مكان آخر وإرسال النتيجة عبر الشبكة. تضيف لامدا والتسلسل القليل من السخرية. يمكنك إجراء تسلسل لتعبير لامدا الخاص بك إذا كان نوع الهدف والوسائط الخاصة به قابلة للتسلسل. ولكن حتى لو كان هذا صحيحًا، فإنهم لا يقومون تلقائيًا بتمكين الواجهة القابلة للتسلسل. يجب عليك إحضارهم إلى هذا النوع بنفسك. ولكن عندما تقوم بالإرسال فقط إلى Serializable: فلن تكون lambda قابلة للتشغيل بعد الآن، لذا أرسلها إلى كلا النوعين: وفي الختام: public abstract class Enum > { ... }// This enum MyEnum {} // Is really just sugar for this class MyEnum extends Enum { ... }class Test { Type c = new C(); Type> d = new D (); } Step 0) C Step 1) Type > >? Step 0) D > Step 1) Type >>> > Step 2) D >> Step 3) List >> > Step 4) D > >> Step . . . (expand forever) class Test { }// Doesn't compile Test s = null; // Compiles Test d = null;void execute(T t) {}execute((Serializable) (() -> {}));execute((Runnable & Serializable) (() -> {}));

جافا قوية بقدر ما هي غامضة.