Surprise! : Write Java Servlets in VB

All our thoughts and prayers, and also some considerably more concrete assistance, go out to the victims of the tsunami in Asia.  At a time like this we are reminded that we are all brothers and sisters. 

ServerTec says they have a a JSP/Servlet engine, ported to run on .NET and J#.  They say you can develop servlets in Visual Studio, using any .NET language.  They have examples for C#, VB, J# and C++.

This isn't interop per se, but is related to interop.  For me, interop is operational re-use of existing systems.  This framework would allow code re-use.  So they are both special cases of Re-use.  For existing JSP/Servlet web apps that today run on a JVM, you could convert them to J# and .NET, which then allows future extension of those apps via the .NET framework, including the built-in .NET web app model (ASP.NET).

Interesting:  Servlets require a bunch of Java classes which are not included in the Visual J# runtime.  As most of y'all know, the VJ# runtime is limited to Java 1.1.4 plus a few extensions for Swing.   There was some stuff that was added to the Java base class library for Java2, and then exploited by Java servlets, including JNDI, Java2 collections, and the XML libraries.   So without JNDI (etc) in the VJ# runtime, how can a servlet engine run on VJ# and .NET?    Answer:  Open source versions of the required libraries: .   How about that?   Currently there are .NET implementations of Java2 collections, JNDI, Apache Oro, Apache Regexp, Apache Xerces, and Apache Xalan. 

I think XML and XSLT support in .NET is ahead of the current Java support, and likewise for ASP.NET and the controls model as compared to JSP+Servlet, as well as the Java Regexp library from Apache and the System.Text.RegularExpressions stuff in .NET.   But if you already have code that relies on the Java interfaces, now you may be able to convert it to .NET without re-engineering the code.  This could save a ton of time.  Different sub-libraries have different licenses, some are Apache and some are GPL. 

Which brings me back to interop.  Suppose you have a library of Java code that employs JNDI to do service lookups, or Xerces to do XML manipulation. It could be totally independent of the web app - not used in a Servlet or JSP at all.    Suppose now you want to add a satellite subsystem to the existing system, and this new subsystem will be implemented in .NET.  The new system needs to take advantage of the same service repository, and the same set of XML documents.  Rather than re-engineering the lookup and XML parsing logic using interfaces defined in the .NET base class library, you could migrate it to  J# with the help of these support classes, and then get full operational re-use (== interop) between .NET and the existing assets. 

This opens up some new, interesting possibilities.

I'd like to hear from people who

  • have used the Servlets-on-.NET framework, either successfully or not.
  • have used the support classes, ditto

Did it work? What can you share with us about your experiences?


Comments (0)

Skip to main content