FWD » Core Development » Database

The scope of this issue is to take the implementation from prototype to a working solution which supports all of the UDFs we currently support under PL/Java. This will involve removing as many unnecessary classes from p2jpl.jar as is possible by unraveling dependencies that don't make sense in the target environment (e.g., TransactionManager, BlockManager, SecurityManager, etc.). The p2jpl.jar should compile fully into CIL and all UDFs should work.

The needs of the Java UDFs we use are not complicated or esoteric (e.g., math, string manipulation), so they should be well supported by IKVM. By removing the more complicated classes (which are not needed but are loaded by bogus dependencies), we should have good level of confidence in the resulting CIL. A nice side effect is that the p2jpl.jar will be simplified for PL/Java, too.

Using the attached om_upd20140314a.zip, almost all methods and functions have full support for MSSQL (the fully implemented Operators.cs and Functions.cs will defer the calls to our Operators.java and Functions.java respectively). However, except for some late additions (like plusMillis methods), I believe that these operators are used only in some specific configuration (I remember I played around with it, but at this moment I don't remember the exact location of the switch).

The p2jpl.jar is a little too oversized at this moment. I should investigate what should be removed and, more than that, some code could be rewritten because there are some restrictions, don't know if because of CLR or IKVM, but I was forced to install the p2j2clr as unsafe because of some constraints like this one:

Msg 6522, Level 16, State 2, Line 1
A .NET Framework error occurred during execution of user-defined routine or aggregate "toDate_t":
System.Security.HostProtectionException: Attempted to perform an operation that was forbidden by the CLR host.

The protected resources (only available with full trust) were: All
The demanded resources were: MayLeakOnAbort

System.Security.HostProtectionException:
   at System.RuntimeMethodHandle.PerformSecurityCheck(Object obj, RuntimeMethodHandleInternal method, RuntimeType parent, UInt32 invocationFlags)
   at System.RuntimeMethodHandle.PerformSecurityCheck(Object obj, IRuntimeMethodInfo method, RuntimeType parent, UInt32 invocationFlags)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
   at IKVM.NativeCode.java.util.TimeZone.GetCurrentTimeZoneID()
   at IKVM.NativeCode.java.util.TimeZone.getSystemTimeZoneID(String javaHome, String country)
   at java.util.TimeZone.setDefaultZone()
   at java.util.TimeZone.getDefaultRef()
   at java.util.Date..ctor(Int32 year, Int32 month, Int32 date, Int32 hrs, Int32 min, Int32 sec)
   at java.sql.Timestamp..ctor(Int32 year, Int32 month, Int32 date, Int32 hour, Int32 minute, Int32 second, Int32 nano)
   at Common.toTimestamp(DateTime t)
   at Functions.toDate_t(DateTime dt)

It's not clear to me where and why this leak may occur but I am thinking that there could be other issues like this out there waiting to be discovered. What's strange is that the stack points the a simple getter (GetCurrentTimeZoneID()) that should not normally allocate resources that could eventually leak.
Also there are lots of warnings in the ikvmc output log that annoy me.

Firstly, just as an update: with IKVM.NET 8.1, the warning are a little changed, the IKVMC0105 & IKVMC0111 are gone, only IKVMC0100 are logged. However, the problem remains the same: queries will fail if one of the class need to be accessed (I believe the event is logged by SQL Server).
On the other side, we normally don't access those classes at runtime. The Operators and Functions only do basic data manipulation. If the execution path reached the listed classes, I think it's a bug and will have to be corrected when found. Let's close this issue now.

I attached the listing from one of my latest conversion, with IKVM.NET 8.1, just for reference.

Please open a separate issue to clean up the dependencies, so we at some point eliminate this noise from the build.

I agree that those classes should never be called by the basic data manipulation done in Operators and Functions. Closing this issue accordingly.