Text Block เป็น literal แบบใหม่ที่ช่วยให้การเขียนข้อความที่มีหลายบรรทัดและต้องมีการจัด format ง่ายขึ้น

หลายๆ ครั้งเราจำเป็นต้องเขียน code snippet เช่น XML, JSON, HTML เป็น String literal ใน Java ซึ่งเวลาเขียนทีก็ค่อนข้างลำบาก เช่น

เราต้องมาคอยใส่ \n และ + ทุกบรรทัด แต่ใน Java 17¹ เราสามารถเขียนโค้ดด้านบนด้วย Text Block ได้ดังนี้

ชีวิตดีขึ้นมากเลยทีเดียว

การใช้งานทั่วไปของ Text Block อันที่จริงก็มีเท่านี้แหละ แต่ถ้าใครต้องการความเป๊ะและรายละเอียดยิบย่อยของ Text Block เราไปดูกันต่อเลย

Note: Text Block ของ Java ทำงานต่างกับ Raw String ของ Kotlin นะครับ เวลาสลับไปมา ระหว่าง 2 ภาษานี้ต้องระวังนิดนึง

New Line ในบรรทัดสุดท้าย

ถ้าสังเกตตัวอย่างด้านบนดีๆ จะเห็นว่า Text Block ด้านบนเมื่อแปลงเป็น String literal แล้ว ที่บรรทัดสุดท้ายจะมี \n ติดมาตรง </html>\n

นั่นเป็นเพราะ closing delimiter """ ของเราอยู่คนละบรรทัดกับ </html> ทำให้มี new line character ติดมานั่นเอง ถ้าไม่อยากให้มีติดมาเราก็แค่ขยับ """ ไปอยู่ท้ายบรรทัดสุดท้าย หรืออีกวิธีคือใช้ line terminator \ (จะพูดถึงอีกทีในหัวข้อ escape sequences)

Leading White Space

white space ด้านหน้าจะโดนเอาออกเท่ากันทุกบรรทัด โดยจะเอาออกจนเท่ากับตำแหน่งของตัวอักษรตัวแรกของบรรทัดใดบรรทัดหนึ่ง

งงมั้ยครับ?

งงเนอะ ดูตัวอย่างดีกว่า ตัวอย่างด้านล่างใช้ . แทน white space ที่ถูกเอาออกไป

ถ้าเราเลื่อน closing delimiter มาทางซ้ายก็จะได้ leading white space นำหน้าแต่ละบรรทัด

Trailing White Space

white space ด้านหลังจะโดนเอาออกทั้งหมดทุกบรรทัดเลย เพราะโดยทั่วไป white space ด้านหลังมักจะมาโดยไม่ตั้งใจอยู่แล้ว อย่างไรก็ตาม ถ้าอยากให้มี trailing white space ก็สามารถทำได้ด้วยการใช้ escape sequence \s (จะพูดถึงอีกทีในหัวข้อ escape sequences)

Escape Sequence

ใน Java ตัว Text Block ไม่ใช่ Raw String ฉะนั้น escape sequence ต่างๆ ยังทำงานเหมือนเดิม

ตามตัวอย่างด้านบนเรายังใช้ \t \n และ escape sequence ทุกตัวได้เหมือนเดิม สำหรับ double quote เราไม่จำเป็นต้อง escape ก็ได้ ยกเว้นถ้าเราอยากพิมพ์ double quote ติดกัน 3 ตัว เราต้อง escape เป็น\" ตัวนึงเพื่อไม่ให้กลายเป็น """ delimiter

การที่ Text Block escape sequence ได้นี่เองทำให้เราต้องระวังมากๆ เวลา copy text จากที่อื่นมาวางต้องคอยดูว่าใน text นั้นมี escape sequence อยู่หรือเปล่า เช่นใน JSON อาจจะมี \n หรือ sequence อื่นๆ อยู่ใน value ก็ได้ ซึ่งจะทำให้ alignment ของ text ที่เราตั้งใจไว้ผิดเพี้ยนไป :(

Escape Sequence ใหม่

Java ออก escape sequence ใหม่มาใช้คู่กับ Text Block ได้แก่

\ (Line Terminator)

บางครั้งเราต้องการพิมพ์ข้อความบรรทัดเดียวยาวๆ จะทำเป็น String literal ก็ไม่สะดวก จะทำเป็น Text Block ก็จะโดนบังคับขึ้นบรรทัดใหม่ ในกรณีนี้เราสามารถใช้ \ เป็นตัวอักษรสุดท้ายในบรรทัดเพื่อไม่ให้มีการขึ้นบรรทัดใหม่ได้ ตามตัวอย่างด้านล่าง

Note: line-terminator \ใช้ได้กับเฉพาะ Text Block เท่านั้น ใช้กับ String literal ไม่ได้

\s (Single Space)

เนื่องจาก Text Block จะ trim trailing white space ออกเสมอ ถ้าเราอยากให้ text ของเรามี trailing white space สามารถทำได้โดยการใช้ \s เป็นรั้วกั้น

Note: \s ใช้ได้กับทั้ง Text Block และ String literal

การ Concat Text Block

Text Block เป็น String ธรรมดา สามารถ concat กับ String อื่นๆ ด้วยเครื่องหมาย + ได้ตามปกติ แต่เนื่องจากการเขียน Text Block ต้องเขียนหลายบรรทัด เวลาเขียนจะดูไม่ค่อยสวยงามเท่าไหร่

วิธีที่สวยกว่าคือใช้ class method String::format แทน

แต่วิธีที่สวยที่สุดคือใช้ instance method ใหม่ String::formatted

สรุป

• Text Block ช่วยในการเขียน multiline string เช่นพวก code snippet ต่างๆ
• Text Block ไม่ใช่ raw string! ยังมีการใช้ escape sequence เหมือนเดิม
• การจัด format ของ Text Block มีเรื่องยิบย่อยที่ต้องรู้เยอะ แนะนำให้ลองเล่นเองหรือตามไปดู source code ของบทความเพิ่มเติมครับ

[1]: Text Block feature release ใน Java 15

Feature ใหม่ใน Java 17: #6 Text Blocks was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

เชื่อว่าทุกคนคงเคยใช้ switch statement กันมาอยู่แล้ว เพราะฉะนั้นก็คงคุ้นเคยกับเหตุการณ์นี้กันดี

Color color = Color.ULTRAMARINE;
String result;
switch (color) {
  case CRIMSON, VERMILION:
    result = "Shades of Red";
  case HONEYDEW, EMERALD:
    result = "Shades of Green";
  case ULTRAMARINE, NAVY_BLUE:
    result = "Shades of Blue";
  default:
    result = "Undefined Shade";
}

พอเขียนเสร็จ ลองรันดู ก็จะพบว่า result เป็น "Undefined Shade" !?

เป็นไปได้ไง ทำไมไม่เป็น "Shades of Blue" ล่ะ ???

สักพักก็จะนึกขึ้นได้ เฮ้ย! switch case มัน fall through! ลืมใส่ break;! (ใครสนใจเรื่อง fall through เชิง ลึก อ่านเพิ่มเติมได้ที่ Understanding switch-case fall-through in Java)

ทางทีมงาน Java เองก็ไม่ได้นิ่งดูดาย ใน Java 17¹ เลยมีการเพิ่ม feature ให้กับ switch หลักๆ 2 เรื่อง

1. Arrow Labels

@Test
void switchWithArrowLabel() {
  Color color = Color.ULTRAMARINE;
  String result;
  switch (color) {
    case CRIMSON, VERMILION -> result = "Shades of Red";
    case HONEYDEW, EMERALD -> result = "Shades of Green";
    case ULTRAMARINE, NAVY_BLUE -> result = "Shades of Blue";
    default -> result = "Undefined Shade";
  }
  assertThat(result).isEqualTo("Shades of Blue");
}

จากการเขียน switch แบบเดิม case L : เราสามารถเขียนเป็น case L -> แทนได้ ซึ่งถ้าใช้เป็น Arrow Label แทนก็จะไม่มีการ fall through แล้ว!!

2. Switch Expressions

เราสามารถใช้ switch เป็น expression ได้แล้ว หรือถ้าให้พูดง่ายๆ ก็คือเราได้ return value จากการเรียกใช้ switch โดยค่าที่ return ออกมาก็คือค่าทางด้านขวาของแต่ละ case นั่นเอง จากตัวอย่างด้านบนเราสามารถเขียนใหม่ได้เป็น

@Test
void switchExpression() {
  Color color = Color.ULTRAMARINE;
  String result =
      switch (color) {
        case CRIMSON, VERMILION -> "Shades of Red";
        case HONEYDEW, EMERALD -> "Shades of Green";
        case ULTRAMARINE, NAVY_BLUE -> "Shades of Blue";
        default -> "Undefined Shade";
      };
  assertThat(result).isEqualTo("Shades of Blue");
}

Keyword yield

ในกรณีที่ด้านขวาของ case L -> มีมากกว่า 1 คำสั่ง เราสามารถเขียนเป็น block แล้วคืนค่าจาก block นั้นโดยใช้ keyword yield

@Test
void switchExpressionWithFullBlockAndYieldValue() {
  Color color = Color.EBONY;
  String result =
      switch (color) {
        case CRIMSON, VERMILION -> "Shades of Red";
        case HONEYDEW, EMERALD -> "Shades of Green";
        case ULTRAMARINE, NAVY_BLUE -> "Shades of Blue";
        default -> {
          System.out.println("Unhandled Color: " + color);
          yield "Undefined Shade";
        }
      };
  assertThat(result).isEqualTo("Undefined Shade");
}

นอกจากนี้เรายังสามารถใช้ switch expression กับการเขียน switch แบบเก่าคู่กับ yield ได้ด้วย

@Test
void switchExpressionWithTraditionalSwitchBlock() {
  Color color = Color.ULTRAMARINE;
  String result =
      switch (color) {
        case CRIMSON, VERMILION:
          yield "Shades of Red";
        case HONEYDEW, EMERALD:
          yield "Shades of Green";
        case ULTRAMARINE, NAVY_BLUE:
          yield "Shades of Blue";
        default:
          System.out.println("Unhandled Color: " + color);
          yield "Undefined Shade";
      };
  assertThat(result).isEqualTo("Shades of Blue");
}

ข้อควรระวังในการใช้ Switch Expressions

พอเราใช้ switch เป็น expression แล้วเราต้องมั่นใจว่าเราจะได้ return value จาก switch (หรือไม่ก็ throw Exception) ซึ่งอันที่จริงมันก็ตรงไปตรงมา เหมือนเวลาเราเขียน method ที่มีการ return value นั่นแล

// COMPILATION ERROR:
// the switch expression does not cover all possible input values
@Test
void switchRulesMustCoverAllPossibleValues() {
  Color color = Color.ULTRAMARINE;
  String result =
      switch (color) {
        case CRIMSON, VERMILION -> "Shades of Red";
        case HONEYDEW, EMERALD -> "Shades of Green";
        case ULTRAMARINE, NAVY_BLUE -> "Shades of Blue";
      };
  assertThat(result).isEqualTo("Shades of Blue");
}

ตัวอย่างด้านบนนี้จะ Compile ไม่ผ่าน เพราะสามารถมีกรณีที่ค่าของ color ไม่ตรงกับค่าที่มีในแต่ละ case เลย ซึ่งจะทำให้ไม่มีอะไร return ออกไปจาก switch expression นี้

ในทางปฏิบัติเราจึงควรห้อย default case ไว้เสมอเวลาใช้ switch expression ซึ่งเราจะ return default value อะไรไป หรือจะ throw Exception ก็แล้วแต่

สรุป

ใน Java 17 มี feature ใหม่เกี่ยวกับ switch ให้เราใช้ 2 อย่าง นั่นคือ

1. ใช้ Arrow Label แทน เพื่อป้องกันการ fall through
2. ใช้ switch เป็น expressions เพื่อเอา result จาก switch ได้ โดยอาจต้องใช้ keyword yield ช่วยในการ return ค่า

สำหรับใครที่ยังดูตัวอย่างในบทความไม่จุใจ ตามไปดู Source Code ต่อได้เลยคร้าบ

[1]: Switch Expressions release ตั้งแต่ Java version 14

Feature ใหม่ใน Java 17: #5 Switch Expressions was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sealed Class หรือ Sealed Interface ช่วยให้เราระบุได้ว่า class ไหนที่จะมา extend class หรือ implement interface ของเราได้

public sealed abstract class Pet permits Cat, Dog, Bird { ... }

public final class Cat extends Pet { ... }
public final class Dog extends Pet { ... }
public final class Bird extends Pet { ... }

ที่มาของปัญหา

ที่มาของ Sealed Class คือเรา ต้องการสร้าง superclass ที่ใครๆ ก็สามารถเข้าถึงได้แต่ไม่สามารถ extend ได้ เช่น

จาก class diagram ด้านบน เราอยากให้ DessertRestaurant สามารถ access Dessert ซึ่งเป็น superclass ของ Cake และ IceCream ได้ แต่ไม่อยากให้ Chocolate มา extend Dessert ได้

ก่อนหน้า Java 17 ถ้าเราอยากไม่อยากให้ class จาก package อื่นมา extend Dessert เราจะประกาศให้ Dessert เป็น package-private ตามโค้ดด้านล่าง

abstract class Dessert { ... }

public final class Cake extends Dessert { ... }
public final class IceCream extends Dessert { ... }

วิธีนี้กัน class อื่นมา extend ได้จริงแต่ปัญหาคือเราจะไม่สามารถใช้งาน Dessert จาก package อื่นได้ (extend ไม่ได้ และ access ไม่ได้)

// Compile Error: Cannot access Dessert from outside package
Dessert dessert = new Cake();

และถ้าเราจะแก้ให้ Dessert สามารถเข้าถึงได้โดยการเปลี่ยน access เป็น public ก็จะกลายเป็นว่า class อื่นๆ สามารถ extend Dessert ของเราได้อีก (extend ได้ และ access ได้)

จะเห็นได้ว่าการ extend และ access มาพร้อมๆ กันเสมอ Sealed Class จึงเกิดมาเพื่อแก้ปัญหานี้

Challenge for Java Geek: อันที่จริงเราพอมีหนทางแก้ปัญหานี้โดยไม่ใช้ Sealed Class อยู่นะครับ ลองคิดเล่นๆ ดูก่อน เดี๋ยวจะเฉลยด้านล่าง :)

การใช้งาน Sealed Class

public sealed abstract class Pet permits Cat, Dog, Bird { ... }

public final class Cat extends Pet { ... }

public sealed class Dog extends Pet {
  public static final class Hound extends Dog {}
  public static final class Terrier extends Dog {}
}

public non-sealed class Bird extends Pet { ... }

• ประกาศให้เป็น Sealed Class/Interface ด้วย keyword sealed
• Sealed Class ต้องประกาศ class ที่อนุญาตให้ extend ได้หลัง keyword permits ในกรณีที่ permitted subclass อยู่ใน source file เดียวกันทั้งหมด ไม่ต้องใช้ permits ก็ได้ เช่น class Dog ในตัวอย่างด้านบน
• Sealed Class กับ permitted subclass ต้องอยู่ package เดียวกัน หรือ module เดียวกัน
• Subclass ของ Sealed Class จะต้องประกาศเป็น final, sealedหรือ non-sealed โดย class ที่ประกาศเป็น non-sealed จะสามารถถูก extend โดย class อื่นได้
• เกร็ดเล็กเกร็ดน้อย: non-sealedเป็น keyword แรกใน Java ที่มี dash !!
• ใช้ Record เป็น subclass ได้ (Record เป็น final class by default)

สรุป

Sealed Class เหมาะกับการนำไปใช้ทำ library มาก เพราะเข้ามาช่วยจำกัด subclass ให้อยู่ในขอบเขตที่เราต้องการ โดยที่ library user ยังสามารถเรียกใช้ superclass ได้เหมือนเดิม

สามารถดู source code ในบทความนี้ได้ ที่นี่

เฉลย Challenge for Java Geek

ก่อนหน้า Java 17 เราก็พอจะทำให้ class อื่น access superclass โดยที่ไม่สามารถ extend ได้ ด้วยการใช้ non-public constructor

public abstract class Dessert {
  // package-private constructor
  Dessert() {}
}

public final class Cake extends Dessert { ... }
public final class IceCream extends Dessert { ... }

อย่างไรก็ตาม วิธีนี้ใช้กับ interface ไม่ได้อยู่ดีครับ

Feature ใหม่ใน Java 17: #4 Sealed Classes was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

ก่อนจะเข้าเนื้อหาใดๆ ขอสารภาพก่อนว่าทำงานมาเกินสิบปีผมเพิ่งรู้จัก keyword strictfp วันนี้นี่แหละครับ 555

สำหรับตัว feature Restore Always-Strict Floating-Point Semantics นี่คิดว่าคงน้อยคนมากที่จะได้ใช้ เอาเป็นว่าบทความนี้เรามาเรียนรู้ประวัติศาสตร์ของ strictfp กันดีกว่า

ปัญหาของ Floating Point

เป็นที่รู้กันดีว่าคอมพิวเตอร์ซึ่งมีหน่วยความจำจำกัดไม่สามารถแสดงค่าจำนวนจริงทั้งหมดได้ การเก็บทศนิยมในภาษาต่างๆ จึงใช้การประมาณค่าด้วย standard IEEE 754

การประมาณค่านี้ทำให้เราไม่สามารถคำนวณค่าทศนิยมที่ถูกเป๊ะๆ ได้ดังตัวอย่างด้านล่าง

Java

$ jshell
|  Welcome to JShell -- Version 17
|  For an introduction type: /help intro

jshell> 0.1 + 0.2;
$1 ==> 0.30000000000000004

Node.js

$ node
Welcome to Node.js v16.13.0.
Type ".help" for more information.
> 0.1 + 0.2
0.30000000000000004

Python

$ python3
Python 3.8.10 (default, Sep 28 2021, 16:10:42) 
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1 + 0.2
0.30000000000000004

ซึ่งนี่ก็ยัง ไม่ใช่สิ่งที่ strictfp จะเข้ามาแก้ไข แต่อย่างใด :P

แค่จะแสดงให้เห็นว่าการแสดง floating point ของแต่ละภาษาใช้ IEEE 754 เป็น standard

ประวัติศาสตร์ของ strictfp

การมาของ keyword strictfp นั้นจริงๆ แล้วมีความเกี่ยวเนื่องกับ CPU architecture ในอดีต เพราะฉะนั้นต้องย้อนไปดูประวัติศาสตร์กันนิดนึง

ช่วงก่อน Java 1.2 — strictfp ยังไม่ถือกำเนิด

Java ก่อน version 1.2 จะบังคับให้การคำนวณ floating point ทั้งหมดเป็นไปตาม standard IEEE 754 วิธีนี้ทำให้การคำนวณ floating point ไม่ว่าจะอยู่บน CPU architecture ไหนก็จะได้ผลการคำนวณเท่ากันเสมอ อย่างไรก็ตาม ณ เวลานั้นการคำนวณ floating point ด้วย standard IEEE 754 บน CPU architecture x86 ยุ่งยากและ performance ไม่ดีเท่าที่ควร

Java 1.2 ถึง Java 16 — การมาของ strictfp

จากเหตุผลด้านบนที่ว่าการคำนวณ floating point ทำได้ช้า Java จึงออก keyword ใหม่มานั่นก็คือ strictfp นั่นเอง การคำนวณ floating point ที่ระบุว่าเป็น strictfp จะบังคับให้การคำนวณเป็นไปตาม standard IEEE 754 (strict) ในทางตรงกันข้าม ถ้าไม่ระบุว่าเป็น strictfp การคำนวณ floating point ก็จะแล้วแต่ CPU architecture ของเครื่องที่ JVM run อยู่เลยซึ่งก็จะเร็วกว่าการคำนวณแบบ strict

Code snippet ของ class StrictMath ใน Java 16

public static strictfp double toRadians(double angdeg) {
  // Do not delegate to Math.toRadians(angdeg) because
  // this method has the strictfp modifier.
  return angdeg * DEGREES_TO_RADIANS;
}

วิธีการใช้ strictfp สามารถดูได้จาก ที่นี่

Java 17 — ลาก่อน strictfp

เมื่อเวลาผ่านไป CPU ตั้งแต่ Pentium 4 เป็นต้นมามี SSE2 extension ซึ่งช่วยให้การคำนวณ floating point แบบ strict เร็วขึ้นมาก ซึ่งทั้ง Intel และ AMD ก็ support SSE2 มาระยะเวลาหนึ่งแล้ว เป็นเหตุผลให้ Java กลับมาบังคับใช้ strict mode กับทุกๆ การคำนวณ floating point ไปเลยเหมือนสมัยก่อน Java 1.2 และเราก็ไม่จำเป็นต้องใช้ keyword strictfp อีกต่อไป

Code snippet ของ class StrictMath ใน Java 17

public static double toRadians(double angdeg) {
  return Math.toRadians(angdeg);
}

สรุป

ขอย้ำอีกครั้งนะครับว่า การมาของ strictfp ตั้งแต่ Java 1.2 จนกระทั่งจากไปใน Java 17 ไม่ได้เกี่ยวข้อง กับเรื่องความไม่แม่นยำในการคำนวณทศนิยมเลย แต่เป็นเพราะต้องการให้ทุกๆ CPU Architecture คำนวณออกมาเหมือนกันต่างหาก

อย่างไรก็แล้วแต่ คิดว่าคนส่วนใหญ่คงไม่ได้ยุ่งกับ keyword strictfp นี้สักเท่าไหร่ แต่สำหรับคนที่เคยใช้ strictfp มาก่อนหน้านี้ ถ้า upgrade มาเป็น Java 17 ก็ไม่ต้องใช้แล้วนะครับ :)

หมายเหตุ

ใครที่อยากได้การคำนวณทศนิยมเลขฐานสิบได้เป๊ะๆ ให้ไปใช้ class BigDecimal แทนครับ

Feature ใหม่ใน Java 17: #3 Restore Always-Strict Floating-Point Semantics was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Record คือ class ประเภทใหม่ที่หลายคนรอคอยให้ Java มีแบบนี้สักที¹

syntax การประกาศ Record ก็เหมือน class ทั่วไปเพียงแต่เปลี่ยนคำว่า class เป็น record แทน และต่อท้ายในวงเล็บด้วย component สำหรับ Record นั้น

public record Rectangle(int width, int height) { }

แค่เห็นก็ว้าวแล้วใช่มั้ย
เย่! ในที่สุด Java ก็มี data class เหมือน Kotlin แล้ว!! — ผิด
เย่! ในที่สุดก็ไม่ต้องใช้ Lombok แล้ว!! — ผิด

ถึงแม้หน้าตาจะคล้ายกับ data class ของ Kotlin และการเอาไปใช้งานบางจุดก็ใกล้เคียงกันมาก แต่ก็ไม่ได้เหมือนกันซะทีเดียว เพราะฉะนั้นเราไปดูรายละเอียดกันก่อนดีกว่า

ที่มาของปัญหา

แรงจูงใจที่ทำให้เกิด Record class ขึ้นมาคือประโยคที่เราเจอคนบ่นถึง Java กันเป็นประจำ “Java is too verbose” หรือ Java ใช้คำฟุ่มเฟือย เกินไปนั่นเอง โดยเฉพาะ class ที่ทำหน้าที่เป็นแค่ตัวส่งข้อมูลที่ไม่ได้มีการแก้ไขข้อมูลใดๆ (immutable data carrier) ซึ่งเวลาที่เราจะสร้าง class แบบที่ว่าขึ้นมามีสิ่งที่เราต้องทำเยอะมาก

• ประกาศ class
• ประกาศ private final field
• ประกาศ constructor ที่รับค่ามาใส่ field
• ประกาศ getter method
• สร้าง method equals, hashCode
• และอาจจะสร้าง method toString ด้วยเพื่อความสะดวก

บางคนอาจบอกว่าของแค่นี้ใช้ IDE generate ออกมาให้ก็ได้ วิธีนี้สะดวกคนเขียนแต่คนที่มาอ่านโค้ดเราเห็นแบบนี้ก็ขี้เกียจอ่านอยู่ดี Java ก็เลยสร้าง Record ขึ้นมาเพื่อเป็น immutable data carrier โดยเฉพาะ

การทำงานของ Record

อย่างที่บอกไว้ว่าเป้าหมายของ Record คือการสร้าง class ที่เป็น immutable data carrier เพราะฉะนั้นจากตัวอย่างของ Record ด้านบนจะเทียบเท่าได้กับ class ดังนี้²

public record Rectangle(int width, int height) {

  private final int width;
  private final int height;

  public Rectangle(int width, int height) {
    this.width = width;
    this.height = height;
  }

  public int width() {
    return this.width;
  }

  public int height() {
    return this.height;
  }

  public boolean equals(Object o) {
    if (!(o instanceof Rectangle)) return false;
    Rectangle other = (Rectangle) o;
    return other.width == width && other.height == height;
  }

  public int hashCode() {
    return Objects.hash(width, height);
  }

  public String toString() {
    return String.format("Rectangle[width=%s, y=%s]", width, height);
  }
}

สิ่งที่ Record ทำให้เราโดยอัตโนมัติเลย ได้แก่

• private final field ซึ่งชื่อและ type เป็นตามที่เราระบุไว้ใน Record header
• Record class จะไม่มี default constructor แต่จะสร้าง constructor ที่รับ parameter ตามที่เราระบุไว้ใน Record Header และทำการ assign ค่าให้กับ field ในข้อแรก
• getter method ที่ชื่อไม่ได้ขึ้นต้นด้วย get !!
• method equals(), hashCode(), และ toString()

ถือว่า Record ช่วยเราประหยัดเวลาสร้าง immutable data class ไปได้เยอะ

Local Record Class

บ่อยครั้งที่เราทำงานกับ stream แล้วอยากให้ map() return ค่าออกมามากกว่า 1 ตัว ซึ่งถ้าเป็นในอดีตเราก็จะมอบหน้าที่นี้ให้กับ Tuple class แต่ตอนนี้เรามีอีกหนึ่งทางเลือกนั่นก็คือการใช้ Local Record Class

เราสามารถประกาศ Record class ภายใน method แล้วใช้งานในนั้นได้เลยดังตัวอย่างด้านล่าง

private List<String> findGradeAStudent() {
  // local record
  record StudentGrade(StudentScore result, String grade) {}

  return getExamResults() // List<StudentScore>
      .stream()
      .map(ss -> new StudentGrade(ss, calculateGrade(ss.score())))
      .filter(g -> g.grade().equals("A"))
      .map(StudentGrade::result)
      .map(StudentScore::name)
      .collect(Collectors.toList());
  }
}

การ customize Record class

ถ้าเราต้องการเพิ่ม logic หรือแก้ไข default behavior ที่ Record class มีให้ เราก็สามารถทำได้เช่นเดียวกับ class ปกติทั่วไป

Constructor

เราสามารถใส่ validation หรือดัดแปลงค่า parameter ใน constructor ได้ โดย Record สามารถเขียน constructor ในรูปแบบ compact canonical constructor ได้ด้วย

record DoubleSizeRectangle(int width, int height) {
  DoubleSizeRectangle {
    if (width <= 0 || height <= 0) {
      throw new IllegalArgumentException("Invalid width or height");
    }
    width *= 2;
    height *= 2;
  }
}

จะมีค่าเท่ากับ

record DoubleSizeRectangle(int width, int height) {
  DoubleSizeRectangle(int width, int height) {
    if (width <= 0 || height <= 0) {
      throw new IllegalArgumentException("Invalid width or height");
    }
    width *= 2;
    height *= 2;

    // Initialization
    this.width = width;
    this.height = height;
  }
}

Accessor methods, equals, hashCode, toString, and other methods

เราสามารถประกาศ accessors, equals, hashCode, และ toString เองเพื่อ customize behavior ของ method เหล่านี้ได้เหมือน class ทั่วๆ ไป สิ่งที่ควรระวังเช่นเรื่อง contract ระหว่าง equals กับ hashCode ก็ยังเหมือนเดิม หรือถ้าจะสร้าง instance method / class (static) method อื่นๆ ขึ้นมาก็ได้เหมือนกัน

Implement Interface

ถึงแม้ว่า Record จะไม่สามารถ extend class อื่นได้ (ดูคำอธิบายด้านล่าง) แต่สามารถ implement interface ได้ตามปกติ เช่น เราอาจจะอยากให้ Record ของเรา implement Comparable interface ได้เป็นต้น

Annotation

การใช้ Annotation กับ Record จะค่อนข้าง tricky นิดนึง เพราะ component ใน Record header อาจจะหมายถึง field, constructor parameter, หรือ accessor method ก็ได้
Annotation ที่วางไว้บน component จะไปโผล่ที่ไหนนั้นขึ้นอยู่กับ @Target ของตัว Annotation เช่นถ้าเป็น @Target(ElementType.FIELD) ตัว Annotation ก็จะไปโผล่บน private field ของ Record นั้น ตัวอย่างเช่น

@OnType
public record TestSubject(
    @OnParameter int p1,
    @OnMethod int p2,
    @OnField int p3,
    @OnFieldAndParameter int p4) {
}

จะมีค่าเท่ากับ

@OnType
public record TestSubject(int p1, int p2, int p3, int p4) {

  ...
  @OnField private final int p3
  @OnFieldAndParameter private final int p4

  public TestSubject(
        @OnParameter int p1,
        int p2,
        int p3,
        @OnFieldAndParameter int p4) {
    ...
  }

  ...

  @OnMethod
  public int p2() {
    return this.p2;
  }

  ...

}

สิ่งที่ Record class ทำไม่ได้

ด้วยความที่ Record ถูกออกแบบมาให้ immutable และ state ของ Record instance ขึ้นอยู่กับ component ใน Record header เท่านั้น เพราะฉะนั้นอะไรก็ตามที่ขัดกับความตั้งใจนี้จะไม่สามารถทำได้

• Record class ไม่สามารถ extend class อื่นได้
• Record class ถือเป็น final class และห้ามเป็น abstract
• ไม่สามารถมี instance field อื่นๆ ใน Record class ได้เพราะจะทำให้ state ของ instance ไม่ขึ้นอยู่กับ Record component เพียงอย่างเดียว
• ไม่สามารถมี native method ได้

สรุป

Record class ช่วยเพิ่มความสะดวกในการสร้าง immutable data class และยังสามารถใช้แทน Tuple ภายใน method ได้โดยการสร้าง Local Record Class

ถึงแม้จะยังเทียบกับ data class ของ Kotlin และ @Data ของ Lombok ที่สามารถสร้าง mutable data class ได้ด้วยไม่ได้ แต่ก็ถือว่าเป็น feature ที่ใครที่ upgrade เป็น Java 17 แล้วน่าเอามาใช้ครับ

สำหรับใครที่อยากดูการใช้งานของ Record class เพิ่มเติมตามไปดูได้ ที่นี่

[1]: feature นี้ release ใน Java 16
[2]: เป็นแค่ตัวอย่างสำหรับเปรียบเทียบนะครับ implementation จริงๆ ขึ้นอยู่กับ VM แต่ละตัวซึ่งอาจต่างจากที่เขียน

Feature ใหม่ใน Java 17: #2 Records was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

สำหรับในบทความซีรี่ส์นี้เราจะมาดูในส่วนที่เป็นเฉพาะ Language Feature กันว่ามีอะไรใหม่ในตัวภาษาบ้าง ซึ่งสำหรับตอนแรกนี้ขอนำเสนอ Feature Pattern Matching for instanceof

ที่มาของปัญหา

ปัญหาที่ Feature นี้จะเข้ามาแก้ก็คือเรื่องความเยิ่นเย้อในการตรวจสอบและ cast instance type

ด้านล่างนี่คือ code ในการตรวจสอบ instance type และ cast ที่หลายๆ คนคงคุ้นเคยกันดี

if (obj instanceof Car) {
  Car c = (Car) obj; // +_+
  c.drift();
}

จะเห็นได้ว่าบรรทัดที่ทำการ cast เป็นอะไรที่เยิ่นเย้อ boilerplate code มากๆ ยังไม่นับว่าทั้งหมดนี้เราต้องพิมพ์คำว่า Car ถึง 3 ครั้ง!

Pattern Matching for instanceof

ด้วย feature นี้ของ Java 17¹ code เราจะกระชับขึ้น กลายเป็น

if (obj instanceof Car c) {
  c.drift();
}

อาจจะไม่ได้เป็น feature ที่เปลี่ยนแปลงอะไรมากนัก แต่ก็ช่วยทำให้ code ของเรากระชับขึ้นและมีโอกาสมีข้อผิดพลาดได้น้อยลง

ข้อควรระวัง

จุดที่น่าสนใจจุดหนึ่งของ feature นี้ก็คือ scope ของตัว pattern variable

ก่อนที่จะอธิบายถึงเรื่อง scope ก็ขออธิบายคำศัพท์นิดนึง จากในภาพด้านล่างตรงส่วน String s เราเรียกว่า Type Pattern และตรงตัวแปร s เรียกว่า Pattern Variable

pattern variable ใช้ concept ที่เรียกว่า flow scoping ซึ่งหมายความว่า pattern variable จะอยู่ใน scope เฉพาะในจุดที่ compiler สามารถบอกได้ว่า pattern นี้ match

ถ้าจากตัวอย่างด้านบนก็หมายความว่า เราจะเรียกใช้ตัวแปร c ได้ก็ต่อเมื่อมันถูกเรียกใช้ในจุดที่ compiler มั่นใจว่า c คือ Car เท่านั้น

if (obj instanceof Car c) {
  c.drift(); // เรียกใช้ c ตรงนี้ได้
}
c.drift(); // compile error เรียกใช้ c ตรงนี้ไม่ได้

หรือถ้าเราเขียนอีกแบบ

if ( !(obj instanceof Car c) ) {
  c.drift(); // เรียกใช้ c ตรงนี้ไม่ได้ เพราะถ้าเข้า block นี้แปลว่า c ไม่ใช่ Car
  throw new RuntimeException();
}
c.drift(); // เรียกใช้ c ตรงนี้ได้! เพราะ compiler มั่นใจว่าบรรทัดนี้ c คือ Car

ซึ่งถ้าเราใช้ boolean operator ควบคู่ไปกับ instanceof ด้วยก็ยังใช้หลักการเดียวกัน

if (obj instanceof String s && s.length() > 0) {
  // แบบนี้สามารถทำได้ เพราะด้านหลัง operator && s เป็น String แน่ๆ 
}

if (obj instanceof String s || s.length() > 0) {
  // แต่แบบนี้ compile error เพราะหลัง operator || s อาจจะไม่ใช่ String ก็ได้
}

สรุป

Java 17 เพิ่ม Feature Pattern Matching for instanceof เข้ามาเพื่อให้การเขียน check + cast type กระชับขึ้น โดยที่มีข้อควรระวังเรื่อง scope ของ pattern variable อยู่เล็กน้อย
หลักการในการจำง่ายๆ ก็คือ pattern variable จะอยู่ใน scope เฉพาะในจุดที่มัน match เท่านั้น ครับ

[1]: feature นี้เพิ่มเข้ามาตั้งแต่ Java 16

Feature ใหม่ใน Java 17: #1 Pattern Matching for instanceof was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a microservice architecture, it is common to pass a custom HTTP header, let’s say: “Correlation-ID”, from one service to another. It might also be equally common to record that value in the log for debugging later.

If you are using Spring Cloud Sleuth, this task would be quite easy with Sleuth’s baggage field feature. You will just have to add a couple of properties to the configuration file and Voilà!

However, my situation is somewhat different in that I need to do it programmatically. Since I have spent a considerable amount of time on it, I decided to write an article about it for future reference.

Setup

The first step is to add the spring-cloud-sleuth dependency to your project.

<dependencies>
  ...
  <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
  </dependency>
  ...
</dependencies>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>${spring-cloud.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Note that I set spring-cloud.version to 2020.0.3 which resolves to Sleuth 3.0.3. If you are using Sleuth 2.x, the code here may not work for you.

For this article, I created two simple microservices, A and B, that talk to each other. The controller code of the service A looks like this:

The code of B controller is pretty similar but without calling another service.

Configure Sleuth Baggage Using Application Properties

First let’s take a look on how to achieve this without any coding. Just add these two properties to application.properties of both services:

spring.sleuth.baggage.remote-fields=Correlation-Id (1)
spring.sleuth.baggage.correlation-fields=Correlation-Id (2)

(1) Tell Sleuth to get the value from this header name(s) and propagate to remote services
(2) Set the baggage value(s) to Slf4j’s MDC

Call the service A with curl -H “Correlation-Id: 528491” http://localhost:8080/a/message and this is the result:

// Service-A Log
2021-09-04 12:02:52,215|INFO|service-a|528491|Service-A is called with Correlation-Id: 528491

// Service-B Log
2021-09-04 12:02:52,321|INFO|service-b|528491|Service-B is called with Correlation-Id: 528491

You can see that the Correlation-Id header value is put into the log and propagated from A to B.

Configure Sleuth Baggage Programmatically

Alternatively, if you want to (or have to) do it programmatically, Sleuth allows us to define Customizer beans that will be used to customize the Tracer object. We will use BaggagePropagationCustomizer to add a remote-field baggage and use CorrelationScopeCustomizer to put the value into MDC.

If you would like to know how this works behind the scenes, I suggest you dive into Sleuth’s BraveBaggageConfiguration code.

Then we test by calling the service A with curl -H “Correlation-Id: 314159” http://localhost:8080/a/message and see the result:

// Service-A Log
2021-09-04 13:58:58,010|INFO|service-a|314159|Service-A is called with Correlation-Id: 314159

// Service-B Log
2021-09-04 13:58:58,076|INFO|service-b|314159|Service-B is called with Correlation-Id: 314159

Summary

In this article, we display 2 ways to propagate HTTP headers from one microservice to another. Normally, we would just use Sleuth provided configuration properties. In other cases or if you need advanced customization, you can utilize the Customizers to configure baggage fields to suit your needs.

The complete source code in this article can be found here: https://github.com/withyuu/sleuth-baggage-programmatically

Passing HTTP headers to another microservice and put them to the log programmatically using Spring… was originally published in Ascend Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.