Re: Microsoft Losing Interest in C#?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Mike Schilling (mscottschilling_at_hotmail.com)
Date: 09/23/04 

Date: Thu, 23 Sep 2004 14:53:00 -0700

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:%23WKUb9aoEHA.3728@TK2MSFTNGP09.phx.gbl...
>
> "Mike Schilling" <mscottschilling@hotmail.com> wrote in message
> news:ubm4wwaoEHA.1664@tk2msftngp13.phx.gbl...
>>
>> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
>> message news:eBBRlYaoEHA.3460@tk2msftngp13.phx.gbl...
>>>> I disagree. The translator knows enough to convert
>>>> Java.Util.Random.nextBytes(byte[]) to System.Random.NextBytes(byte[]);
>>>> it should also know the semantics of the call, i.e. that the call
>>>> changes the byte array. Even without that detailed knowledge, the
>>>> default behavior should be something like:
>>>>
>>>> byte tempArr = new byte[barr.Length];
>>>> CopyToByteArray(barr, tempArr);
>>>> System.Random.NextBytes(tempArr);
>>>> CopyFromByteArray(tempArr, barr);
>>>>
>>>> At any rate, the fact that JLCA silently produces errors like this is
>>>> reason enough for me not to use it.
>>>
>>> While I can accept that is correct in this circumstance, I would find it
>>> troubling in the general case for this behavior. Neither choice is going
>>> to be correct all of the time. In alot of cases this behavior would be
>>> quite useless, and potentially costly with regards to performance
>>> (imagine a call to a socket, writer, or stream with a large buffer,
>>> copying it twice would be ghastly and buggy, IMHO. Worse yet, compound
>>> that over 40k lines. What good is code which has a tripled memory copy
>>> rate).
>>
>> If the translator knows how to map a Java SDK call to a .NET framework
>> call, part of that mapping should be knowing which direction(s) to copy
>> the array in. In this case, it needed to be copied out but not in, and
>> JLCA generated the precise opposite. Sorry, but it's a low-quality
>> product.
>
> I'm not arguing its quality, Idon't really care, I just think its overly
> arrogant to assume that any application can know every API's purpose and
> make decisions based on that, especially those which coudl be in, out, or
> in\out depending on other parameter values. This case *could* have, I
> suppose, but I doubt the entire SDK is that clean cut. Your general case
> scenario is just bad and wrong-minded, IMHO.

Gee, and we were getting along so well. :-)

Actually, it wouldn't be that hard. There's a finite list of API calls it
tries to convert, and for each of them, determining whether the inputs are
modified or not is just a question of reading the documentation. JLCA
already has API mappings, or it couldn't have gotten that far. Annotating
them with some simple semantic information doesn;t add much more work. And
it's a perfect opportunity to use unit tests to verify the behavior: write
tests in Java, translate them, and ensure that both versions act
identically. (More difficult with a random number generator than with most
calls, I admit.)

Actually, copying byte arays is a bad idea. In the array, the byte is
simply an octet; it makes no difference whether it's signed or unsigned. It
isn't until the byte comes out of the array that it matters, and then it can
be cast to sbyte before any arithmetic gets done on it.

>
> Also, I think translating Java into C# is a pretty bad idea. The two are
> terribly different, and I wouldn't think that java code would be something
> I would want in C#(or vice versa, for that matter).

C# is bigger, since it has events, delegates, unmanaged pointers, etc. But
for the common subset, 99% of the difference between the two languages is
syntax. The object models are close to identical, and the common APIs are
awfully similar too; notice how Random.nextBytes(0 translated to
Random.NextBytes(). It's actually not all that difficult to do correctly.

Relevant Pages

  • Re: CLOS and databases
    ... It is not a Common Lisp to Java or C++ ... translator, but it does allow you to work in a restricted Lisp-like ... be able to easily translate to a single-inheritance, ...
    (comp.lang.lisp)
  • Re: Autotranslate existing libraries?
    ... > A few weeks ago I wrote most of a Java->CL translator. ... > it in favour of "real work" before it was fully complete, ... > a matter of me recognising which CL language feature was ... > half-implemented by a given Java construct, ...
    (comp.lang.lisp)
  • Re: java to tcl conversion?
    ... >>Any automated tools for converting java to tcl? ... do you want a translator that changes Java source to ... > roughly equivalent Tcl source? ...
    (comp.lang.tcl)
  • Internationalization of ordinal numbers
    ... The language would look something like this for English: ... consists of a pattern and a replacement separated by an equal sign. ... pattern is a Java regular expression, and the replacement is what it's ... a translator isn't going to write these ...
    (comp.lang.java.programmer)
  • JAXB 2.0: ambiguity of underscoreHandling="asCharInWord"
    ... I used Google to find information about JAXB 2.0 and I ended up ... downloading a document called "The Java Architecture for XML Binding ... and the latter mapping is possible only if "_" is ...
    (comp.text.xml)