Home » Language IDEs » Java Development Tools (JDT) » From o.e.j.core.CompletionProposal to erased method signature?
From o.e.j.core.CompletionProposal to erased method signature? [message #1408138] |
Thu, 14 August 2014 10:22 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Andreas Sewe![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=sewe%40cqse.eu) Messages: 111 Registered: June 2013 |
Senior Member |
|
|
Hi,
I am currently trying to determine, given a o.e.j.core.CompletionProposal (of kind METHOD_REF* or METHOD_NAME_REFERENCE) and a TypeBinding for the method call's receiver, what method this will complete to. In particular, I want the erased method signature as it would appear in Java bytecode.
Doing this by-hand is quite challenging:
One option would be to get the numerous signatures from the CompletionProposal (getDeclarationSignature, getReceiverSignature, getSignature, even fOriginalSignature via reflection). Alas, replacing the various type parameters with their erased bounds is tricky, as the information what exactly 'T' refers to can come from the method's generic signature or any superclass's or interface's.
Another option is to get the availableMethods() from the receiver's TypeBinding (downcasting to ReferenceBinding) and then match those one by one against the CompletionProposal's signature until a match is found. Then, the erased method signature could be extracted from the matching MethodBinding. Here the tricky part is likely to be the matching (due to overloading).
As either way looks awfully complicated, I wonder whether there's a simpler/more direct way to determine what method a CompletionProposal refers to. Any help is greatly appreciated.
Best wishes,
Andreas
|
|
| | | | | |
Re: From o.e.j.core.CompletionProposal to erased method signature? [message #1408519 is a reply to message #1408311] |
Fri, 15 August 2014 09:02 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Andreas Sewe![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=sewe%40cqse.eu) Messages: 111 Registered: June 2013 |
Senior Member |
|
|
Quote:check MethodBinding.genericSignature() ...
Yes, that matches (up to a slashes/dots mismatch) CompletionProposal.getSignature() if MethodBinding.genericSignature() is not null, which happens if the method in question is not a generic method.
Now, simply matching CompletionProposal.getSignature() to MethodBinding.signature() in "genericSignature() == null" case is probably(?) a bad idea, as MethodBinding.signature()'s Javadoc states that it should only be called during/after code generation.
But matching against the method MethodBinding is unnecessary if the CompletionProposal.getSignature() is not a generic signature anyway. The only remaining question I thus have is whether there is an easy way to figure that out, i.e., whether CompletionProposal.getSignature() contains any generics-related information or not.
If there does not exist such a method (I couldn't find one, but JDT is huge, so I may have missed it), I guess I will have to dismantle the signature myself using Signature.getParameterTypes/getReturnType and then check with Signature.getTypeSignatureKind for anything generics-related. Does this sound like the way to go to you?
BTW, thanks for your help so far. Much appreciated.
|
|
| | | | |
Re: From o.e.j.core.CompletionProposal to erased method signature? [message #1411071 is a reply to message #1409967] |
Fri, 22 August 2014 10:15 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Andreas Sewe![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=sewe%40cqse.eu) Messages: 111 Registered: June 2013 |
Senior Member |
|
|
Hi Stephan. I am afraid I spotted a problem with the current approach of matching the CompletionProposal's signature against the MethodBinding's. Maybe you can help me out.
The problem occurs if the CompletionProposal's declaring type (as obtained from the LookupEnvironment) is a BinaryTypeBinding. In that case, ReferenceBinding.getMethod returns MethodBindings with parameters like Collection#RAW. An example:
For a declaring type of
public class java.util.ArrayList<E extends java.lang.Object>
extends Unresolved type java.util.AbstractList<E>
implements : List<E>, Unresolved type java.util.RandomAccess, Unresolved type java.lang.Cloneable, Unresolved type java.io.Serializable I get constructor overloads of
[public void <init>() , public void <init>(int) , public void <init>(Collection#RAW) ]
Now, matching the third of these against the CompletionProposal's Signature of "(Ljava/util/Collection<+TE;>;)V" is tricky (lots of fiddly String-manipulation, unless there exists a nice helper method that strips off type parameters).
Interestingly, other methods of ArrayList are kept with their type parameters:
so our approach will certainly help with matching in these cases.
Do you think that falling back to the CompletionProposal's signature with type parameters stripped off will work, i.e., that only parameterized arguments are "raw" in BinaryTypeBindings, but that I will always see type variables (like "E" in the "add" example above) if used as parameters? (All these type parameters and parameter types make my head hurt )
FWIW, the actual code is at <https://git.eclipse.org/r/#/c/31964/14/plugins/org.eclipse.recommenders.completion.rcp/src/org/eclipse/recommenders/completion/rcp/utils/ProposalUtils.java>, with the matching of overloads happening in lines 90 ff.
Best wishes,
Andreas
|
|
| | | | |
Re: From o.e.j.core.CompletionProposal to erased method signature? [message #1423996 is a reply to message #1414534] |
Mon, 15 September 2014 09:53 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
|
I meet this case and the same questions are you.
Thank you for sharing information.
Follow-up: I don't have a ReferenceBinding for the declaring class, unfortunately, just one for the actual receiver type. Do I thus have to implement the type hierarchy walking (probing with ReferenceBinding.getMethods() at each level) myself or does there exist a utility method somewhere in JDT that I can use for this?
Thank's!
Ads: Hiện nay https://internetvietnam.net/dang-ky-lap-dat-internet-fpt-tai-quan-3.html là rất cần thiết trong tình hình kinh tế đang phát triển và tình hình an ninh như hiện nay bởi quận 3 là quận trung tâm, là quận tập trung rất nhiều công ty, văn phòng, ngân hàng, showroom.
Quận 3 là một quận thuộc trung tâm thành phố nhu cầu lắp mạng fpt quận 3với những tòa nhà của chính phủ, viện bảo tang, bên cạnh đó là các tòa cao ốc văn phòng, công ty v.v... nhu cầu lắp đặt camera quan sát tại quận 3 ngày càng trở nên phổ biến hơn.
Lợi ích của hệ thống lắp đặt camera quan sát Quận 3
Tăng cường công tác bảo vệ an ninh cho cửa hàng 24/24h.
Phát hiện kịp thời những hành vi cướp đoạt tài sản,hạn chế đến mức thấp nhất những mất mát về tài sản.
Giúp người quản lý lắp đặt camera quận 4 https://internetvietnam.net/dang-ky-lap-dat-internet-fpt-tai-quan-4.html mọi hoạt động của nhân viên, rèn luyện tác phong làm việc nghiêm túc cho nhân viên
Ghi và lưu lại tài liệu để quảng bá thương hiệu.
Tạo sự tin tưởng cho khách hàng lắp mạng fpt quận 4 tới giao dịch,mua sắm.
Có thể giới thiệu với đối tác về cửa hàng của mình trực tuyến qua Internet, giúp tiết kiệm thời gian của mình cũng như đối tác.
Với phương trâm kinh doanh " Tất Cả Vì Sự Hài Lòng Khách Hàng" cộng thêm sự chuyên nghiệp, tận tâm của đội ngũ kỹ thuật, chúng tôi lắp đặt camera quận 5 đã dành được niềm tin yêu của khách hàng mà chúng tôi lắp mạng fpt quận 5 https://internetvietnam.net/dang-ky-lap-dat-internet-fpt-tai-quan-5.html đã hận hạnh được phục vụ trong suốt thời gian qua.
Dưới đây là một số gói lắp đặt camera quan sát giá rẻ mà Camera Tấn Phát ước tính ra cho quý khách hàng tham khảo và chọn lựa:
Khi quý khách có nhu cầu đến tham quan lắp đặt camera quận 6 hay mua sắm tại công ty chúng tôi, bên cạnh việc chiêm ngưỡng những thiết bị công nghệ được trưng bày khá da dạng và phong phú với nhiều mẫu mã chủng loại khác nhau thì chắc hẳn quý vị cũng sẽ thấy nhiều chiếc camera quan sat kết hợp để truyền tín hiệu đang âm thầm dõi mắt, giám sát an ninh, chúng không được phô trương, không được trưng bày đa dạng như bao sản phẩm khác thế nhưng chúng âm thầm bảo vệ mọi thứ tại đây. lắp đặt camera Quận 3 hiện nay có ba loại tiêu cự: cố định, không điều chỉnh được; có thể điều chỉnh lúc lắp đặt; có thể điều chỉnh lúc sử dụng.
Chúc mừng năm mới 2018!
[Updated on: Sat, 03 February 2018 05:46] Report message to a moderator
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 17:32:38 GMT 2024
Powered by FUDForum. Page generated in 0.04015 seconds
|