I see that Appdynamics 4.2 claims to support Java 8 lambda instrumenting, but this support was removed in 4.3.
I cannot find anything in 4.3 release notes that mentions removing support for lambdas.
What's happened? Is it somehow related to JDK-8145964?
See 4.3.x Documentation⇒POJO Entry Points⇒Monitor Java Interface Static and Default Methods:
Note that another Java language feature introduced in Java 8, lambda method interfaces, are not supported by the AppDynamics Java Agent.
It’s possible that this is due to technical difficulties with JDK-8145964 as you suspect. But I’d also point out that this kind of Instrumentation would be questionable. It’s not this JRE generated class that implements any specific behavior, it’s the invoked target method.
Support for Lambda expressions has been in the product since 4.1 which shipped in 2015 I believe. That being said we are always enhancing support. These do have some limitations after initialization of the classes using them (dynamic instrumentation limits). The product should support them, we have added some additional capabilities and features for Lambda expressions in our next major release. Have you tried to contact help # appdynamics.com
Looks like it was not mentioned in release notes, but instead Support Advisory 56039 was raised. They indeed mention JDK-8145964 as a reason for removing the support.
Related
There is an package in Kotlin for continuations, but it's marked as experimental. There is no documentation other than the API, and no tutorial or examples anywhere that I could find. Does anyone know if it's already usable? What would be an example of its usage?
The Continuation interface is a part of coroutines support API in the standard library. You can start exploring the coroutines from the documentation page, or from the kotlinx.coroutines library repository, which contains an extensive coroutine programming guide.
Coroutines are experimental in Kotlin 1.1 and 1.2, but there was an announcement that they are going to stabilize in 1.3.
When you say "continuations", you actually mean "coroutines". Continuation is a part of that story.
kotlin-coroutines-informal by the JetBrains team is a great resource to start you off with coroutines. If you're looking to use them for async programming on Android, especially take note of the section on wrapping the callbacks which your existing async API provides, turning the existing Java function calls into Kotlin suspend funs.
About the status of experimental, check out Roman Elizarov's answer to that question. Here's a highlight:
Kotlin coroutines can and should be used in production. That was the chief reason to officially release them in Kotlin 1.1. Having released them, the JetBrains team had committed to maintain backwards compatibility with respect to any changes that are introduced to them in the minor releases as they evolve, while allowing people to safely try them in complex production applications.
There is absolutely no reason to wait for 1.3 to start using coroutines. Whatever you write today will work into the foreseeable future with no changes and, on top of that, it will be very easy to switch from kotlinx.coroutines.experimental to kotlinx.coroutines after the release. The APIs are already very stable and most of the changes are now in the area of channels and actors.
Once Kotlin 1.0 is out, what will be the compatibility policy? As a user, I hope Kotlin would keep its compatibility, either in source or binary. Just as serious as Java.
On contrast, Scala is a bad example. Failing to keep its binary compatibility between minor versions drove me away. And I believe a lot of users have left Scala partly because of its compatibility issue. This caused many libraries (including SBT at my time) cannot provide a complete suite of distributions for the whole series of Scala versions. This is just binary compatibility issue. Imagine if source compatibility was broken.
I have decided to use Kotlin in my company's commercial project. So I really need to be sure Kotlin is serious about keeping compatibility, instead of pursuing beauty.
Kotlin isn't out yet (UPD: now it is). Changes to the language are to be expected (even changes that break code and binary compatibility).
With the Beta release the binary format was finalized, so we shouldn't expect changes there anymore (but they might still happen if bugs have to be fixed).
After 1.0 gets released the language and the binary format is supposed to be backwards compatible forever.
Source: http://blog.jetbrains.com/kotlin/2015/11/the-kotlin-language-1-0-beta-is-here/
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
I just released my app but I am only able to make it compatible from 4.3 and up.
When I try to go any lower than 4.3 (xcode), it says I need to add code to make this work.
Does anyone know how to do this or has any suggestions? I would like my app to be compatible with 3.0 and onwards.
Thank you very much
You have to reach the least common code, what I mean by this is that you must find all the methods that are all incompatible within all of these versions of the OS. After that you will have to find each and every of it's functional equivalents. Then you can use conditional statements to check for every version and see what fits better or you can use the respondsToSelector method inherited from the NSObject class. In the end you have to test it on each device you are targeting :P
You can run this checkup list that I have always liked.
Edit:
I think I misunderstood your question though it has already been mentioned, be sure to check your deployment target in your build settings.
Checklist:
In your project's build settings…
Did you set the "iOS Deployment Target" to iOS 3?
Did you include the armv6 architecture in both, the built and the valid architectures?
In general:
Do you link to any framework that is not supported on iOS 3?
Do you use any methods, classes or other features that have been added later?
Suppose I have a software and I want to make cross-plataform plugins. You compile the plugin for a virtual machine, and any platform running my software would be able to run this code.
I am wondering if it is possible to use LLVM interpreter and bytecode for this purpose. Also, I am wondering if does make sense using LLVM for this purpose instead of something else, i.e. is it what LLVM was made for?
I'm not sure that LLVM was designed for it. However, I doubt there is anything that hasn't been done using LLVM1
Other virtual-machines based script engines are specifically created for the job:
LUA is very popular
Wikipedia lists some other Extension/embeddable languages under the Scripting language entry
If you're looking for embeddable virtual machines:
IKVM supports embedding JVM and CLR in a bridged mode (interoperable)
Parrot supports embedding (and includes a Python interpreter; mind you, you can just run python bytecode images)
Perl has similar architecture and supports embedding
Javascript supports embedding (not sure about the architecture of v8, but I guess it would use a virtual machine)
Mono's CLR engine supports embedding: http://www.mono-project.com/Embedding_Mono
1 including compiling c++ information to javascript to run in your browser...
There is VMIR (https://github.com/andoma/vmir) which is a LLVM bitcode interpreter / JIT engine that's intended to be embedded into other apps.
Disclaimer: I'm the author of it and it's still work-in-progress but works reasonable well.
In theory, there exist a limited subset of LLVM IR which can be portable across various platforms. You shall not specify alignments, you shall not bitcast pointers to integral types, you must avoid intrinsics, etc. Which means - you can't immediately use a code generated by a stock C compiler (llvm-gcc, Clang, whatever), unless you specify a limited target for it and implement sanitising LLVM passes. Another issue is that the bitcode format from different LLVM versions is not guaranteed to be compatible.
In practice, I would not go there. Mono is a reasonably small, embeddable, fast VM, and all the .NET stack of tools is available for it. VM itself is pretty low-level (as long as you do not care about the verifyability).
LLVM includes an interpreter, so if you can build this interpreter for your target platforms, you can then evaluate LLVM bitcode on the fly.
It's apparently not so fast though.
In their classic discussion (that you do not want to miss if you're a fan of open source, LLVM, compilers) about LLVM vs libJIT, that has happened long before LLVM became famous and established, the author of libJIT Rhys Weatherley raised this particular issue, he stated that LLVM is not suitable to be embedded, while Chris Lattner, the author of LLVM stated that otherwise, it is modular and you can use it in any possible fashion including embedding only the parts you need.