Tại sao tôi không thể sử dụng câu lệnh chuyển đổi trên Chuỗi?


1004

Chức năng này có được đưa vào phiên bản Java sau này không?

Ai đó có thể giải thích lý do tại sao tôi không thể làm điều này, như trong cách thức switchhoạt động của tuyên bố kỹ thuật của Java không?


195
Nó ở SE 7. 16 năm sau khi có yêu cầu. download.oracle.com/javase/tutorial/java/nutsandbolts/
Kẻ

81
Sun đã trung thực trong đánh giá của họ: "Don't hold your breath."lol, bug.sun.com/ormsdatabase/view_orms.do?orms_id=1223179
raffian

3
@raffian Tôi nghĩ đó là vì cô ấy đã thở dài hai lần. Họ cũng hơi muộn để trả lời, sau gần 10 năm. Cô ấy có thể đã đóng gói hộp ăn trưa cho cháu của mình sau đó.
WeirdElfB0y

Câu trả lời:


1004

Các câu lệnh chuyển đổi với Stringcác trường hợp đã được triển khai trong Java SE 7 , ít nhất 16 năm sau khi chúng được yêu cầu lần đầu tiên. Một lý do rõ ràng cho sự chậm trễ không được cung cấp, nhưng nó có thể phải làm với hiệu suất.

Triển khai trong JDK 7

Tính năng này hiện đã được triển khai trong javac quy trình "khử đường"; một cú pháp cấp cao, rõ ràng bằng cách sử dụng các Stringhằng số trong các casekhai báo được mở rộng tại thời gian biên dịch thành mã phức tạp hơn theo một mẫu. Mã kết quả sử dụng các hướng dẫn JVM luôn tồn tại.

A switchvới Stringcác trường hợp được dịch thành hai công tắc trong quá trình biên dịch. Đầu tiên ánh xạ mỗi chuỗi thành một số nguyên duy nhất, vị trí của nó trong công tắc ban đầu. Điều này được thực hiện bằng cách chuyển đổi đầu tiên trên mã băm của nhãn. Trường hợp tương ứng là một ifcâu lệnh kiểm tra sự bằng nhau của chuỗi; nếu có va chạm trên hàm băm, thử nghiệm là một tầng if-else-if. Công tắc thứ hai phản ánh rằng trong mã nguồn ban đầu, nhưng thay thế nhãn trường hợp bằng các vị trí tương ứng của chúng. Quy trình hai bước này giúp bạn dễ dàng duy trì kiểm soát dòng chảy của công tắc ban đầu.

Chuyển đổi trong JVM

Để biết thêm về kỹ thuật switch, bạn có thể tham khảo Đặc tả JVM, trong đó việc biên dịch các câu lệnh chuyển đổi được mô tả. Tóm lại, có hai hướng dẫn JVM khác nhau có thể được sử dụng cho một công tắc, tùy thuộc vào độ thưa của các hằng số được sử dụng trong các trường hợp. Cả hai đều phụ thuộc vào việc sử dụng hằng số nguyên cho từng trường hợp để thực thi hiệu quả.

Nếu các hằng số dày đặc, chúng được sử dụng như một chỉ mục (sau khi trừ đi giá trị thấp nhất) vào một bảng các con trỏ tableswitchlệnh Hướng dẫn lệnh.

Nếu các hằng số thưa thớt, việc tìm kiếm nhị phân cho trường hợp chính xác được thực hiện theo lookupswitchhướng dẫn.

Trong khử đường a switchtrên Stringcác đối tượng, cả hai hướng dẫn có khả năng được sử dụng. Điều lookupswitchnày phù hợp cho việc chuyển đổi đầu tiên trên mã băm để tìm vị trí ban đầu của vụ án. Các thứ tự kết quả là một phù hợp tự nhiên cho a tableswitch.

Cả hai hướng dẫn đều yêu cầu các hằng số nguyên được gán cho từng trường hợp được sắp xếp tại thời điểm biên dịch. Trong thời gian chạy, mặc dù O(1)hiệu năng tableswitchthường xuất hiện tốt hơn O(log(n))hiệu năng của lookupswitchnó, nó đòi hỏi một số phân tích để xác định xem bảng có đủ dày đặc để biện minh cho sự đánh đổi thời gian của Space không. Bill Venners đã viết một bài viết tuyệt vời bao gồm chi tiết này, cùng với cái nhìn sâu sắc về các hướng dẫn kiểm soát luồng Java khác.

Trước JDK 7

Trước JDK 7, enumcó thể xấp xỉ một Stringcông tắc dựa trên cơ sở. Điều này sử dụng phương thức tĩnhvalueOf được tạo bởi trình biên dịch trên mọi enumloại. Ví dụ:

Pill p = Pill.valueOf(str);
switch(p) {
  case RED:  pop();  break;
  case BLUE: push(); break;
}

26
Có thể nhanh hơn nếu chỉ sử dụng If-Else-If thay vì băm cho một công tắc dựa trên chuỗi. Tôi đã tìm thấy từ điển khá đắt tiền khi chỉ lưu trữ một vài mặt hàng.
Jonathan Allen

84
Một if-otherif-otherif-otherif-other có thể nhanh hơn, nhưng tôi sẽ lấy mã sạch hơn 99 lần trong số 100. Chuỗi, là bất biến, lưu mã băm của chúng, vì vậy "tính toán" hàm băm rất nhanh. Người ta sẽ phải mã hồ sơ để xác định những lợi ích có.
erickson

21
Lý do được đưa ra đối với việc thêm công tắc (Chuỗi) là vì nó sẽ không đáp ứng các đảm bảo hiệu suất mong đợi từ các câu lệnh switch (). Họ không muốn "đánh lạc hướng" các nhà phát triển. Thành thật mà nói tôi không nghĩ rằng họ nên đảm bảo hiệu suất của switch () để bắt đầu.
Gili

2
Nếu bạn chỉ sử dụng Pillđể thực hiện một số hành động dựa trên strtôi sẽ tranh luận nếu khác thì thích hợp hơn vì nó cho phép bạn xử lý strcác giá trị ngoài phạm vi ĐỎ, XANH mà không cần phải bắt ngoại lệ valueOfhoặc kiểm tra khớp một cách thủ công với tên của mỗi loại liệt kê mà chỉ cần thêm chi phí không cần thiết. Theo kinh nghiệm của tôi, nó chỉ có ý nghĩa khi sử dụng valueOfđể chuyển đổi thành một phép liệt kê nếu cần một biểu diễn an toàn kiểu của giá trị Chuỗi sau này.
MilesHampson

Tôi tự hỏi nếu trình biên dịch thực hiện bất kỳ nỗ lực nào để kiểm tra xem có bất kỳ cặp số (x, y) nào mà tập hợp các giá trị (hash >> x) & ((1<<y)-1)sẽ mang lại các giá trị riêng biệt cho mỗi chuỗi có hashCodekhác nhau không, và (1<<y)ít hơn hai lần số chuỗi (hoặc tại ít nhất không lớn hơn thế nhiều).
supercat

125

Nếu bạn có một vị trí trong mã của mình, nơi bạn có thể bật Chuỗi, thì có thể tốt hơn là cấu trúc lại Chuỗi để liệt kê các giá trị có thể, mà bạn có thể bật. Tất nhiên, bạn giới hạn các giá trị tiềm năng của Chuỗi bạn có thể có đối với các giá trị trong bảng liệt kê, điều này có thể hoặc không thể mong muốn.

Tất nhiên, bảng liệt kê của bạn có thể có một mục nhập cho 'khác' và phương thức fromString (Chuỗi), sau đó bạn có thể có

ValueEnum enumval = ValueEnum.fromString(myString);
switch (enumval) {
   case MILK: lap(); break;
   case WATER: sip(); break;
   case BEER: quaff(); break;
   case OTHER: 
   default: dance(); break;
}

4
Kỹ thuật này cũng cho phép bạn quyết định các vấn đề như trường hợp không nhạy cảm, bí danh, v.v. Thay vì phụ thuộc vào một nhà thiết kế ngôn ngữ để đưa ra giải pháp "một kích thước phù hợp với tất cả".
Darron

2
Đồng ý với JeeBee, nếu bạn đang chuyển đổi chuỗi có thể cần một enum. Chuỗi thường đại diện cho một cái gì đó đi đến một giao diện (người dùng hoặc cách khác) có thể thay đổi hoặc không thay đổi trong tương lai vì vậy tốt hơn thay thế nó bằng enums
hhafez

18
Xem xefer.com/2006/12/switchonopes để biết cách viết hay về phương pháp này.
David Schmitt

@DavidSchmitt Bài viết có một lỗ hổng lớn. Nó nắm bắt tất cả các ngoại lệ thay vì những trường hợp thực sự bị ném bởi methode.
M. Mimpen

91

Sau đây là một ví dụ hoàn chỉnh dựa trên bài đăng của JeeBee, sử dụng java enum thay vì sử dụng phương thức tùy chỉnh.

Lưu ý rằng trong Java SE 7 trở lên, bạn có thể sử dụng một đối tượng String trong biểu thức của câu lệnh switch.

public class Main {

    /**
    * @param args the command line arguments
    */
    public static void main(String[] args) {

      String current = args[0];
      Days currentDay = Days.valueOf(current.toUpperCase());

      switch (currentDay) {
          case MONDAY:
          case TUESDAY:
          case WEDNESDAY:
              System.out.println("boring");
              break;
          case THURSDAY:
              System.out.println("getting better");
          case FRIDAY:
          case SATURDAY:
          case SUNDAY:
              System.out.println("much better");
              break;

      }
  }

  public enum Days {

    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY,
    SUNDAY
  }
}

26

Công tắc dựa trên số nguyên có thể được tối ưu hóa thành mã rất hiệu quả. Các chuyển đổi dựa trên loại dữ liệu khác chỉ có thể được biên dịch thành một chuỗi các câu lệnh if ().

Vì lý do đó, C & C ++ chỉ cho phép chuyển đổi trên các loại số nguyên, vì nó là vô nghĩa với các loại khác.

Các nhà thiết kế của C # đã quyết định rằng phong cách này rất quan trọng, ngay cả khi không có lợi thế.

Các nhà thiết kế của Java dường như nghĩ giống như các nhà thiết kế của C.


26
Việc chuyển đổi dựa trên bất kỳ đối tượng có thể băm nào có thể được thực hiện rất hiệu quả bằng cách sử dụng bảng băm - xem .NET. Vì vậy, lý do của bạn không hoàn toàn chính xác.
Konrad Rudolph

Vâng, và đây là điều tôi không hiểu. Họ có sợ các đối tượng băm sẽ, về lâu dài, trở nên quá đắt?
Alex Beardsley

3
@Nalandial: thực sự, với một chút nỗ lực từ phía trình biên dịch, nó hoàn toàn không tốn kém vì khi biết bộ chuỗi, nó khá dễ dàng để tạo ra một hàm băm hoàn hảo (mặc dù điều này không được .NET thực hiện; có lẽ cũng không đáng để cố gắng
Konrad Rudolph

3
@Nalandial & @Konrad Rudolph - Trong khi băm một Chuỗi (do tính chất bất biến của nó) có vẻ như là một giải pháp cho vấn đề này, bạn phải nhớ rằng tất cả các Đối tượng không phải là cuối cùng có thể bị ghi đè. Điều này gây khó khăn trong thời gian biên dịch để đảm bảo tính nhất quán trong một công tắc.
martinatime

2
Bạn cũng có thể xây dựng một DFA để khớp với chuỗi (giống như các công cụ biểu thức chính quy làm). Có thể thậm chí hiệu quả hơn băm.
Nate CK

19

Một ví dụ về Stringsử dụng trực tiếp kể từ 1.7 cũng có thể được hiển thị:

public static void main(String[] args) {

    switch (args[0]) {
        case "Monday":
        case "Tuesday":
        case "Wednesday":
            System.out.println("boring");
            break;
        case "Thursday":
            System.out.println("getting better");
        case "Friday":
        case "Saturday":
        case "Sunday":
            System.out.println("much better");
            break;
    }

}

18

James Curran nói ngắn gọn: "Công tắc dựa trên số nguyên có thể được tối ưu hóa thành mã rất hiệu quả. Công tắc dựa trên loại dữ liệu khác chỉ có thể được biên dịch thành một loạt các câu lệnh if (). Vì lý do đó, C & C ++ chỉ cho phép chuyển đổi trên các loại số nguyên, vì nó là vô nghĩa với các loại khác. "

Ý kiến ​​của tôi, và chỉ có điều đó, là ngay khi bạn bắt đầu chuyển sang những người không phải là người nguyên thủy, bạn cần bắt đầu nghĩ về "bằng" so với "==". Trước hết, so sánh hai chuỗi có thể là một thủ tục khá dài, thêm vào các vấn đề hiệu suất được đề cập ở trên. Thứ hai, nếu có chuyển đổi trên chuỗi, sẽ có nhu cầu chuyển đổi trường hợp bỏ qua chuỗi, chuyển đổi chuỗi xem xét / bỏ qua miền địa phương, chuyển đổi chuỗi dựa trên regex .... Tôi sẽ chấp thuận một quyết định tiết kiệm nhiều thời gian cho nhà phát triển ngôn ngữ với chi phí của một ít thời gian cho các lập trình viên.


Về mặt kỹ thuật, regexes đã "chuyển đổi", vì về cơ bản chúng chỉ là các máy trạng thái; họ chỉ có hai "trường hợp" matchednot matched. (Tuy nhiên, không tính đến những thứ như [tên] nhóm / v.v.)
JAB

1
docs.oracle.com/javase/7/docs/technotes/guides/lingu/ Bang : Trình biên dịch Java tạo ra mã byte thông thường hiệu quả hơn từ các câu lệnh chuyển đổi sử dụng các đối tượng String so với các câu lệnh if-then-other.
Wim Deblauwe

12

Bên cạnh những lý lẽ tốt ở trên, tôi sẽ thêm rất nhiều người hôm nay thấy switch là phần còn lại đã lỗi thời của quá khứ thủ tục của Java (trở lại C lần).

Tôi không chia sẻ đầy đủ ý kiến ​​này, tôi nghĩ rằng nó switchcó thể có ích trong một số trường hợp, ít nhất là vì tốc độ của nó, và dù sao thì nó cũng tốt hơn một số chuỗi xếp tầngelse if mà tôi thấy trong một số mã ...

Nhưng thực sự, nó đáng để xem xét trường hợp bạn cần một công tắc, và xem nếu nó không thể được thay thế bằng một cái gì đó OO hơn. Ví dụ, enums trong Java 1.5+, có lẽ HashTable hoặc một số bộ sưu tập khác (đôi khi tôi rất tiếc chúng ta không có chức năng (ẩn danh) với tư cách là công dân hạng nhất, như trong Lua - không có chuyển đổi - hoặc JavaScript) hoặc thậm chí là đa hình.


"đôi khi tôi rất tiếc chúng ta không có chức năng (ẩn danh) với tư cách là công dân hạng nhất" Điều đó không còn đúng nữa.
dùng8397947

@dorukayhan Vâng, tất nhiên rồi. Nhưng bạn có muốn thêm một nhận xét ở tất cả các câu trả lời trong mười năm qua để nói với thế giới rằng chúng ta có thể có chúng nếu chúng ta cập nhật lên các phiên bản Java mới hơn không? :-D
PhiLho

8

Nếu bạn không sử dụng JDK7 trở lên, bạn có thể sử dụng hashCode()để mô phỏng nó. Vì String.hashCode()thường trả về các giá trị khác nhau cho các chuỗi khác nhau và luôn trả về các giá trị bằng nhau cho các chuỗi bằng nhau, nên nó khá đáng tin cậy (Các chuỗi khác nhau có thể tạo cùng mã băm như @Lii được đề cập trong một nhận xét, chẳng hạn như "FB""Ea") Xem tài liệu .

Vì vậy, mã sẽ trông như thế này:

String s = "<Your String>";

switch(s.hashCode()) {
case "Hello".hashCode(): break;
case "Goodbye".hashCode(): break;
}

Bằng cách đó, bạn đang chuyển đổi kỹ thuật trên một int.

Ngoài ra, bạn có thể sử dụng mã sau đây:

public final class Switch<T> {
    private final HashMap<T, Runnable> cases = new HashMap<T, Runnable>(0);

    public void addCase(T object, Runnable action) {
        this.cases.put(object, action);
    }

    public void SWITCH(T object) {
        for (T t : this.cases.keySet()) {
            if (object.equals(t)) { // This means that the class works with any object!
                this.cases.get(t).run();
                break;
            }
        }
    }
}

5
Hai chuỗi khác nhau có thể có cùng mã băm, vì vậy nếu bạn bật mã băm, nhánh trường hợp sai có thể bị lấy.
Lii

@Lii Cảm ơn bạn đã chỉ ra điều này! Mặc dù điều đó là không thể, nhưng tôi sẽ không tin nó hoạt động. "FB" và "Ea" có cùng mã băm, vì vậy không thể tìm thấy xung đột. Mã thứ hai có lẽ đáng tin cậy hơn.
HyperNeutrino

Tôi ngạc nhiên khi biên dịch này, vì casetôi nghĩ rằng, luôn luôn là các giá trị không đổi và String.hashCode()không phải là như vậy (ngay cả khi tính toán trong thực tế chưa bao giờ thay đổi giữa các JVM).
Staxman

@StaxMan Hừm thú vị, tôi chưa bao giờ dừng lại để quan sát điều đó. Nhưng vâng, casecác giá trị câu lệnh không nhất thiết phải được xác định tại thời gian biên dịch để nó hoạt động tốt.
HyperNeutrino

4

Trong nhiều năm, chúng tôi đã sử dụng bộ tiền xử lý (n nguồn mở) cho việc này.

//#switch(target)
case "foo": code;
//#end

Các tệp được xử lý trước được đặt tên là Foo.jpp và được xử lý thành Foo.java với tập lệnh ant.

Ưu điểm là nó được xử lý thành Java chạy trên 1.0 (mặc dù thông thường chúng tôi chỉ hỗ trợ trở lại 1.4). Ngoài ra, việc này dễ dàng hơn nhiều (rất nhiều chuyển đổi chuỗi) so với làm mờ nó bằng enum hoặc các cách giải quyết khác - mã dễ đọc, duy trì và hiểu hơn rất nhiều. IIRC (không thể cung cấp số liệu thống kê hoặc lý luận kỹ thuật tại thời điểm này) nó cũng nhanh hơn các tương đương Java tự nhiên.

Nhược điểm là bạn không chỉnh sửa Java nên có thêm một chút công việc (chỉnh sửa, xử lý, biên dịch / kiểm tra) cộng với một IDE sẽ liên kết lại với Java, một chút phức tạp (chuyển đổi trở thành một chuỗi các bước logic if / khác) và thứ tự trường hợp chuyển đổi không được duy trì.

Tôi sẽ không đề xuất nó cho 1.7+ nhưng nó hữu ích nếu bạn muốn lập trình Java nhắm mục tiêu các JVM trước đó (vì Joe công khai hiếm khi được cài đặt mới nhất).

Bạn có thể lấy nó từ SVN hoặc duyệt mã trực tuyến . Bạn sẽ cần EBuild để xây dựng nó.


6
Bạn không cần 1.7 JVM để chạy mã bằng công tắc Chuỗi. Trình biên dịch 1.7 biến công tắc String thành một cái gì đó sử dụng mã byte hiện có trước đó.
Dawood ibn Kareem

4

Các câu trả lời khác cho biết điều này đã được thêm vào trong Java 7 và đưa ra cách giải quyết cho các phiên bản trước đó. Câu trả lời này cố gắng trả lời "tại sao"

Java là một phản ứng đối với sự phức tạp quá mức của C ++. Nó được thiết kế để trở thành một ngôn ngữ sạch đơn giản.

String có một chút xử lý trường hợp đặc biệt trong ngôn ngữ nhưng đối với tôi có vẻ rõ ràng rằng các nhà thiết kế đã cố gắng giữ cho lượng vỏ đặc biệt và đường cú pháp ở mức tối thiểu.

chuyển đổi trên chuỗi khá phức tạp dưới mui xe vì các chuỗi không phải là kiểu nguyên thủy đơn giản. Nó không phải là một tính năng phổ biến tại thời điểm Java được thiết kế và không thực sự phù hợp với thiết kế tối giản. Đặc biệt là khi họ đã quyết định không sử dụng trường hợp đặc biệt == cho chuỗi, sẽ có một chút lạ và trường hợp hoạt động trong trường hợp == không.

Từ 1.0 đến 1.4, ngôn ngữ tự nó vẫn giữ nguyên khá nhiều. Hầu hết các cải tiến cho Java là về phía thư viện.

Tất cả đã thay đổi với Java 5, ngôn ngữ đã được mở rộng đáng kể. Các phần mở rộng tiếp theo tiếp theo trong phiên bản 7 và 8. Tôi hy vọng rằng sự thay đổi thái độ này được thúc đẩy bởi sự gia tăng của C #


Tường thuật về chuyển đổi (Chuỗi) phù hợp với lịch sử, dòng thời gian, bối cảnh cpp / cs.
Espresso

Đó là một sai lầm lớn khi không thực hiện tính năng này, mọi thứ khác là một cái cớ rẻ tiền mà Java đã mất nhiều người dùng trong những năm qua vì sự thiếu tiến bộ và sự bướng bỉnh của các nhà thiết kế không phát triển ngôn ngữ. May mắn thay, họ đã thay đổi hoàn toàn hướng và thái độ sau JDK7
firephil

0

JEP 354: Biểu thức chuyển đổi (Bản xem trước) trong JDK-13 và JEP 361: Biểu thức chuyển đổi (Tiêu chuẩn) trong JDK-14 sẽ mở rộng câu lệnh chuyển đổi để có thể được sử dụng làm biểu thức .

Bây giờ bạn có thể:

  • trực tiếp gán biến từ biểu thức chuyển đổi ,
  • sử dụng hình thức mới của nhãn chuyển đổi ( case L ->):

    Mã ở bên phải của nhãn chuyển đổi "trường hợp L ->" bị hạn chế là biểu thức, khối hoặc (để thuận tiện) cho câu lệnh ném.

  • sử dụng nhiều hằng số cho mỗi trường hợp, cách nhau bằng dấu phẩy,
  • và cũng không có thêm giá trị phá vỡ :

    Để mang lại một giá trị từ một biểu thức chuyển đổi, breakcâu lệnh with value được bỏ theo hướng có lợi cho yieldcâu lệnh.

Vì vậy, bản demo từ các câu trả lời ( 1 , 2 ) có thể trông như thế này:

  public static void main(String[] args) {
    switch (args[0]) {
      case "Monday", "Tuesday", "Wednesday" ->  System.out.println("boring");
      case "Thursday" -> System.out.println("getting better");
      case "Friday", "Saturday", "Sunday" -> System.out.println("much better");
    }

-2

Không đẹp lắm, nhưng đây là một cách khác cho Java 6 và dưới đây:

String runFct = 
        queryType.equals("eq") ? "method1":
        queryType.equals("L_L")? "method2":
        queryType.equals("L_R")? "method3":
        queryType.equals("L_LR")? "method4":
            "method5";
Method m = this.getClass().getMethod(runFct);
m.invoke(this);

-3

Đó là một làn gió ở Groovy; Tôi nhúng jar Groovy và tạo một groovylớp tiện ích để thực hiện tất cả những điều này và hơn thế nữa mà tôi thấy bực tức phải làm trong Java (vì tôi bị mắc kẹt khi sử dụng Java 6 trong doanh nghiệp.)

it.'p'.each{
switch (it.@name.text()){
   case "choclate":
     myholder.myval=(it.text());
     break;
     }}...

9
@SSpoke Bởi vì đây là một câu hỏi java và một câu trả lời Groovy không có chủ đề và một phích cắm vô dụng.
Martin

12
Ngay cả trong những ngôi nhà SW lớn bảo thủ, Groovy vẫn được sử dụng cùng với Java. JVM cung cấp một môi trường bất khả tri ngôn ngữ nhiều hơn một ngôn ngữ bây giờ, để trộn và sử dụng mô hình lập trình phù hợp nhất cho giải pháp. Vì vậy, có lẽ bây giờ tôi nên thêm một đoạn trong Clojure để thu thập thêm các lượt tải xuống :) ...
Alex Punnen

1
Ngoài ra, cú pháp hoạt động như thế nào? Tôi đoán Groovy là một ngôn ngữ lập trình khác ...? Lấy làm tiếc. Tôi không biết gì về Groovy.
HyperNeutrino

-4

Khi bạn sử dụng intellij cũng nhìn vào:

Tệp -> Cấu trúc dự án -> Dự án

Tệp -> Cấu trúc dự án -> Mô-đun

Khi bạn có nhiều mô-đun, hãy đảm bảo bạn đặt cấp độ ngôn ngữ chính xác trong tab mô-đun.


1
Không chắc câu trả lời của bạn có liên quan đến câu hỏi như thế nào. Ông hỏi tại sao một câu lệnh chuyển đổi chuỗi như sau không có sẵn: String mystring = "Something"; switch (mystring) {case "Something" sysout ("got here"); . . }
Deepak Agarwal

-8
public class StringSwitchCase { 

    public static void main(String args[]) {

        visitIsland("Santorini"); 
        visitIsland("Crete"); 
        visitIsland("Paros"); 

    } 

    public static void visitIsland(String island) {
         switch(island) {
          case "Corfu": 
               System.out.println("User wants to visit Corfu");
               break; 
          case "Crete": 
               System.out.println("User wants to visit Crete");
               break; 
          case "Santorini": 
               System.out.println("User wants to visit Santorini");
               break; 
          case "Mykonos": 
               System.out.println("User wants to visit Mykonos");
               break; 
         default: 
               System.out.println("Unknown Island");
               break; 
         } 
    } 

} 

8
OP không hỏi cách bật chuỗi. Anh ấy / cô ấy đang hỏi tại sao anh ấy / cô ấy không thể, vì những hạn chế về cú pháp trước JDK7.
HyperNeutrino
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.