String.format in Java has weird rounding by default

I was participating in one of our Android projects, and while testing I discovered, that our program acted weird — app displayed one value, but acted like the value was different. The value was 1.45, and our Java Android app displayed 1.4 instead of 1.5.

The source looked something like:
double d = 1.45;
String val = String.format(Locale.US, "%.1f", d) + "%";

I am still a beginner in Java, and at first I believed, that String.format rounds down by default. This was till I saw, that value 1.55 is rounded up by default.

Digging into Java documentation I found, that String.format uses RoundingMode HALF_EVEN by default:

Rounding mode to round towards the “nearest neighbor” unless both neighbors are equidistant, in which case, round towards the even neighbor. Behaves as for RoundingMode.HALF_UP if the digit to the left of the discarded fraction is odd; behaves as for RoundingMode.HALF_DOWN if it’s even. Note that this is the rounding mode that statistically minimizes cumulative error when applied repeatedly over a sequence of calculations. It is sometimes known as “Banker’s rounding,” and is chiefly used in the USA. This rounding mode is analogous to the rounding policy used for float and double arithmetic in Java.

http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html

Of course other beginners are also discovering this Java Rounding.

Unfortunately Android does not support setRoundingMode, so currently using the following workaround:
double d = (double)Math.round(((double)percents) * 10f) / 10f;
String val = String.format(Locale.US, "%.1f", d) + "%";

PowerShell in Unicode, Windows 8 RP and Windows Server 2012 RC

PowerShell 3.0 under Windows 8

I was testing our software with latest version of Microsoft Windows — Windows 8 Release Preview and Windows Server 2012 Release Candidate (Windows Server 2012 RC Datacenter).

There was some changed behavior in very specific cases for some rarely used Windows API. I also found some race conditions, that showed up in Windows 8, but all this was trivial to fix.

The strange problem appeared in capturing console output from PowerShell in UTF-8 or Unicode (UTF-16). We are using CreateProcess Windows API function with redirected pipes. And strangely all output is converted from Unicode to ASCII. We are using OutputEncoding UTF-8:
[Console]::OutputEncoding = [Text.Encoding]::Utf8See example here: Unicode in PowerShell – example #2.

Windows 8 is using a new version of PowerShell — v3, so I tried to use compatibility command line switch -version 2.0, and this solved the problem.

Most probably this is a bug in Microsoft PowerShell — PowerShell somewhere is converting all output to ASCII. The question remains, will this be fixed in RTM or we will be unable to use Unicode output in PowerShell v3.

P.S. Currently I am unable to test this under Windows 8 RTM or Windows Server 2012 RTM, because for MSDN subscribers, Windows 8 and 2012 will be available on August 15, 2012.

Visual Studio Form Editor: To prevent possible data loss before loading the designer, the following errors must be resolved

This is not the first time. I have seen this error message in the past (probably multiple times), and every time I look to this error and I do not understand, why it appeared and how to fix it. I read the text, projects not referenced, projects have been built… wait… yes, projects must be built, otherwise Inherited Forms can not be shown. Building the projects with base classes solved the problem.

Visual Studio Form Editor: To prevent possible data loss before loading the designer, the following errors must be resolved: The designer could not be shown for this file because none of the classes within it can be designed. The designer inspected the following clasess in the file: MyClass.cs — The base class MyBaseClass.cs could not be loaded. Ensure the assembly has been referenced and that all projects have been built.