In roboelectric when you write your test class you have declare the #RunWith annotation of which there is RobolectricGradleTestRunner and RobolectricTestRunner.class. What is the difference and which one should we use ? Why is there 2 in the first place. If I use RobolectricTestRunner then it does not work for me it says some weird error like :
"java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity."
However this seems to go away if I use RobolectricGradleTestRunner.
RobolectricTestRunner was first and is for maven based projects.
RobolectricGradleTestRunner was for gradle based projects because some paths have changed.
Since robolectric 3.1.1 this is not more necessary and is now deprecated.
For more details see also http://robolectric.org/getting-started/
Related
As the doc stands, one can define -p:AndroidVersionCode=101 as one of MSBuild arguments.
However, the Android Version Code is ignored and the final APK file always contains only the value from AndroidManifest.xml even though the <GenerateApplicationManifest>true</GenerateApplicationManifest> is defined in the *Droid.csproj file (in fact, I've set it also in netstandard csfile).
How to define Version Code for MSBuild?
Here is the complete MSBuild command which I use:
msbuild -t:Clean -t:PackageForAndroid -p:AndroidPackageFormat=apk -p:ApplicationVersion="1.0" -p:AndroidVersionCode=101 -p:ApplicationId="cz.sebastian.myapp" -p:OutputPath="C:\Packages\" -p:Configuration=Release .\MyApp.Droid.csproj
After several practical experiments I've found the following:
Docs are wrong. The property AndroidVersionCode doesn't reflect Android's Version Code, in fact, I didn't find what it's really used for. Version Code can be modified via the ApplicationVersion property, only.
To really change the Version Code one must remove the android:versionCode from AndroidManifest.xml.
To sum up: Remove android:versionCode from Android manifest and use ApplicationVersion with an integer value.
MSBuild version 17.4.0+18d5aef85 for .NET Framework
we upgraded from HV 4.x to HV 5.4.2 and now when we have interface like following
#NotNull
List<AccountInfo> getMultiClientAccountBalances(#NotNull ClientContext clientContext, #NotNull Optional<AccountFilter> accountFilter);
I'm getting error:
javax.validation.UnexpectedTypeException: HV000186: The constraint of type 'javax.validation.constraints.NotNull' defined on 'getMultiClientAccountBalances.arg1' has multiple matching constraint validators which is due to an additional value handler of type 'org.hibernate.validator.internal.engine.valuehandling.OptionalValueUnwrapper'. It is unclear which value needs validating. Clarify configuration via #UnwrapValidatedValue.
I know it can be fixed by adding #UnwrapValidatedValue to the field, but this must be added to every method what is a lot of work for me. Is there any simpler solution (besides upgrade to HV6.x)
Unfortunately I don't see how we could change this behavior in 5.4 without breaking other use cases.
And there is no easy way to disable the optional value handler as it's added unconditionally.
So I would say you have two solutions:
a search and replace of all #Constraint Optional to add the UnwrapValidatedValue option
or move to HV 6, where we totally reworked this feature and where, I think, it should work as you expect it. I know you didn't want this answer but it is what it is...
The issue with 1. is that we removed this annotation from HV (it was experimental) in favor of a standard feature included in Bean Validation so you will have to remove it when moving to 6.
I don't know your exact environment but HV 6 is highly compatible with the previous versions so it might work very well. Just be careful about the dependencies as we changed the groupId of the artifact from org.hibernate to org.hibernate.validator. Also be aware that you need to update the validation-api from 1.1 to 2.0.
6 is already very stable and if you have any issues with it, we will fix them right away.
We use this type of Reflection only in our test framework and not in production. We want add some jar files to the app classloader depending of our test code. Is there any workaround for it? How can we get access to not exported classes?
java.lang.reflect.InaccessibleObjectException: Unable to make member of class jdk.internal.loader.ClassLoaders$AppClassLoader accessible: module java.base does not export jdk.internal.loader to unnamed module #9f73a2
at jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:174)
at java.lang.reflect.Method.checkCanSetAccessible(Method.java:191)
at java.lang.reflect.Method.setAccessible(Method.java:185)
Accessing module-internal classes can not be done from code. This is on purpose. But there is a workaround from the command line - a non-standardized option on java that does what you want:
--add-exports <module>/<package>=<target-module>(,<target-module>)*
updates <module> to export <package> to <target-module>,
regardless of module declaration.
<target-module> can be ALL-UNNAMED to export to all
unnamed modules.
Note
Java 9 is a moving target and the exact syntax has been changed a couple of times - as was this answer. This means (a) some of the comments below may seem outdated and (b) the flag might not work exactly like that. Please leave a comment and it will get fixed.
I want to load dynamically XML meta-data files that are not in the classpath (the XML meta-data files will be generated after launching my app).
I thought I could call the method
MetaDataManager.registerFile(java.lang.String fileURLString, FileMetaData filemd, ClassLoaderResolver clr)
Then, I tried the API enhancement, so I added the following lines:
JDOEnhancer enhancer = JDOHelper.getEnhancer();
enhancer.setVerbose(true);
enhancer.addClasses(ClassToPersist.class.getName()).enhance();
getClass().getClassLoader().loadClass(ClassToPersist.class.getName());
The following jars are in the classpath: datanucleus-api-jdo.jar, datanucleus-connectionpool.jar, datanucleus-core.jar datanucleus-rdbms.jar, jdo-api.jar, asm.jar.
But when I launch my app, I get this exception:
Caused by: mypackage.MyException:
org.datanucleus.api.jdo.exceptions.ClassNotPersistenceCapableException: The class "mypackage.ClassToPersist" is not persistable. This means that it either hasnt been enhanced, or that the enhanced version of the file is not in the CLASSPATH (or is hidden by an unenhanced version), or the Meta-Data/annotations for the class are not found.
Do you please have any idea how to fix this ?
PS: I also noticed that the method enhance returns 0 which indicates that the class has not been enhanced (we could exclude the other options)
Thanks
I think I found an easy way to fix this.
At runtime, I created a jar that contains the updated metadata file as META-INF/package.jdo. Then I added this jar to the classpath as described here
Using this hacks, I didn't need to re-enhace my class since it is enhanced after compilation.
(But for information, I had to call JDOEnhancer.addFiles() to enhance my class.)
So your call to loadClass has loaded the unenhanced class (since it would have been loaded in order to perform the enhancement presumably), and you didn't follow the tutorial that is provided at http://www.datanucleus.org/documentation/development/dynamic_class_metadata_enhance_runtime.html
I had problem with my application with Canvas generation ( I'm using JavaFx ). Setting this option helped:
-Dprism.order=j2d
The thing that is problem to is that I cann't find any documentation for prism ( Dprism ). Second problem is that I would like to set up this option via config file.
Properties props = System.getProperties();
props.setProperty("com.sun.prism.order", "j2d");
Code above dosen't work for me.
These were the properties used by JavaFX 20 months ago (from the adamish blog):
com.sun.scenario.animation.adaptivepulse
com.sun.scenario.animation.AnimationMBean.enabled
com.sun.scenario.animation.nogaps
decora.purgatory
glass.platform
javafx.animation.framerate
javafx.animation.fullspeed
javafx.animation.pulse
javafx.debug
javafx.embed.isEventThread
javafx.sg.warn
javafx.toolkit
javafx.verbose
javafx.version
nativewindow.ws.name
prism.debug
prism.device
prism.dirtyregioncount
prism.disableBadDriverWarning
prism.forcerepaint
prism.multisample
prism.noFallback
prism.order
prism.printallocs
prism.reftype
prism.showcull
prism.showdirty
prism.shutdownHook
prism.tess
prism.tessaa
prism.trace
prism.verbose
quantum.debug
quantum.pulsedebug
quantum.verbose
I do not know what most of the above properties are, when they are set, what values they may have, how they are used or what they do.
The JavaFX Project Lead (Richard Bair), notes:
Just a word of caution, if we haven't documented the command line
switches, they're fair game for removal / modification in subsequent
releases :-)
There is an issue tracker request to get some of the properties officially documented and supported:
JDK-8092282 "Document officially supported system properties and command line switches"
The request is currently scheduled for implementation in Java 9. Access to the issue tracker requires a login, but anybody can signup and comment on the issue or vote for it.
I was having the same problem. The issues is that if your main class extends Application, there is a launcher class that kicks in before your main method and reads the prism properties before you set them.
If you use a class that doesn't extend Application as the main class and from this one you set the system properties and then call the main method of class extending Application, the properties go through