Can you safely deserialize with OpenJDK some binary data that we got by serializing something with Oracle JDK? (and vice-versa)
Let’s assume the java version is the same (and that the class code is available, and is the same, in both stages).
Is the exact way Oracle JVM serializes objects considered public information?
To expand on comments from #morgano, #RealSkeptic and #EJP (to whom credit should be given): yes, Java Object serialization is directed by an official specification, which is public, so any JVM implementation that does serialization should conform to it, or not be called a JVM.
I will say it is not entirely safe. In my Android app, I can not deserialize data on an Android 7 device which has been serialized on an Android 6 device. Apparently, Google switched to OpenJDK in Android 7.
The error I get is:
java.io.StreamCorruptedException: invalid type code: 71
This problem was reported here in a similar fashion
This poses quite a problem since my app sends serialized data over the internet and it will not be compatible if it runs on both Android 6(or lower) and Android 7.
Related
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.
I've installed osx 10.10 ( Yosemite ) and since then the device (NI-USB 6210) is not working anymore.
The problem is obviously driver related. I called National Instruments and they confirmed the issue, and they also told me that the problem will be probably fixed in the next release of the nidaqmx, that will happen not so soon.
So their suggestion is to downgrade to Mavericks, which kinda suck.
They also told me to check the compatibility table
http://www.ni.com/labview/os-support/i/
in order to know when if will be supported, until then I have to struggle with downgrade or find a workaround which would be the best thing. anybody found a solution to this problem lately?
Depending on your device and how you program it, you should be able to get it working on Yosemite using NI-DAQmx Base 14.0 [1].
NI-DAQmx Base 14.0 does not claim Yosemite support, but after inspecting the installer and running a few tests, here is what I have determined:
The installer, kernel extensions, frameworks, and applications are signed by National Instruments, which means Gatekeeper won't interrupt you with "are you sure you want to do this?" questions.
Both 32-bit and 64-bit LabVIEW APIs are provided.
Both 32-bit and 64-bit C APIs are provided, but a C or Cocoa application emits a warning on exit. It appears one of the components in the driver attempts to access UI elements from a background thread. My suspicion is that the LabVIEW Run-Time Engine, in which the DAQmx Base C API runs, is doing that.
Links
[1] NI-DAQmx Base 14.0 for Mac
http://www.ni.com/download/ni-daqmx-base-14.0/5060/en/
I had this same problem, and spent an evening figuring out the problem.
Apparently, the NiDaq framework tries to send a message setHandler:withData: to the appdelegate. On yosemite, this handler no longer exists, causing the exception.
If you haven't implemented such message in your own app delegate, things go bad.
But you can simply implement a dummy handler by adding this to your application delegate class :
- (id)setHandler:(id)a withData:(id) b
{
return nil;
}
this way, the framework doesn't crash !!! I still have to test if the measured data is correct, but at least i'm running again !
My C# app uses a C++ WinRT component I've written to get a list of system fonts using Direct X.
This is based on this example:
http://msdn.microsoft.com/en-us/library/dd756582(v=VS.85).aspx
My app is published in the store, but my latest update failed to pass the store review process on point 3.10 complaining about my use of Direct 3D and how this might not run on ARM tablets. As far as I know I'm not using Direct 3D and the only Direct X feature I'm using is GetSystemFontCollection.
How can I make sure I don't fail this requirement and do I need to remove some rogue reference in my component to Direct3D?
Also, why am I failing this now, when it passed before?
Did you target all three platforms or choose any cpu in your release?
Does this page help:
http://msdn.microsoft.com/en-gb/library/windows/apps/hh994923.aspx
It looks like you may have inadvertently requested a higher level.
I submitted again and included a note to the tester explaining that my app didn't use any Direct 3D features, and I told them the exact DirectX function I did use.
I still failed, but the Direct3D reason was no longer one of the reasons.
Apparently my app is crashing, which was another failure reason the first time round, but I thought this must be related to the Direct3D problem. I can't reproduce the crash, but at least I now know that I can stop looking at my use of DirectX. This was a red herring.
iOS SDK is upgrading, and some new tech will appear, i.e, block is new tech.
So question is if "block" based implementation also can be distributed to lower target version or older iPhone ( 3G or first generation ) ?
how to cope with those issues ?
The usual way to deal with this sort of issue is to selectively enable features at runtime based on the current OS version. However, this can be very complicated to manage.
Query the current OS version at runtime
Use weak linking
Dynamically create the class
Call the new features only if the new class is present
For example:
Class optionalClass = NSClassFromString(#"NSArtificialIntelligence");
if (optionalClass) {
id optionalObj = [[optionalClass alloc] init];
// ...
}
The following documentation describes the process in detail:
Configuring a Project for SDK-Based Development
Using Weakly Linked Classes in iOS
You specifically mention blocks. This feature requires support from the compiler and Objective-C runtime, so it will not be available at all on older systems.
You must weak link to libSystem.B.dylib if you are using blocks for iOS4 or later. Because blocks are able to compile with the latest iOS SDK but iOS2,3.0 and 3.1 don't have blocks runtime.
iOS 4 app crashes at startup on iOS 3.1.3: Symbol not found: __NSConcreteStackBlock
(Besides, you can use blocks for iPhone 2.2+. Please take a look at plblocks.)
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.