I had problems in some flow with unicode chars in some of my flows. So i fixed the flow and added a test.
assertEquals("Björk", buyingOption.getArtist());
the buyingOption.getArtist() will return the same name that is on ,here is a snippet :
but junit will fail with the message :
junit.framework.ComparisonFailure: null
Expected :Bj?rk
Actual :Bj?rk
at com.delver.update.system.AECSystemTest.basicOperationtsTest1(AECSystemTest.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
This is probably due to the default encoding used for your Java source files. The ö in the string literal in the JUnit source code is probably being converted to something else when the test is compiled.
To avoid this, use Unicode escapes (\uxxxx) in the string literals in your JUnit source code:
assertEquals("Bj\u00F6rk", buyingOption.getArtist());
I agree with Grodriguez but would like to suggest you to change your default encoding to UTF-8 and forget about this kind of problems.
How to do this? It depends on your IDE. For example in Eclipse go to Window/Preferences then type "encoding", choose Workspace and change encoding to UTf-8
I found the solution was to change the default encoding before running mvn test
My fix to this issue was to set the ENV var JAVA_TOOL_OPTIONS before running
export JAVA_TOOL_OPTIONS="$JAVA_TOOL_OPTIONS -Dfile.encoding=UTF8"
mvn test
Related
We have a Java application (OpenJDK 1.8) - a service generating some payload using the Freemaker templates (mvn version 2.3.31). The content translations are handled using the resource bundles (.property files with translations, e.g. template.properties, template_fi.properties, template_bg.properties, ..). The properties files have content of the utf-8 encoding and all works good.
When migrating to Java 11 (Zulu OpenJDK 11), we started to have an issue with translations, which were not "latin" - having characters not in the ISO-8859-1 charset. All characters out of the charset encoding were changed to ?. (yet the resource files were utf-8 encoded, changing the content using native2ascii did not help)
After some time / experiments we solved the encoding issue using the system property:
-D java.util.PropertyResourceBundle.encoding=ISO-8859-1
I'm looking for an explanation - WHY? I find the property value counterintuitive and I'd like to understand the process.
According to the documentation I understand the ResourceBundle suppose to read the property in using the ISO-8859-1 and throw an exception when encountering an invalid character. The system properly mentioned above should enable having the property file encoded in UTF. Yet the workable solution was explicitly setting the ISO-8859-1 encoding
And indeed testing pure Java implementation, the proper output is achieved using the UTF-8 encoding
System.setProperty("java.util.PropertyResourceBundle.encoding","UTF-8");
// "ISO-8859-1" <- not working
// System.setProperty("java.util.PropertyResourceBundle.encoding","ISO-8859-1");
Locale locale = Locale.forLanguageTag("bg-BG");
ResourceBundle testBundle = ResourceBundle.getBundle("test", locale);
System.out.println(testBundle.getString("name"));
// return encoded, so the terminal doeesn't break the non-latin characters
System.out.println(
Base64.getEncoder()
.encodeToString(testBundle.getString("name").getBytes("UTF-8")));
I assume that the Fremaker library somehow makes some encoding changes internally, yet not sure what/why, the Freemaker internal localized string is a simple bundle
Sorry if this question has already been answered some where, I have not had any luck turning up a solution. This is my first SO post, if information is missing/unclear, or the formatting sucks, let me know, I will update the post.
I am using TestNG version 6.13.1 (also tested with 7.0.0-beta1). I am running this command (not the full command, the class path is massive, and there are multiple -D options)
java -cp <classpath stuff...> -DappiumPort=30000 org.testng.TestNG -usedefaultlisteners false /Users/.../adbservice/test-results/3567/test_config/Test_Suite_testT13googleMaps.xml
expecting that testNG will recognize the first argument as a switch, and turn the default listeners off. This is based on reading Turning off test-output in TestNG and http://testng.org/doc/documentation-main.html#testng-xml, and other less relevant documents.
What actually happens is testNG appears to treat all the arguments as if they are file paths, and I get a very helpful error message
ProcessResults(exitCode=0, output=java.io.FileNotFoundException: /Users/.../adbservice/-usedefaultlisteners false testng.xml (No such file or directory)
at java.base/java.io.FileInputStream.open0(Native Method)
at java.base/java.io.FileInputStream.open(FileInputStream.java:196)
at java.base/java.io.FileInputStream.<init>(FileInputStream.java:139)
at org.testng.xml.Parser.parse(Parser.java:148)
at org.testng.xml.Parser.parse(Parser.java:233)
at org.testng.TestNG.parseSuite(TestNG.java:290)
at org.testng.TestNG.initializeSuitesAndJarFile(TestNG.java:334)
at org.testng.TestNG.initializeEverything(TestNG.java:974)
at org.testng.TestNG.run(TestNG.java:988)
at org.testng.TestNG.privateMain(TestNG.java:1330)
at org.testng.TestNG.main(TestNG.java:1299)
The command itself is issued from Java, using a wrapper around a ProcessExecutor. The code looks like
new ProcessExecutor()
.command(cmd)
.readOutput(true)
.timeout(waitForTimeMs, TimeUnit.MILLISECONDS)
.execute();
I can get the same error if I capture the command input and paste it into the shell, so it seems that it is not a problem with the java code itself, but I figured I would include that information for completeness.
My question is, how can I make this call to testNG work using the command line arguments? There seem to be few alternatives because I have packaged tests which are executed in a shell process.
Edit
Since this is such a common case, I am convinced there is something wrong on my side. I tested that theory out by creating a really simple java project with a smoke test, and then ran it with
java -cp .:testng-6.13.1.jar:jcommander-1.72.jar:build/libs/test-1.0-SNAPSHOT.jar org.testng.TestNG -usedefaultlisteners false testng.xml
which worked exactly as described in the documentation. Therefore I think there is something going on with the input to java and how it is being processed that is causing the error with testNG.
Edit 2
Did some further investigation on my side, eventually I tried the original generated java command with the parameters ( -usedefaultlisteners false) on the command line, and lo and behold it worked, or at least, it did some stuff before bombing out, instead of complaining about the parameters being invalid file paths, which was my original result when running on the command line. Maybe I had the wrong directory or some such the first time, but this suggests that it is a problem with handling the command with this ProcessExecutor.
Edit 3
Paydirt. It turns out the ProcessExecutor library does not handle command line input with spaces as one might expect, so for example,
Lists.newArrayList(
"java", "-cp", ".:", "org.testng.TestNG", "-enabledefaultlisteners false", "testng.xml"
)
will error, but
Lists.newArrayList(
"java", "-cp", ".:", "org.testng.TestNG", "-enabledefaultlisteners", "false", "testng.xml"
)
works. It seems like that should be documented in the ProcessExecutor library docs.
I am trying to copy files to an nfsv3 mounted volume during a spark job. Some of the files contain umlauts. For example:
Malformed input or input contains unmappable characters:
/import/nfsmountpoint/Währungszählmaske.pdf
The error occurs in the following line of scala code:
//targetPath is String and looks ok
val target = Paths.get(targetPath)
The file encoding is shown as ANSI X3.4-1968 although the linux locale on the spark machines is set to en_US.UTF-8.
I already tried to change the locale for the spark job itself using the following arguments:
--conf 'spark.executor.extraJavaOptions=-Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8'
--conf 'spark.driver.extraJavaOptions=-Dsun.jnu.encoding=UTF8 -Dfile.encoding=UTF8'
This solves the error, but the filename on the target volume looks like this:
/import/nfsmountpoint/W?hrungsz?hlmaske.pdf
The volume mountpoint is:
hnnetapp666.mydomain:/vol/nfsmountpoint on /import/nfsmountpoint type nfs (rw,nosuid,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,noacl,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=4.14.1.36,mountvers=3,mountport=4046,mountproto=udp,local_lock=none,addr=4.14.1.36)
Is there a possible way to fix this?
Solved this by setting the encoding settings like mentioned above and manually converting from and to UTF-8:
Solution for encoding conversion
Just using NFSv4 with UTF-8 support would have been an easier solution.
In a .bndrun file I have:
-runvm: -Djava.util.logging.config.file=${workspace}/com.myproject/conf/logging.properties
When I run the run descriptor, the console shows:
Error: Could not find or load main class and
That's because of the following generated command line:
"C:\Program Files\Java\jre7\bin\javaw.exe" -Djava.util.logging.config.file=C:\Documents and Settings\Dan\eclipse-workspaces\workspace/com.myproject/conf/logging.properties
The space is obviously upsetting it. Normally quote marks are the solution to this. But if I add them, they seem to be stripped out:
-runvm: -Djava.util.logging.config.file="${workspace}/com.myproject/conf/logging.properties"
This is likely a bug in bnd, might be because the backslashes of windows. In this case, since you're relative to the workspace, you might want to address the properties relative?
Can you file a bug?
You can try to use a macro to get rid of the backslashes, till the "bug" is fixed.
# replace backslash with slash
workspace.unix = ${replace;${workspace};(\\\\);/}
I'm unable to view correctly my UTF8 string in AndroidSutdio debug or android layout.
below is my code :
String test1 = "hélǐ";
Results is test1 = hél�
test1 Looks similar to reading my UTF8 string with ANSI encoding in notepad++. However if I harcode it into the XML layout directly (instead of using Button.setHint() method) I can see hélǐ correctly.
UPDATE 1 : thanks Jon Skeet for pointing out test1.lenght() = 6 and not 4 thus is not a display issue.
UPDATE 2 : thanks Joop Eggen for pointing out that "h\u00e9l\u012d" return the correct answer
UPDATE 3 : I have copy paste my code to an equivalent android project on eclipse and it works fine. thus it must be AndroidStudio related issue.
UPDATE 4 : added a variable JAVA_TOOL_OPTIONS = -Dfile.encoding=UTF-8 to force javac using that command but with no effect to the result.
UPDATE 5 : I installed AndroidStudio on ubuntu and copy paste my code and it run fine as well there. But how to fix it on AndroidStudio Windows? (as unfortunately I need to use windows)
Anyone ever faced that issue before? how to fix without using \u code
Thanks
note:
I'm using AndroidStudio
in my Javac and Android DX complier I added -encoding utf8
in my AndroidStudio all files encodings are set to utf8 (and i can see utf8 in bottom right)
Charset.defaultCharset() return utf8
InputStreamReader.getEncoding() return utf8
all my xml layout have an utf8 flag on the top
Notepad++ read correctly my copy/paste "hélǐ" with utf8 encoding.
Try h\u00e9l\u012d too. This removes the factor of java source encoding.
Try writing the text to file:
new OutputStreamWriter(new FileOutputStream(file), "UTF-8")
Then the cause should become clearer.
As editor and compiler must use the same encoding, you seem to have done all thing possible for the rest. Especially checking with NotePad++ (- JEdit is possible too). One small point is IDE background compiling and and final compiling.
Also running is a console: the console could be erroneously use the operating system encoding.
All those new String(...) are superflous and erroneously. Do not use that here, as indeed one error could cancel an error between mismatched encoding of editor and compiler.
(In ISO-8859-1 ĭ (i-breve) is not available - hence test3.)
My case was exactly the same as Simon (I am using Android Studio for Mac 0.2.2)
I solved the problem by editing the build.gradle file under the /src folder, adding these lines:
tasks.withType(Compile) {
options.encoding = 'UTF-8'
}
It worked for me. Hope it helps somebody with the same problem.
Fixed in latest version of AndroidStudio