Yesterday I read two excellent posts about C# 3.0 automatic properties feature: ScottGu’s «New C# “Orcas” Language Features: Automatic Properties, Object Initializers, and Collection Initializers» and Bart De Smet’s «C# 3.0 Automatic Properties explained».

It was a pleasure to see that my old «A programming language pattern idea» hit straight to the point.

By the way, this “Orcas” feature is still missing the “container” concept, enabling an access to the auto-generated field from the constructor. Another missing point is a read-only automatic properties.

Mainsoft launched Developer Zone site, feauturing Visual MainWin for J2EE — a Visual Studio .NET plug-in, which enables you use C# or VB.NET to develop, debug and deploy Web applications and Web services that run on Microsoft Windows, Linux and any Java-enabled platform. Grasshopper supports single-source code development, so you can develop an ASP.NET application that will compile and run on multiple platforms.

In addition, this new technology provides you with ability to consume pure Java software components, such as EJB’s, JDBC drivers etc., so you can call you Java components directly from C# code of your application.
This is definitely a new generation of cross-platform interoperability technology.

Grasshopper, the Developer edition of Visual MainVin for J2EE, is available for download from the Mainsoft Developer Zone site. Grasshopper bundles the Apache Tomcat application server and PostgreSQL database, so you get a complete cross-platform Visual Studio development environment for any platform running Apache Tomcat.

Grasshopper presents the following key feature points :

  • Visual Studio integration: it completely suits into VisualStudio environment, so you continue enjoying the full range of the Visual Studio .NET capabilities. Even more, it extends them into Java components, so advanced features like IntelliSense, code navigation and error detection are available when accessing Java components. Additional feature is a cross-platform debugger, which provides you and ability to debug both of your C# and Java code within the same application. In addition, Grasshopper help system integrates into MSDN collection of books and provides support for search, index, content, and dynamic help. Futhermore, Grasshopper provides a new MSDN book that describes the Java runtime classes and interfaces.
  • Access to external Java components: you can access external Java components with no depend of the Java environment they were initially developed. You can add JARs as a references to your C# or VB.NET project, accessing them as any other software components available in your application.
  • Open source .NET framework: Grasshopper provides the .NET Framework class library , implementing ASP.NET, ADO.NET, XML, Web services and .NET server-side runtime services. This .NET Framework sources are shared with Mono, the open source .NET implementation for Linux. The sources are packaged as Visual Studio projects, so you can download the source code, modify it, compile, debug and test the code, all from Visual Studio.

References :

When it was announced that at the Ides of March the Senate is to meet in the Curia Pompeii, everybody preferred this time and place.

“Lives of the Twelve Caesars” by C. Suetonius Tranquillus about Julius Caesar assassination and death.

Do you think Brutus and Cassius were able to do better if they have all of today technology on their side? Don’t be quick with your answer.
Imagine you have two applications: one built in Java and other running in .Net environment. You want both application to use common database, you want to store dates, but you don’t want to store date objects in the database (for example, you use an ad-hoc database solution that just can not store dates).
The conversion should be done in two phases — one is quite simple and the other is tricky a bit.
First of all, the Java and .Net dates have a different starting point: zero milliseconds in Java corresponds to January 1, 1970, 00:00:00 GMT (aka “the epoch”). In .Net zero milliseconds* corresponds to 12:00 A.M., January 1, 0001 GMT.
So the basic is to bridge over the reference points gap with adding (or substracting) the corresponding number of milliseconds such that zero milliseconds in .Net is mapped to -62135769600000L milliseconds in Java. This number of milliseconds corresponds to GMT zone, so do not forget to include your time zone offset into the calculations.
The second part is more complex. Default .Net calendar is Gregorian calendar and all of .Net date calculations rely on this calendar rules (even for the dates that are in the past relative to Gregorian calendar invention). From the other side, Java default calendar is also Gregorian calendar, but actually java.util.GregorianCalendar implements Julian calendar for dates before October 4, 1582.
Thus, the year 1582 in Java Gregorian calendar has 10 days less that the same year in .Net Gregorian calendar and, in addition, each forth year before 1582 (excluding the century years which are not divisible by 400) in Java has one day more that the same year in .Net (because of leap year rule difference). This requires you to add or substract appropriate number of milliseconds for each date before 1582**.

* Actually .Net dates operate with ticks (100-nanosecons units), but to simplify our discussion, I always use milliseconds value, since the converting from ticks to milliseconds and vise versa is trivial.
** I still don’t know what are the actual dates in each of this years that produces the difference, so you are more than welcome to check this.

References :

Special thanks to :

  • Konstantin Triger for the major help in research of date conversions issue.