ده چیزی که در مورد جاوا نمی‌دانستید!

895 خواندن این مطلب 5 دقیقه زمان می‎برد

شما از کسانی هستید که از زمانی که شئ‌گرایی رونق داشت جاوا را می‌شناختید، از زمانی که به نام Oak صدا زده می‌شد و از هنگامی که طرفداران c++i هیچ شانسی برای پیشرفت جاوا قائل نمی‌شدند با آن کار می‌کردید؟
حتی اگر شما از ابتدا با جاوا آشنا بودید و با آن کار می‌کردید، قول می‌دهم که بیش از نیمی از موارد زیر را نمی‌دانید.
پس بیایید با ۱۰ شگفتی از عملکرد داخلی جاوا آشنا شویم.

۱-چیزی به نام checked Exception وجود ندارد
درست است! JVM اصلا چنین چیزی نمی‌شناسد و فقط زبان جاوا آن را می‌داند.
امروز همه موافق هستند که checked Exceptionها اشتباه بودند. هیچ زبان دیگری بعد از جاوا از chekced Exception استفاده نکرده است و حتی در جاوا ۸ در APIهای استریم‌ها وجود ندارند.
برای اثبات عدم شناخت JVM از این خطاها کد زیر را امتحان کنید:

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

public class Test {

// No throws clause here

public static void main(String[] args) {

doThrow(new SQLException());

}

static void doThrow(Exception e) {

Test.<RuntimeException> doThrow0(e);

}

@SuppressWarnings("unchecked")

static <E extends Exception>

void doThrow0(Exception e) throws E {

throw (E) e;

}

نه تنها این کد کامپایل می‌شود بلکه خطای SQLException هم پرتاب می‌کند بدون آنکه نیاز به بلوک try/catch یا جمله throws Exception در امضای تابع باشد!

۲- می‌توان تابع‌هایی که تنها در نوع خروجی متفاوت هستند را overload کرد.

کامپایل نمی‌شود درسته؟

class Test {
    Object x() { return "abc"; }
    String x() { return "123"; }
}

class Test {

Object x() { return "abc"; }

String x() { return "123"; }

}

زبان جاوا اجازه نمی‌دهد که دو تابع در یک کلاس با نام یکسان بدون تفاوت در نوع خروجی یا عبارت throws تعریف شوند.

اگر جاواداک مربوط به کلاس Class.getMethod(String, class…)i را چک کنیم نوشته شده:
“توجه کنید که ممکن است بیش از یک متد در یک کلاس مطابقت داشته باشد چرا که جاوا اجازه تعریف توابع با امضای یکسان و نوع خروجی متفاوت را به یک کلاس نمی‌دهد اما JVM این‌گونه نیست. این مساله انعطاف پذیری را در ماشین مجازی افزایش می‌دهد که بتواند قابلیت‌های مختلف زبان را پیاده‌سازی کند. برای مثال covariant returns می‌توانند با توابع bridge پیاده شوند. توابع bridge و توابع override شده یک امضا ولی خروجی‌های مختلف خواهند داشت.”
پس اگر کد زیر را بنویسیم داریم:

abstract class Parent<T> {
    abstract T x();
}

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

abstract class Parent<T> {

abstract T x();

}

class Child extends Parent<String> {

@Override

String x() { return "abc"; }

}

کد تولید شده در بایت کد کلاس Child را بررسی می‌کنیم.

// Method descriptor #15 ()Ljava/lang/String;
  // Stack: 1, Locals: 1
  java.lang.String x();
    0  ldc <String "abc"> [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]

// Method descriptor #15 ()Ljava/lang/String;

// Stack: 1, Locals: 1

java.lang.String x();

0 ldc <String "abc"> [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 تنها یک Object در بایت کد است. تابع bridge ساخته‌شده توسط کامپایلر تولید می‌شود چرا که نوع خروجی در امضای تابع Parent.x() ممکن است انتظار برود در بعضی از نقاط فراخوانی Object باشد. اضافه کردن generic بدون چنین توابع bridgeای برای binary comaptible بودن امکان پذیر نمی‌شد. بنابراین تغییر JVM برای اجازه دادن به چنین قابلیت‌هایی راحت‌تر بود. راه‌حل هوشمندانه‌ای بود، نه؟!

۳- تمام این‌ها آرایه‌های دوبعدی هستند!

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

class Test {

int[][] a() { return new int[0][]; }

int[] b() [] { return new int[0][]; }

int c() [][] { return new int[0][]; }

}

بله درست است، حتی اگر ذهن شما نتواند سریع پردازش کند که تمام عبارات فوق یکسان هستند. مشابه کد زیر:

class Test {
    int[][] a = {{}};
    int[] b[] = {{}};
    int c[][] = {{}};
}

class Test {

int[][] a = {{}};

int[] b[] = {{}};

int c[][] = {{}};

}

فکر می‌کنید احمقانه است؟ حال تصور کنید ویژگی type annotation در جاوا ۸ را به همراه آن به کار ببریم. تعداد حالات بی‌شمار خواهد شد!

@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 [] = {{}};
}

@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 [] = {{}};

}

۴- شما عبارات شرطی را درک نمی‌کنید
فکر می‌کنید که وقتی از عبارات شرطی استفاده می‌کنید همه چیز را درمورد آن می‌دانید؟ خب لازم است که بگوییم این طور نیست! اغلب شما فکر می‌کنید که کد

Object o1 = true ? new Integer(1) : new Double(2.0);

1	Object o1 = true ? new Integer(1) : new Double(2.0);

و کد زیر

Object o2;

if (true)
    o2 = new Integer(1);
else
    o2 = 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 2	System.out.println(o1); System.out.println(o2);

خروجی برنامه به شکل زیر خواهد بود:

1.0
1

1.0

عملگر شرط “هر وقت لازم بداند” نمایش نوع‌داده عددی را به کار می‌گیرد. شما از برنامه زیر انتظار خواهید داشت که 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);

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);

۵- شما حتی از عملگر انتساب ترکیبی هم چیزی نمی‌دانید!
دو خط کد زیر را در نظر بگیرید:

i += j;
i = i + j;

1 2	i += j; i = i + j;

ظاهرا باید معادل باشند، درسته؟ اما نیستند! در JLS آمده است.

عملگر انتساب مرکب به فرم E1 op= E2 معادل است با E1 = (T)((E1) op(E2))i که در آن T از نوع E1 است. به جز در مواردی که E1 تنها یک بار ارزیابی می‌شود.
این مساله خیلی زیباست مثال‌های زیر را ببینید:

byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57

byte b = 10;

b *= 5.7;

System.out.println(b); // prints 57

یا

byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40

byte b = 100;

b /= 2.5;

System.out.println(b); // prints 40

یا

char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'

char ch = '0';

ch *= 1.1;

System.out.println(ch); // prints '4'

یا

char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'

char ch = 'A';

ch *= 1.5;

System.out.println(ch); // prints 'a'

حالا واقعا چقدر مفید خواهد بود؟ بریم کاراکترهای توی کدمون را *= کنیم….!

۶- اعداد رندوم
حالا یک معمای بزرگ‌تر. به پاسخ نگاه نکنید ببینید می‌توانید خودتان کشف کنید. وقتی برنامه زیر را اجرا می‌کنیم:

for (int i = 0; i < 10; i++) {
  System.out.println((Integer) i);
}

for (int i = 0; i < 10; i++) {

System.out.println((Integer) i);

}

“گاها” خروجی زیر را دریافت می‌کنیم:

221

236

183

193

چطور ممکن است؟
.
.
.
.
.
راه حل اینجاست (به Integer cache overriding در JDK با استفاده از reflection و سپس استفاده از auto-boxing , auto_unboxing برمی‌گردد)

۷- GOTO
این یکی از موارد مورد علاقه من است. جاوا GOTO دارد! این کد را بنویسید.

int goto = 1;

1	int goto = 1;

نتیجه زیر را در برخواهد داشت!

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

Test.java:44: error: <identifier> expected

int goto = 1;

به این دلیل است که جاوا کلید واژه استفاده نشده GOTO دارد.

اما نکته جالب کار این است که شما خودتان می‌توانید goto را تعریف کنید
پرش به جلو:

label: {
  // do stuff
  if (check) break label;
  // do more stuff
}

label: {

// do stuff

if (check) break label;

// do more stuff

}

در بایت کد

2  iload_1 [check]
3  ifeq 6          // Jumping forward
6  ..

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);

label: do {

// do stuff

if (check) continue label;

// do more stuff

break label;

} while(true);

در بایت کد

2  iload_1 [check]
 3  ifeq 9
 6  goto 2          // Jumping backward
 9  ..

2 iload_1 [check]

3 ifeq 9

6 goto 2 // Jumping backward

9 ..

۸- جاوا برای نوع داده‌ها اسم مستعار دارد
در زبان‌های دیگر به سادگی می‌توان اسم مستعار تعریف کرد:

interface People => Set<Person>;

1	interface People => Set<Person>;

که از این به بعد به جای set به راحتی می‌توان از People استفاده کرد.

People?      p1 = null;
Set<Person>? p2 = p1;
People?      p3 = p2;

People? p1 = null;

Set<Person>? p2 = p1;

People? p3 = p2;

در جاوا در سطوح بالا نمی‌توانیم اسم مستعار برای نوع داده‌ها تعریف کنیم اما می‌توانیم این کار را در اسکوپ یک کلاس یا متد انجام دهیم. فرض کنید ما از نامگذاری‌های Integer, Long, … خوشمان نمی‌آید و می‌خواهیم اسامی کوتاه‌تری مثل I, L, … را داشته باشیم. ساده است:

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

class Test<I extends Integer> {

<L extends Long> void x(I i, L l) {

System.out.println(

i.intValue() + ", " +

l.longValue()

);

}

در اسکوپ کلاس Test بالا، I اسم مستعاری برای Integer و در اسکوپ تابع x این کلاس L اسم مستعاری برای Long شده است. پس می‌توان متد بالا را به شکل زیر فراخوانی کرد:

new Test().x(1, 2L);

1	new Test().x(1, 2L);

این تکنیک‌ها البته جدی نیستند. در این جا Integer, Long هر دو نوع داده‌های نهایی هستند و این یعنی I, L واقعا اسم مستعارند اما اگر این طور نبود و مثلا با نوع داده Object سروکار داشتیم آن وقت از یک generic ساده استفاده کرده بودیم.

۹- بعضی از روابط بین نوع‌داده‌ها مشخص نیست!
این مورد می‌تواند اندکی ترسناک باشد پس یک لیوان چایی بریزید و تمرکز کنید. این دو نوع را در نظر بگیرید:

// A helper type. You could also just use List
interface Type<T> {}

class C implements Type<Type<? super C>> {}
class D<P> implements Type<Type<? super D<D<P>>>> {}

// A helper type. You could also just use List

interface Type<T> {}

class C implements Type<Type<? super C>> {}

class D<P> implements Type<Type<? super D<D<P>>>> {}

نوع داده‌های C, D چه معنی می‌دهند؟
این‌ها تقریبا بازگشتی هستند مشابه شیوه‌ای که java.lang.Enum بازگشتی است در نظر بگیرید:

public abstract class Enum<E extends Enum<E>> { ... }

1	public abstract class Enum<E extends Enum<E>> { ... }

با تعریف فوق پیاده‌سازی enum تنها یک معادل نحوی برای ساده‌سازی خواهد بود:

// This
enum MyEnum {}

// Is really just sugar for this
class MyEnum extends Enum<MyEnum> { ... }

// This

enum MyEnum {}

// Is really just sugar for this

class MyEnum extends Enum<MyEnum> { ... }

با در نظر داشتن این مساله به مثال خودمان برمی‌گردیم. آیا تکه کد زیر کامپایل خواهد شد؟

class Test {
    Type<? super C> c = new C();
    Type<? super D<Byte>> d = new D<Byte>();
}

class Test {

Type<? super C> c = new C();

Type<? super D<Byte>> d = new D<Byte>();

}

سوال سختی است!
آیا C یک زیرنوع از Type<? super C>i است؟

Step 0) C <?: Type<? super C>
Step 1) Type<Type<? super C>> <?: Type (inheritance)
Step 2) C  (checking wildcard ? super C)
Step . . . (cycle forever)

Step 0) C <?: Type<? super C>

Step 1) Type<Type<? super C>> <?: Type (inheritance)

Step 2) C (checking wildcard ? super C)

Step . . . (cycle forever)

یا آیا D یک زیر نوع از Type<? super D<Byte>>i است؟

Step 0) D<Byte> <?: Type<? super C<Byte>>
Step 1) Type<Type<? super D<D<Byte>>>> <?: Type<? super D<Byte>>
Step 2) D<Byte> <?: Type<? super D<D<Byte>>>
Step 3) List<List<? super C<C>>> <?: List<? super C<C>>
Step 4) D<D<Byte>> <?: Type<? super D<D<Byte>>>
Step . . . (expand forever)

Step 0) D<Byte> <?: Type<? super C<Byte>>

Step 1) Type<Type<? super D<D<Byte>>>> <?: Type<? super D<Byte>>

Step 2) D<Byte> <?: Type<? super D<D<Byte>>>

Step 3) List<List<? super C<C>>> <?: List<? super C<C>>

Step 4) D<D<Byte>> <?: Type<? super D<D<Byte>>>

Step . . . (expand forever)

اگر کد بالا را در اکلیپس امتحان کرده باشید می‌بینید که کرش خواهد کرد! در کل می‌توان گفت که ارتباط بعضی از نوع‌داده‌ها قابل تصمیم‌گیری نیست.

۱۰- اشتراک نوع‌داده‌ها
یک ویژگی عجیبی که جاوا دارد اشتراک نوع‌داده‌هاست. می‌توان نوع‌داده‌ای تعریف کرد که در حقیقت اشتراک دو نوع داده دیگر است. برای مثال:

class Test<T extends Serializable & Cloneable> {
}

1 2	class Test<T extends Serializable & Cloneable> { }

هر نوع‌داده‌ای که قرار است به جای T استفاده شود باید هر دو کلاس Serializable , Cloneable را پیاده‌سازی کرده باشد مثلا String اینطور نیست ولی Date می‌تواند باشد:

// Doesn't compile
Test<String> s = null;

// Compiles
Test<Date> d = null;

// Doesn't compile

Test<String> s = null;

// Compiles

Test<Date> d = null;

این ویژگی در جاوا ۸ هم استفاده شده که می‌توان نوع‌داده‌ها را به اشتراک نوع‌داده‌های خاص منظوره تبدیل کرد. اما این به چه دردی می‌خورد؟ حقیقتا این اصلا به درد بخور نیست! اما اگر بخواهیم یک lambda expression را به چنین نوع داده‌ای تبدیل کنیم راه دیگری نداریم. فرض کنید محدودیت‌های نوع‌داده مسخره زیر را روی تابع خود داشته باشید:

<T extends Runnable & Serializable> void execute(T t) {}

1	<T extends Runnable & Serializable> void execute(T t) {}

شما یک Runnableای می‌خواهید که Serializable هم باشد برای شرایطی که هم می‌خواهید آن را در جایی دیگر اجرا کنید و هم روی سیم بفرستید. lambda و Serialization اندکی مشابه اند!
شما می‌توانید یک lambda expression را serialize کنید اگر نوع‌داده مقصد و آرگومان‌های آن serializable بودند.
اما اگر این هم درست باشد به طور اتوماتیک serializable را پیاده‌سازی نمی‌کنند. برای تبدیل آن‌ها به آن نوع‌داده لازم است تبدیل صورت گیرد. اما وقتی فقط به Serializable تبدیل انجام شود.

execute((Serializable) (() -&gt; {}));

1	execute((Serializable) (() -> {}));

آن‌گاه lambda دیگر runnable نخواهد بود. بنابراین باید تبدیل به هردو نوع‌داده صورت گیرد.

execute((Runnable &amp; Serializable) (() -&gt; {}));

1	execute((Runnable & Serializable) (() -> {}));

جاوا زبان پر رمز و رازی است. شما چه عجایب دیگری از آن تا به حال کشف کرده‌اید؟

منابع:

javacodegeek
wikipedia
stackoverflow

برچسب ها

فروغ مهرعلیان 30 مهر 1394

895 خواندن این مطلب 5 دقیقه زمان می‎برد

یک دیدگاه

امیر گفت:
19 آبان 1398 در 5:56 ب.ظ
عجب!
پاسخ

دیدگاهتان را بنویسید لغو پاسخ

مهدی
عالی، عالی و بازم عالی اگر چندتا دوره فارسی دیگه رو ببینید م...
فرهاد نجفی
اگر واقعن دنبال دوره قوی هستید که بتونید بعد از اون وارد باز...
مهدی
توصیه می کنم دوستانی که آشنایی با گیت و گیت هاب ندارن دوره ر...
کیومرث
درود و خدا قوت بخاطر زحمات فراوان و سخاوت در اشتراک گذاری دا...
محمد
من خودم 45 ساله هستم. هرچند به واقعیتها اشاره کردید و فی الو...

ده چیزی که در مورد جاوا نمی‌دانستید!

یک دیدگاه

دیدگاهتان را بنویسید لغو پاسخ

دستگرمی شانزدهم

دستگرمی پانزدهم

دستگرمی چهاردهم

دستگرمی سیزدهم

دستگرمی دوازدهم

دور دوم آزمون جاواکاپ

سیر مطالعاتی

سوالات رایج درباره جاواکاپ

دوره آموزش رایگان JavaFX

دعوت به تبادل نظر: آیا جاوا برای تولید نرم‌افزارهای عمومی گزینه مناسبی است؟

ماتریس (تا پایان جلسه ششم)

عضویت در خبرنامه

با عضویت در خبرنامه، از جدیدترین مقالات سایت با خبر شوید.

شرکت سامانه های یکپارچه بزرگ فردا

مرکز راهکارهای اطلاعاتی هوشمند

نوشته های مشابه

ورودی/خروجی مسدودکننده و غیر مسدودکننده در جاوا

بهبود زمان راه‌اندازی برنامه‌های جاوا در زمان توسعه

چرا پارادیم «اکتور مدل» مهم است؟

با یادگیری اینکه «چیزها چطور کار می‌کنند» در برنامه‌نویسی پیشرفت کنید – قسمت دوم

یک دیدگاه

دیدگاهتان را بنویسید لغو پاسخ