vô hiệu hóa thời gian biên dịch phụ thuộc kiểm tra khi biên soạn các lớp Java

Question

Hãy xem xét hai lớp Java sau:

a.) class Test { void foo(Object foobar) { } } 

b.) class Test { void foo(pkg.not.in.classpath.FooBar foobar) { } } 

Hơn nữa, giả sử rằng pkg.not.in.classpath.FooBar không được tìm thấy trong classpath.

Lớp đầu tiên sẽ biên dịch tiền phạt bằng cách sử dụng javac chuẩn.

Tuy nhiên, lớp thứ hai sẽ không biên dịch và javac sẽ cung cấp cho bạn thông báo lỗi "package pkg.not.in.classpath does not exist".

Các thông báo lỗi là tốt đẹp trong trường hợp chung kể từ khi kiểm tra sự phụ thuộc của bạn cho phép trình biên dịch để cho bạn biết nếu bạn có một số tranh luận phương pháp sai vv

khi tốt đẹp và hữu ích kiểm tra này phụ thuộc vào thời gian biên dịch là AFAIK không phải nghiêm chỉnh cần thiết để tạo tệp lớp Java trong ví dụ trên.

1. Bạn có thể cho bất kỳ ví dụ mà nó sẽ là về mặt kỹ thuật không thể tạo ra một tập tin lớp Java hợp lệ mà không thực hiện biên dịch kiểm tra phụ thuộc thời gian?

2. Bạn có biết cách nào để hướng dẫn javac hoặc bất kỳ trình biên dịch Java nào khác bỏ qua việc kiểm tra phụ thuộc thời gian biên dịch không?

Hãy đảm bảo câu trả lời của bạn giải quyết cả hai câu hỏi.

Answer 1

Bạn có thể đưa ra bất kỳ ví dụ nào về kỹ thuật không thể tạo tệp lớp Java hợp lệ mà không thực hiện kiểm tra phụ thuộc thời gian biên dịch không?

xem xét mã này:

public class GotDeps { 
    public static void main(String[] args) { 
    int i = 1; 
    Dep.foo(i); 
    } 
} 

Nếu phương pháp mục tiêu có chữ ký public static void foo(int n), sau đó các hướng dẫn sẽ được tạo:

public static void main(java.lang.String[]); 
    Code: 
    0: iconst_1 
    1: istore_1 
    2: iload_1 
    3: invokestatic #16; //Method Dep.foo:(I)V 
    6: return 

Nếu phương pháp mục tiêu có chữ ký public static void foo(long n), sau đó số int sẽ được thăng cấp thành long trước lời gọi phương thức:

public static void main(java.lang.String[]); 
    Code: 
    0: iconst_1 
    1: istore_1 
    2: iload_1 
    3: i2l 
    4: invokestatic #16; //Method Dep.foo:(J)V 
    7: return 

Trong trường hợp này, nó sẽ không thể tạo ra các hướng dẫn gọi hoặc làm thế nào để cư cấu trúc CONSTANT_Methodref_info gọi trong hồ bơi liên tục lớp bằng số 16. Xem class file format trong spec VM để biết thêm chi tiết.

Answer 2

Tôi không thể xem cách bạn có thể cho phép điều này mà không phá vỡ kiểm tra loại java. Làm thế nào bạn sẽ sử dụng đối tượng tham chiếu của bạn trong phương pháp của bạn? Để mở rộng ví dụ của bạn,

class test { 
    void foo (pkg.not.in.classpath.FooBar foobar) { 
     foobar.foobarMethod(); //what does the compiler do here? 
    } 
} 

Nếu bạn gặp phải một số trường hợp bạn phải truy cập thư viện mà bạn không có quyền truy cập gần nhất có thể đến là để có được phương pháp thông qua phản ánh, một cái gì đó tương tự (phương pháp gọi từ bộ nhớ, có thể không chính xác)

void foo(Object suspectedFoobar) 
    { 
     try{ 
     Method m = suspectedFoobar.getClass().getMethod("foobarMethod"); 
     m.invoke(suspectedFoobar); 
     } 
     ... 
    } 

tôi có thể không thực sự nhìn thấy điểm để làm điều này, mặc dù. Bạn có thể cung cấp thêm thông tin về vấn đề bạn đang cố giải quyết không?

Answer 3

Tôi không nghĩ có cách như vậy - trình biên dịch cần biết về lớp của đối số, để tạo bytecode thích hợp. Nếu nó không thể định vị lớp Foobar, nó không thể biên dịch lớp Test.

Lưu ý rằng khi hai lớp của bạn là chức năng tương đương vì bạn không thực sự sử dụng đối số, chúng không giống hệt nhau và sẽ tạo ra mã byte khác nhau khi được biên dịch.

Vì vậy, tiền đề của bạn - trình biên dịch không cần phải tìm lớp để biên dịch trong trường hợp này - là không chính xác.

Sửa - nhận xét của bạn dường như được hỏi "có thể không phải là trình biên dịch chỉ bỏ qua thực tế và tạo ra các bytecode rằng sẽ thể thích hợp không?"

Câu trả lời là không -.. Nó có thể không According to the Java Language Specification, phương pháp chữ ký phải thực hiện các loại, đó là elsewhere defined được phân giải tại thời gian biên dịch

Điều đó có nghĩa rằng trong khi nó sẽ là một cách máy móc khá đơn giản để tạo một trình biên dịch có thể thực hiện những gì bạn đang yêu cầu, nó sẽ vi phạm JLS và do đó về mặt kỹ thuật sẽ không phải là trình biên dịch Java. . :-)

Answer 4

Giao diện trích xuất

pkg.in.classpath.IFooBar 

làm cho FooBar implements IFooBar và

class Test { void foo(pkg.in.classpath.IFooBar foobar) {} } 

class Test của bạn sẽ được biên soạn. Chỉ cần cắm thực hiện đúng tức là FooBar trong thời gian chạy sử dụng nhà máy và cấu hình. Hãy tìm một số thùng chứa IOC IOC.

Answer 5

Về điều duy nhất bạn có thể làm là sử dụng một số thao tác bytecode để chuyển đổi nó thành loại cụ thể hơn.

package pkg.not.in.classpath; 
public class FooBar { } 

từ này::

package pkg.not.in.classpath; 
class FooBar { } 

Vì vậy, chỉ có văn bản của bạn rằng đó là pháp lý để sử dụng Foobar có

Không có gì trong ngữ pháp Java cho một sử dụng pkg.not.in.classpath.FooBar để phân biệt đây là.

Ngoài ra còn một sự nhập nhằng giữa gói scoped lớp học và các lớp bên trong mã nguồn:

class pkg { 
    static class not { 
     static class in { 
      static class classpath { 
       static class FooBar {} 
      } 
     } 
    } 
} 

Các lớp bên trong cũng được gọi pkg.not.in.classpath.FooBar trong nguồn nhưng sẽ được gọi là pkg$not$in$classpath$FooBar hơn pkg/not/in/classpath/FooBar trong tập tin lớp. Không có cách nào mà javac có thể nói bạn có ý nghĩa gì mà không cần tìm nó trong classpath.

Answer 6

Java theo thiết kế thực hiện kiểm tra độ trễ thời gian biên dịch và sử dụng nó không chỉ để xác định loại mà để xác định cuộc gọi phương thức khi chúng bị quá tải. Tôi biết không có cách nào xung quanh điều đó.

Điều có thể được thực hiện (và được thực hiện cho, các trình điều khiển JDBC) là để trì hoãn việc kiểm tra phụ thuộc thông qua việc sử dụng sự phản chiếu. Bạn có thể lấy lớp từ Class.forName mà không cần trình biên dịch biết lớp ở thời gian biên dịch. Nói chung, tuy nhiên, điều này có nghĩa là mã được viết vào một giao diện và khi chạy một lớp được nạp để thực hiện giao diện.

Answer 7

Sẽ là vi phạm JLS để biên dịch một lớp mà không cần nhìn vào chữ ký loại của các lớp tùy thuộc vào. Không có trình biên dịch Java phù hợp nào cho phép bạn làm điều này.

Tuy nhiên ... có thể thực hiện điều gì đó tương tự. Cụ thể, nếu chúng ta có một lớp A và lớp B mà phụ thuộc vào A, người ta có thể làm như sau:

1. Compile A.java
2. Compile B.java chống A.class.
3. Chỉnh sửa A.java để thay đổi nó theo cách không tương thích.
4. Biên dịch A.java, thay thế lớp A. cũ.
5. Chạy ứng dụng Java bằng B.class và lớp A. mới không tương thích.

Nếu bạn làm điều này, ứng dụng sẽ không thành công với IncompatibleClassChangeError khi trình tải lớp thông báo tính không tương thích chữ ký.

Thực ra, điều này minh họa tại sao việc biên dịch bỏ qua các phụ thuộc sẽ là một ý tưởng tồi. Nếu bạn chạy một ứng dụng với các tập tin bytecode không nhất quán, (chỉ) phát hiện sự mâu thuẫn đầu tiên sẽ được báo cáo. Vì vậy, nếu bạn có nhiều mâu thuẫn, bạn sẽ cần phải chạy ứng dụng của bạn rất nhiều lần để "phát hiện" tất cả chúng. Thật vậy, nếu có bất kỳ tải động nào của các lớp (ví dụ: sử dụng Class.forName()) trong ứng dụng hoặc bất kỳ phụ thuộc nào của nó, thì một số vấn đề này có thể không hiển thị ngay lập tức.

Tóm lại, chi phí bỏ qua các phụ thuộc trong thời gian biên dịch sẽ chậm hơn trong việc phát triển Java và các ứng dụng Java ít tin cậy hơn.

Answer 8

Tôi tạo ra hai lớp: Caller và Callee

public class Caller { 
    public void doSomething(Callee callee) { 
     callee.doSomething(); 
    } 

    public void doSame(Callee callee) { 
     callee.doSomething(); 
    } 

    public void doSomethingElse(Callee callee) { 
     callee.doSomethingElse(); 
    } 
} 

public class Callee { 
    public void doSomething() { 
    } 
    public void doSomethingElse() { 
    } 
} 

tôi biên soạn các lớp này và sau đó tháo rời chúng với javap -c Callee > Callee.bc và javap -c Caller > Caller.bc. Đây được sản xuất như sau:

Compiled from "Caller.java" 
public class Caller extends java.lang.Object{ 
public Caller(); 
Code: 
0: aload_0 
1: invokespecial #1; //Method java/lang/Object."<init>":()V 
4: return 

public void doSomething(Callee); 
Code: 
0: aload_1 
1: invokevirtual #2; //Method Callee.doSomething:()V 
4: return 

public void doSame(Callee); 
Code: 
0: aload_1 
1: invokevirtual #2; //Method Callee.doSomething:()V 
4: return 

public void doSomethingElse(Callee); 
Code: 
0: aload_1 
1: invokevirtual #3; //Method Callee.doSomethingElse:()V 
4: return 

} 

Compiled from "Callee.java" 
public class Callee extends java.lang.Object{ 
public Callee(); 
Code: 
0: aload_0 
1: invokespecial #1; //Method java/lang/Object."<init>":()V 
4: return 

public void doSomething(); 
Code: 
0: return 

public void doSomethingElse(); 
Code: 
0: return 

} 

Trình biên dịch tạo ra một chữ ký phương pháp và một cuộc gọi typesafe invokevirtual cho phương pháp các cuộc gọi đến 'callee' - nó biết những gì lớp và những phương pháp đang được viện dẫn ở đây. Nếu lớp đó không có sẵn, trình biên dịch sẽ tạo ra chữ ký phương thức hoặc `invokevirtual 'như thế nào?

Có một JSR (JSR 292) để thêm một opcode 'invokedynamic' có thể hỗ trợ lời gọi động, tuy nhiên điều này hiện không được JVM hỗ trợ.