I heard that cglib takes less time as compare to java reflection for runtime object creation but when I checked, it is taking 100 times more time than java reflection.
Following is the result of my research
Creating 10000 objects
CGLIB:191 milliseconds
Normal:2 milliseconds
Reflection:24 milliseconds
I want to ask here that what are the benefits of using cglib/javaassit over java reflection.
I have found the benefits of cglib over Java reflection. Class generated using runtime byte-code generation library (cglib, javassit, byte buddy) can be altered at runtime without recompiling and Java Reflection classes can't be altered.
Related
I'm in the process of porting a Asp.Net Core Website targeting the full framework to a website that targets Asp.Net Core 3.
In that process I have hit a snag. The website references the Newtonsoft 11.0.3 NuGet package and among other things uses the Newtonsoft.Json.Serialization.DynamicValueProvider class.
Interestingly that class exists when targeting the full framework but does not exist when targeting netcoreapp3.1 and so Visual Studio is producing compilation errors stating that the class doesn't exist. At first that seemed crazy to me, but I checked the source code for the class and sure enough it contains the following conditional compilation statement wrapped around the whole class
#if HAVE_REFLECTION_EMIT
Apparently the netStandard 2.0 dll in the NuGet package that my netcoreapp3.1 project would use causes the conditional compilation statement to not include the DynamicValueProvider class.
So I did some poking around in the Newtonsoft.Json.Serialization namespace and I see that there is a ReflectionValueProvider class available that does not contain such conditional compilation and is available when targeting netcoreapp3.1
I've looked at the source code for both the DynamicValueProvider class and the ReflectionValueProvider class and I'm unclear on the difference. Both appear to get or set the value of a property or member type based on the MemberInfo passed in into the constructor. Both appear to use reflection to accomplish their work. As I mentioned, apparently DynamicValueProvider needs reflection Emit ability and ReflectionValueProvider does not. Emit ability apparently is used to Emit IL as best I can tell.
So I wonder if perhaps the two are drop in replacements for each other except that maybe DynamicValueProvider might be faster since it apparently leverages IL Emitting. But that's just a hunch. I'd prefer to have a more concrete understanding of the differences between the two classes before I start swapping the one for the other in this existing codebase as a way to get to .Net Core 3.
Can you provide me with better insight into the differences between the DynamicValueProvider
class and the ReflectionValueProvider class, or at least confirm my hunch?
We had updated Newtonsoft.Json from 9.* to 12.0.3 version, and observed performance degradation on paths that includes json serialization. All paths lead to DynamicValueProvider. Fortunately, we had global descendant for DefaultContractResolver, and I was able to overload CreateMemberValueProvider method to return ReflectionValueProvider.
For now we are continue testing the new version, but I can say that from performance perspective ReflectionValueProvider works faster than DynamicValueProvider.
I think there is a correlation with the fact that NetStandard 2.0 is also used to build Xamarin.Forms applications for iOS which require an AOT compilation.
As written here:
Limitations of Xamarin.iOS
"Since applications using Xamarin.iOS are compiled to static code, it is not possible to use any facilities that require code generation at runtime."
and
"No Dynamic Code Generation.
The System.Reflection.Emit is not available"
For example, this is a System.Text.Json limitation that actually cannot be used in Xamarin.Forms projects for iOS. More info here.
System.Text.Json Serializer does not appear to work on Xamarin iOS
As we know, there are two methods of library loading.
1) Static libraries (.a): Library of object code which is linked with, and becomes part of the application.
2) Dynamically linked shared object libraries (.so), which will link at execution of application and it can be used in two ways.
a) Dynamically linked at run time but statically aware.
b) Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.
After compilation, we can check the library dependency of type 'a' as below
objdump -x usr/bin/flashcp
.....
Dynamic Section:
NEEDED libgcc_s.so.1
NEEDED libc.so.6
My question is how to check/detect type 'b' library dependency ? Please suggest is there any way to detect before execution ?
Thanks in advance
Thiru
There's no way to generally check for libraries that are loaded dynamically and whose functions are called via function pointers.
In some special cases, as a hack, you can attempt various ways of reverse-engineering the executable, e.g. statically analyzing code around the calls to LoadLibrary and GetProcAddress on Windows. You could derive some heuristics that would work on many executables, but there's no way that's guaranteed to work, other than executing the code in a virtual machine and intercepting all calls to LoadLibrary/dlopen as they happen.
I am newbie in Qt, I have dll from 3rd party (NFC reader), this is C Win32 library (I don have header file, only dll file) so in C# i call it by using DLLImport Attribute. Now I want to using Qt to make the application and I don know how to do it. I hope somone will help me. Please explain clearly because I am very very fresh with Qt.
Thank you so much
Use QLibrary to load the library - it's a bit easier than using the native API (LoadLibrary etc.).
Use resolve("symbolname") on the QLibrary instance to get a pointer to a particular function. You then need to cast that pointer to the signature of the function you're actually going to call, and call via this cast pointer.
The documentation for your NPC Reader's DLL should describe the signatures of the functions, you needed that information for C# anyway.
Can we call COM exposed interface methods at runtime one by one? This can be achieved in the case of Win32 DLL's using reflections, but the same job needs to be done with COM.dll or COM.exe. We'll be able to view all exposed methods of that COM.dll or COM.exe and we need to call all of them one by one (Remember, I need to call unmanaged code, purely written in VC++ unmanaged code, that would not be .NET assembly).
Regards,
Usman
If the target COM object supports the IDispatch interface you could read its typelibrary and call the methods dynamically. But you still need to figure out what to pass should the method take any arguments.
Is it possible to find all interfaces (classes, parameters, ect..) normally registered with Component Object Model's (COM) TypeLib even though the TypeLib is completely empty? If so how would you go about doing this? I believe another term for this is an "Anonymous COM". I am sure that accessible interfaces exist for this COM because i have an application that is using a class that isn't listed in the TypeLib.
If the type library is blank, then there is no way that you can find information about the types in a COM library.
You need at least a coclass entry in the typelib to find an implementation of IUnknown.
If you have that, then you can actually create instances of the class and then call QueryInterface on IUnknown for the IDispatch implementation (if one exists).
If an IDispatch interface exists, you can then call GetTypeInfo to get information about the interfaces that are implemented.
If you need to make late-bound calls to IDispatch, then you will need to call the Invoke method.
Note, you mention the type library, but it is common practice for in-process COM servers to embed the type library in the dll that is the implementation of the types represented in the library. Are you sure that you haven't checked that as well? Or are you sure you have the type library and it is indeed blank?
If the type lib is indeed blank and the dll doesn't contain it, it's completely possible that the type lib was "private" in the sense that other clients were compiled against it. COM doesn't need a type-lib at runtime necessarily. The pattern for exposing IClassFactory interface implementations is to export a standard DLL function with a well-known signature.
One could easily call LoadLibrary, then call GetProcAddress and cast the result to IClassFactory. From there, they would use the private GUID and IID that they know (not from the type library) as well as the COM interfaces that they have defined privately and work from there.
The only reasoning I can think of for something like this is a form of obfuscation and/or addressing privacy/security concerns, only allowing clients the producer of the server approves of to call it.
It doesn't help you, but could explain why you are seeing a type library with no information in it and at the same time, see other clients consume the library.
Not using a type library in COM programming is fairly common. Any scripting language does, it uses IDispatch to discover supported methods and properties at runtime. IDispatch::GetIDsOfNames() or IDispatch::GetTypeInfo() gets that ball rolling. This is called late-binding. It is slow, but that doesn't matter in a scripting language.
Another standard way is through header files generated by MIDL from a .idl file that describes the interfaces and coclasses. You'll find many of them in the Windows SDK include directory, mshtml.h for example. But this is suitable only to unmanaged C/C++ code.
Using COM without a type library in a managed language like C# is difficult but not impossible. VB.NET is the better language, it supports late binding out of the box. C# will get better when version 4.0 arrives, it has a new "dynamic" keyword.