Microsoft Losing Interest in C#?

[Michael Adams]

I don't know if you have noticed, but it seems like Microsoft is losing
interest in C#, and putting their energy into Visual Basic.NET instead.

For instance, online chats by language since July 1, 2004:

VB.NET 47
C# 6
C++ 8
J# 0

ADO with VB.NET 6
ADO with C# 0
ADO with C++ 0
ADO with J# 0

Windows Forms with VB.NET 2
Windows Forms with C# 0
Windows Forms with C++ 0
Windows Forms with J# 0

If you look at the roadmap Microsoft has laid out for Visual Studio 2005 and
the various languages, it appears almost all of the RAD improvements are for
VB.NET. The only thing I see coming for C# are a few language enhancements,
but really nothing for RAD. Yes, C# programmers want granularity, but we
don't get paid unless the projects go out, too! You have to get it out the
door. When is Microsoft going to wake up to this?

I don't understand why Microsoft doesn't put the same kind of energy into
the languages that start with a "C" as they do a "B"...and then they wonder
why people defect to Java, PHP, or even C++ on other platforms.

Maybe it's time for C# people to speak up.

Michael

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uO******** ******@TK2MSFTN GP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eI******** ********@TK2MSF TNGP14.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .

When I do this in Java, the output looks like:

2CFFFF1E-0CB4-11D9-A4BE-C3134102AA77
2CFFFF1F-0CB4-11D9-A4BE-C3134102AA77
2CFFFF20-0CB4-11D9-A4BE-C3134102AA77
2CFFFF21-0CB4-11D9-A4BE-C3134102AA77
2CFFFF22-0CB4-11D9-A4BE-C3134102AA77
2CFFFF23-0CB4-11D9-A4BE-C3134102AA77
2CFFFF24-0CB4-11D9-A4BE-C3134102AA77
2CFFFF25-0CB4-11D9-A4BE-C3134102AA77
2CFFFF26-0CB4-11D9-A4BE-C3134102AA77
2CFFFF27-0CB4-11D9-A4BE-C3134102AA77
2CFFFF28-0CB4-11D9-A4BE-C3134102AA77
2CFFFF29-0CB4-11D9-A4BE-C3134102AA77

C# output will be different from Java (due to the random numbers), but
if you run them at more or less the same time,

all UUIDs should be unique. The difference will be an increment in
the first group
the first, time-based, group should be larger for whichever is run
second
the second and third, also time-based, groups, should be identical
the last group should still end in AA77

My results:
D556A42D-0CA5-11D9-8D09-00000000AA77
D556A42E-0CA5-11D9-8D09-00000000AA77
D556A42F-0CA5-11D9-8D09-00000000AA77
D556A430-0CA5-11D9-8D09-00000000AA77
D556A431-0CA5-11D9-8D09-00000000AA77
D556A432-0CA5-11D9-8D09-00000000AA77
D556A433-0CA5-11D9-8D09-00000000AA77
D556A434-0CA5-11D9-8D09-00000000AA77
D556A435-0CA5-11D9-8D09-00000000AA77
D556A436-0CA5-11D9-8D09-00000000AA77
D556A437-0CA5-11D9-8D09-00000000AA77
D556A438-0CA5-11D9-8D09-00000000AA77

The straight 0's at the end seems a little odd, but that may just be an
aspect of my partiuclar machine.

It's definitely a bug. It appears to be in the translation of:

/** randomly generate a node ID. make the last two bytes
* 0xAA77, which cannot conflict with a real Ethernet address */
private void initializeNodeI d()
{
byte barr[] = new byte[2];

Random r1 = new Random();
Random r2 = new Random(r1.hashC ode());
r1.nextBytes(ba rr);
nodeId[0] = barr[0];
nodeId[1] = barr[1];

r2.nextBytes(ba rr);
nodeId[2] = barr[0];
nodeId[3] = barr[1];

nodeId[4] = (byte)0xaa;
nodeId[5] = 0x77;
}

I'll hazard a guess: that the nextBytes call translates to
System.Random.N extBytes(), which fills an array of *unsigned* bytes, and
that the results don't get copied back to barr, which is an array of
*signed* bytes. If so, it's the same bug I saw in 2002.

That does appear to be the case, and, frankly, I would be surprised if any
translator got this right. It seems like something only a person who knew
what the code was supposed to be doing could do.

For what its worht, there is a call to SupportClass.To ByteArray() around
barr in NextBytes, which certainly causes the issue.

It seems much closer, however.

[Ravichandran J.V.]

<!-- really like C# but I wish like good sportsmen I wish MicroTheft was
a good sport and say in their C# Language Release something to the
effect "C# exists because it has stood on the shoulder of Giants..."
-->

Sportsmen play sports and software engineers engineer programs. So, why
have this cross-platform integration?
<!-- Thanks for lending me your mind. -->

When one reads a post here one has no option but to spend some of the
grey matter on the contents as I have done. I am sure, though, that I
have not lent my mind so, please don't use my mind.

<!--
Ofcourse this does not apply to people who are forced by their managers
or senior managers to use a technology/language like VB.NET or VB. It is
these managers who need job security (their business and tech or other
knowledge amounts zero... a well programmed monkey could
do their job.. just like G.W. Bush). -->

why do yhou make grammatical mistakes ? "a well programmed monkey could
do *its* not their job". Syntax and grammar mean almost the same thing,
you know. If you make English grammatical mistakes, do you also make
syntactical mistakes ? It is worth correcting, you know.
with regards,
J.V.Ravichandra n
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandra n+J.V.&cob=aspn etpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID= P3966388&BN=999 &PN=2
- Or, just search on "J.V.Ravichandr an"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Mike Schilling]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uO******** ******@TK2MSFTN GP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eI******** ********@TK2MSF TNGP14.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .
When I do this in Java, the output looks like:

2CFFFF1E-0CB4-11D9-A4BE-C3134102AA77
2CFFFF1F-0CB4-11D9-A4BE-C3134102AA77
2CFFFF20-0CB4-11D9-A4BE-C3134102AA77
2CFFFF21-0CB4-11D9-A4BE-C3134102AA77
2CFFFF22-0CB4-11D9-A4BE-C3134102AA77
2CFFFF23-0CB4-11D9-A4BE-C3134102AA77
2CFFFF24-0CB4-11D9-A4BE-C3134102AA77
2CFFFF25-0CB4-11D9-A4BE-C3134102AA77
2CFFFF26-0CB4-11D9-A4BE-C3134102AA77
2CFFFF27-0CB4-11D9-A4BE-C3134102AA77
2CFFFF28-0CB4-11D9-A4BE-C3134102AA77
2CFFFF29-0CB4-11D9-A4BE-C3134102AA77

C# output will be different from Java (due to the random numbers), but
if you run them at more or less the same time,

all UUIDs should be unique. The difference will be an increment in
the first group
the first, time-based, group should be larger for whichever is run
second
the second and third, also time-based, groups, should be identical
the last group should still end in AA77
My results:
D556A42D-0CA5-11D9-8D09-00000000AA77
D556A42E-0CA5-11D9-8D09-00000000AA77
D556A42F-0CA5-11D9-8D09-00000000AA77
D556A430-0CA5-11D9-8D09-00000000AA77
D556A431-0CA5-11D9-8D09-00000000AA77
D556A432-0CA5-11D9-8D09-00000000AA77
D556A433-0CA5-11D9-8D09-00000000AA77
D556A434-0CA5-11D9-8D09-00000000AA77
D556A435-0CA5-11D9-8D09-00000000AA77
D556A436-0CA5-11D9-8D09-00000000AA77
D556A437-0CA5-11D9-8D09-00000000AA77
D556A438-0CA5-11D9-8D09-00000000AA77

The straight 0's at the end seems a little odd, but that may just be an
aspect of my partiuclar machine.

It's definitely a bug. It appears to be in the translation of:

/** randomly generate a node ID. make the last two bytes
* 0xAA77, which cannot conflict with a real Ethernet address */
private void initializeNodeI d()
{
byte barr[] = new byte[2];

Random r1 = new Random();
Random r2 = new Random(r1.hashC ode());
r1.nextBytes(ba rr);
nodeId[0] = barr[0];
nodeId[1] = barr[1];

r2.nextBytes(ba rr);
nodeId[2] = barr[0];
nodeId[3] = barr[1];

nodeId[4] = (byte)0xaa;
nodeId[5] = 0x77;
}

I'll hazard a guess: that the nextBytes call translates to
System.Random.N extBytes(), which fills an array of *unsigned* bytes, and
that the results don't get copied back to barr, which is an array of
*signed* bytes. If so, it's the same bug I saw in 2002.

That does appear to be the case, and, frankly, I would be surprised if any
translator got this right. It seems like something only a person who knew
what the code was supposed to be doing could do.

I disagree. The translator knows enough to convert
Java.Util.Rando m.nextBytes(byt e[]) to System.Random.N extBytes(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.N extBytes(tempAr r);
CopyFromByteArr ay(tempArr, barr);

At any rate, the fact that JLCA silently produces errors like this is reason
enough for me not to use it.

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:em******** ******@TK2MSFTN GP09.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:uO******** ******@TK2MSFTN GP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eI******** ********@TK2MSF TNGP14.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .
> When I do this in Java, the output looks like:
>
> 2CFFFF1E-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF1F-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF20-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF21-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF22-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF23-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF24-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF25-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF26-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF27-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF28-0CB4-11D9-A4BE-C3134102AA77
> 2CFFFF29-0CB4-11D9-A4BE-C3134102AA77
>
> C# output will be different from Java (due to the random numbers), but
> if you run them at more or less the same time,
>
> all UUIDs should be unique. The difference will be an increment in
> the first group
> the first, time-based, group should be larger for whichever is run
> second
> the second and third, also time-based, groups, should be identical
> the last group should still end in AA77
>

My results:
D556A42D-0CA5-11D9-8D09-00000000AA77
D556A42E-0CA5-11D9-8D09-00000000AA77
D556A42F-0CA5-11D9-8D09-00000000AA77
D556A430-0CA5-11D9-8D09-00000000AA77
D556A431-0CA5-11D9-8D09-00000000AA77
D556A432-0CA5-11D9-8D09-00000000AA77
D556A433-0CA5-11D9-8D09-00000000AA77
D556A434-0CA5-11D9-8D09-00000000AA77
D556A435-0CA5-11D9-8D09-00000000AA77
D556A436-0CA5-11D9-8D09-00000000AA77
D556A437-0CA5-11D9-8D09-00000000AA77
D556A438-0CA5-11D9-8D09-00000000AA77

The straight 0's at the end seems a little odd, but that may just be an
aspect of my partiuclar machine.

It's definitely a bug. It appears to be in the translation of:

/** randomly generate a node ID. make the last two bytes
* 0xAA77, which cannot conflict with a real Ethernet address */
private void initializeNodeI d()
{
byte barr[] = new byte[2];

Random r1 = new Random();
Random r2 = new Random(r1.hashC ode());
r1.nextBytes(ba rr);
nodeId[0] = barr[0];
nodeId[1] = barr[1];

r2.nextBytes(ba rr);
nodeId[2] = barr[0];
nodeId[3] = barr[1];

nodeId[4] = (byte)0xaa;
nodeId[5] = 0x77;
}

I'll hazard a guess: that the nextBytes call translates to
System.Random.N extBytes(), which fills an array of *unsigned* bytes, and
that the results don't get copied back to barr, which is an array of
*signed* bytes. If so, it's the same bug I saw in 2002.

That does appear to be the case, and, frankly, I would be surprised if
any translator got this right. It seems like something only a person who
knew what the code was supposed to be doing could do.

I disagree. The translator knows enough to convert
Java.Util.Rando m.nextBytes(byt e[]) to System.Random.N extBytes(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.N extBytes(tempAr r);
CopyFromByteArr ay(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).

However, I do think that such calls should be flagged by the //UPGRADE_TODO
tag they add to potential errors or changes, I just don't think either
default is a very good choice.

[Mike Schilling]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eB******** ******@tk2msftn gp13.phx.gbl...

I disagree. The translator knows enough to convert
Java.Util.Rando m.nextBytes(byt e[]) to System.Random.N extBytes(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.N extBytes(tempAr r);
CopyFromByteArr ay(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.

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:ub******** ******@tk2msftn gp13.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eB******** ******@tk2msftn gp13.phx.gbl...

I disagree. The translator knows enough to convert
Java.Util.Rando m.nextBytes(byt e[]) to System.Random.N extBytes(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.N extBytes(tempAr r);
CopyFromByteArr ay(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.

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).

[Mike Schilling]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:ub******** ******@tk2msftn gp13.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eB******** ******@tk2msftn gp13.phx.gbl...

I disagree. The translator knows enough to convert
Java.Util.Rando m.nextBytes(byt e[]) to System.Random.N extBytes(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.N extBytes(tempAr r);
CopyFromByteArr ay(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.nextByte s(0 translated to
Random.NextByte s(). It's actually not all that difficult to do correctly.

[Daniel O'Connell [C# MVP]]

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. :-)

Sorry, I came across a little gruff, ;). Honestly I wasn't *that* impressed
by it, myself, though I do think v3 is considerably better than v1.
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.)
It might not be terribly hard, I'm just more concerned with the possiblity
that both choices will be wrong in some cases, can that semantic information
express all possibliities or only a most common scenario? Can the analyzer
determine which possibility is in use? If not, chances are you are going to
get hidden, subtle bugs that upset someone. It just may not happen to be
either of us, ;).
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.

I tend to agree, I think array covariance of primative types(or atleast
signed\unsigned alternatives of one type) is something worht having in the
langauge. But that goes well beyond the JLCA, it is stuck using what it can.
I suppose it could convert to a byte array, but that wouldn't be very
literal and may upset people as well, ;).

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.nextByte s(0 translated to
Random.NextByte s(). It's actually not all that difficult to do correctly.

While most of the api's are similar, personally I think it is the eventing
model that changes things. I write very few substantial pieces of code in C#
that doesn't use an event here or there, and I doubt there is alot of
extensive java code that doesn't use and\or expose event sinks.

However, the other issue is weird bugs like this one. While this particular
bug is a semantic one due to the JCLA, I don't think the application is
capable of definitivly assuring no changes in behavior. Like I said, JJ2k
was something like 350 issues. While I certainly couldn't write a jpeg2000
implementation in the period of time it would take the maintainer to fix
those issues, the time for me personally to learn enough about jpeg2000 and
java to fix those errors without causing issues and keep the java baggage
would probably be high enough to consider a native implementation using .NET
platform conventions. Thus, for the uninitiated, its a pretty useless tool

For me, personally, architectural conventions can go along way towards
productivity. While I don't have many particular problems with java's
conventions, seeing them all of a sudden within .NET code is a shocker and
breaks the mindset somewhat.

[Mike Schilling]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe******** ******@TK2MSFTN GP11.phx.gbl...

It might not be terribly hard, I'm just more concerned with the possiblity
that both choices will be wrong in some cases, can that semantic
information express all possibliities or only a most common scenario? Can
the analyzer determine which possibility is in use? If not, chances are
you are going to get hidden, subtle bugs that upset someone. It just may
not happen to be either of us, ;).
I think that it's well-defined for a given method that a parameter is an
input, an output, or both.

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.

I tend to agree, I think array covariance of primative types(or atleast
signed\unsigned alternatives of one type) is something worht having in the
langauge. But that goes well beyond the JLCA, it is stuck using what it
can. I suppose it could convert to a byte array, but that wouldn't be very
literal and may upset people as well, ;).

Only if they're very literal-minded:-) Seriously, converting to a byte
array rather than an sbyte array doesn't cause any problems, and avoids any
need to copy them.

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.nextByte s(0
translated to Random.NextByte s(). It's actually not all that difficult
to do correctly.

While most of the api's are similar, personally I think it is the eventing
model that changes things. I write very few substantial pieces of code in
C# that doesn't use an event here or there, and I doubt there is alot of
extensive java code that doesn't use and\or expose event sinks.

GUI code, certainly. I think auto-conversion of Swing or awt is hopeless.
I write mostly server code or command-line programs, and there eventing is
either much less common or hidden inside frameworks.

However, the other issue is weird bugs like this one. While this
particular bug is a semantic one due to the JCLA, I don't think the
application is capable of definitivly assuring no changes in behavior.
Like I said, JJ2k was something like 350 issues. While I certainly
couldn't write a jpeg2000 implementation in the period of time it would
take the maintainer to fix those issues, the time for me personally to
learn enough about jpeg2000 and java to fix those errors without causing
issues and keep the java baggage would probably be high enough to consider
a native implementation using .NET platform conventions. Thus, for the
uninitiated, its a pretty useless tool

I agree. Its design point, I think, is people with a substantial
application who are considering dropping their Java development and do a
one-time conversion to .NET, and the goal is to make that feasible by saving
them time over rewriting from scratch. That isn't me; I need to keep a Java
version and a .NET version moving forward together, and JLCA is not useful
for that.

[Daniel O'Connell [C# MVP]]

"Mike Schilling" <ms************ *@hotmail.com> wrote in message
news:Oy******** *****@TK2MSFTNG P11.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:Oe******** ******@TK2MSFTN GP11.phx.gbl...

It might not be terribly hard, I'm just more concerned with the
possiblity that both choices will be wrong in some cases, can that
semantic information express all possibliities or only a most common
scenario? Can the analyzer determine which possibility is in use? If not,
chances are you are going to get hidden, subtle bugs that upset someone.
It just may not happen to be either of us, ;).
I think that it's well-defined for a given method that a parameter is an
input, an output, or both.

It is, however, in a circumstance where its both, at times only input or
only output matters to the caller, the other result is simply unimportant
for whatever reason(usually because an API does too much, I suspect output
is ingnored more often than the input). How do you determine that with a
code analyzer?

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.

I tend to agree, I think array covariance of primative types(or atleast
signed\unsigned alternatives of one type) is something worht having in
the langauge. But that goes well beyond the JLCA, it is stuck using what
it can. I suppose it could convert to a byte array, but that wouldn't be
very literal and may upset people as well, ;).

Only if they're very literal-minded:-) Seriously, converting to a byte
array rather than an sbyte array doesn't cause any problems, and avoids
any need to copy them.

Unless, for some reason, mathematics is involved. I am actually somewhat
surprised that java used signed bytes in this circumstance.

While most of the api's are similar, personally I think it is the
eventing model that changes things. I write very few substantial pieces
of code in C# that doesn't use an event here or there, and I doubt there
is alot of extensive java code that doesn't use and\or expose event
sinks.

GUI code, certainly. I think auto-conversion of Swing or awt is hopeless.
I write mostly server code or command-line programs, and there eventing is
either much less common or hidden inside frameworks.

I primiarly write components, which often expose events that are eventually
listend to by GUI applications. However, I find within the .NET framework,
there are *quite* a few instances where an event or atleast a delegate is
used. Threading, asynch IO, .NET 2.0 generic methods, etc.

Swing and awt are pretty unlikely, although with the new layout manager ins
..NET 2.0 it would be much easier than it would have been before that,
atleast for basic code.

However, the other issue is weird bugs like this one. While this
particular bug is a semantic one due to the JCLA, I don't think the
application is capable of definitivly assuring no changes in behavior.
Like I said, JJ2k was something like 350 issues. While I certainly
couldn't write a jpeg2000 implementation in the period of time it would
take the maintainer to fix those issues, the time for me personally to
learn enough about jpeg2000 and java to fix those errors without causing
issues and keep the java baggage would probably be high enough to
consider a native implementation using .NET platform conventions. Thus,
for the uninitiated, its a pretty useless tool

I agree. Its design point, I think, is people with a substantial
application who are considering dropping their Java development and do a
one-time conversion to .NET, and the goal is to make that feasible by
saving them time over rewriting from scratch. That isn't me; I need to
keep a Java version and a .NET version moving forward together, and JLCA
is not useful for that.

I tend to agree. The only real way to achieve this is to implement a full
java compiler and runtime for .NET (or a full C# compiler and .NET runtime
for java) which allows cross compilation. Otherwise, its simply not possible
to do.

Anyway, for unified version, I just don't think the differing design models
is going to work well, atleast not for component code.