Hands On: Developers Comment on Visual J# .NET 1.0

Hear from Java developers with hands-on insights on using Visual J#.NET 1.0 for building web services.

Tags: Java, Developers, Support, JDK, Web Services, APIs, Microsoft,

With Microsoft's release of Visual J# .NET 1.0 earlier this month, IDN has begun to hear from developers and consultants who have some hands-on insights into this latest tool aimed at bridging the Java and .NET worlds.

Robert Interrante is a senior Java developer with Ajilon Consulting, a professional services firm based in Towson, Maryland with regional offices throughout the country. He has been using and watching the evolution of Visual J# .NET since last fall.

Overall, Interrante finds merit in the Visual J#. NET tool, if only for the reason that IT managers can get a flavor for what kinds of web services they might be able to build -- without spending a lot of time and money for retraining or technology. "I can use J# and it feels exactly like Java for writing a utility class and in other tasks," he told IDN.

What this means, Interrante said, "is if I have a development team made up of a mix of Microsoft and Java developers, I would not have to make any of my Java team learn anything specific about .NET, and many of the Java classes would be able to build and work just like they do in native Java. In my test development, I could write multiple J# components using what to me looked like 'real Java' and the .NET team could include them in their libraries."

Chris Maeda, CTO at Kana, an eCRM solutions firm based in Menlo Park, CA, agreed with Interrante on that point. "The main feature is that J# is the Java language. Before [Visual] J#, a Java developer approaching .NET would have to learn both a new language (e.g. C#) and a new set of runtime libraries [in] the .NET Framework. Now Java developers only need to learn the runtime libraries," Maeda said.

Most Notable Feature - JDK 1.2 Support

When asked to name the most notable feature in the latest Visual J#.NET release, both developers cited Visual J#'s support for JDKs. In earlier beta versions, Visual J#'s implementations of Java stopped with JDK 1.1.4, which meant no support for the Java Native Interface (JNI), RMI event handling and other key features. But the Visual J# 1.0 full release addresses some developer concerns by adding some JDK 1.2 support, Maeda said.

"The main changes that we asked for after working with the betas was better support for Java platform libraries. J# comes with support for JDK 1.1.4 runtime libraries, but lots of Java code uses APIs from later versions
of the JDK. Microsoft added support for some of the JDK 1.2 APIs (especially the new Java Collections APIs) due to overwhelming demand," Maeda told IDN.

The added support for some JDK 1.2 APIs begs the question of whether Microsoft will provide full JDK 1.2 support in Visual J# .NET to allow even easier migration for Java to .NET, as well as other benefits. Meada's answer was encouraging. He told IDN, "Microsoft is also considering adding support for other parts of the JDK 1.2 APIs which would make it easier to migrate Java code to .NET or to maintain a single Java code base that compiles for both .NET and J2EE."

Interrante was also intrigued by a Visual J# .NET feature that provided him with what he called "a slick IDE component table" that developers can include to a web page. Writing a simple script to a web page could provide users with a component table that can display a limited subset of results, say 25 out of 10,000. "To do that in J2EE would require a lot of custom work or expensive third party component libraries with an IDE," he added.

Bang from Visual J# .NET

So, how would these developers suggest Java programming teams get the most use from Visual J# .NET?

Interrante suggested Visual J# is a good way to get a developer's feet wet, without a company having to make a big investment in time, training or money. "For companies looking to test the waters for web services, they can see what kind of benefits they'd get from .NET without requiring Java programmers to learn a new language. And, where time and budget are both a concern, I can see a lot of value in using Visual J# with the .NET." However, Interrante adds, that should Java developers like what they see, "they should really think about jumping directly to C# because there is just so much more that that language can do."

Maeda said early Visual J# users should focus on projects that merge web and enterprise applications because ".NET has a rich set of APIs for building scalable web-architected enterprise apps."

Lowering the Bar

"The goal of Visual J#.NET is to lower the bar for adoption of .NET and web services for the Java developer," said Tony Goodhew, a Microsoft product manager in the .NET developer division.

"The thinking goes; 'I'm already in Java, why should I learn something else?'" Goodhew emphasizes that Visual J# is not a full 100 percent Java implementation in so far as it will not support JVMs, and does not acknowledge work with elements of the Java platform, including servlets, JSPs or EJBs. In their place, Visual J#.NET provides such services with ADO.NET.

To understand Microsoft's Visual J# implementation of Java, it is important for Java developers to understand that Microsoft makes a distinction between Java-based business rules (specified in language, syntax, etc.) and the Java platform implementation (which includes plumbing and add-ons to help with code execution, such as servlets, JSPs, EJBs, etc.).

"We're not doing the [Java] platform," Goodhew said. "But in .NET [Framework], the approach is that we provide J# programs with the XML and web services automatically, without the need to write add-ons or build extra code."

For other good sources of "First Looks" information for Visual J# (dating from its beta release last fall), you can also go to an FTP tutorial. Also available is a collection of articles and Quick Start tips from Got Dot Net.