Some interesting points!


"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bs4jkq$rv4$1@digitaldaemon.com...
> Resizeable arrays:
> Java has resizeable arrays in java.util.* you have one.

java.util.Vector

> Now you could say it's
> part of the library not of the language, but where do you draw the line
between
> language and library in Java?

Vector is a container class, and has nothing to do with the [] array syntax of Java. [] arrays in Java are not resizeable. Vectors can only contain Objects, not ints, longs, etc. Where I drew the line is if a feature is part of the so-called core language or not, i.e. if it is built in to the semantics of the compiler. The reason for this is that one can build libraries that do just about anything, as Microsoft's COM libraries for doing virtual function calls in C demonstrate. But few would argue that virtual function polymorphism is a feature of C, even though those C COM techniques *do* work.

> Is java.lang.Object Part of the language or part
> of the library? All classes implicitly inherit from it, so I guess it is
part of
> the language. But if the package java.lang.* is part of the language why
isn't
> java.util.*?

If the compiler translated [] syntax into references to java.lang.Vector (as it does specially for java.lang.String) I would give it a "yes".

> Associative arrays:
> Same as above.

Same as above <g>.

> Templates:
> Make a note about Java, that 1.5 will have generic types.

There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.

> Compatibility -> direct access to C:
> What about JNI? This should become a Yes.

JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.

> Compatiblity -> Use existing debuggers:
> Why should I want to use "existing" debuggers to debug Java oder C# code?

Because some vendors specialize in making debuggers or specialized products that work with the debug output, different debuggers have different strengths and weaknesses, and being free to choose among them is better.

> And than I miss some points in your table:
> under Features:
> Documentation in the sourcecode:
> D: No
> C: No
> C++: No
> C#: No
> Java: Yes

I don't agree. Java's convention of putting documentation in the source code is just that, a convention, not a language feature. Similar things have been done with C, C++, Matthew has done it with D.

> don't know where, maybe arrays, as there are your strong typedefs:
> system independet floatinpoint arithmetic:
> D: No
> C: No
> C++: No
> C#: No
> Java: Yes (strictfp)

In my opinion and in the opinion of people who write serious numerics code, Java's requirement that intermediate results get truncated to 64 bits is a bug, not a feature. I suspect that is why no other language does it <g>.

> don't know where, maybe arrays, as there are your strong typedefs:
> unsigned types:
> D: Yes
> C: Yes
> C++: Yes
> C#: Yes
> Java: No

I missed that.

> under Arrays:
> Covariant arrays:
> D: No
> C: No
> C++: No
> C#: Yes
> Java: No

Not sure what covariant arrays are.

> under OOP:
> Reflection:
> D: VERY limited (if this stays a yes/no-table No)
> C: No
> C++: No
> C#: Yes
> Java: Yes

I intend to improve this in D, but as yet it is, as you say, very limited.

> under Performance (below Templates <- sould be called generic types)
> Automatic type deduction:
> D: No
> C: No
> C++: Yes
> C#: No
> Java: No

Do you mean for function templates?

> under Other:
> Container/Collections:
> D: No
> C: No
> C++: Yes
> C#: Yes
> Java: Yes

This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.

> under Other:
> GUI, Grafic routines, Internet (sokets, ...)
> D: No
> C: No
> C++: No
> C#: No
> Java: Yes

Library routines. I agree that Java, for example, has a very strong and extensive library.

> under Other:
> Object serialising:
> D: No
> C: No
> C++: No
> C#: No
> Java: Yes

Library.

> under Other:
> Remote Procedure Call:
> D: No
> C: No
> C++: No
> C#: Yes
> Java: Yes

Library.

> These points might help to choose, which language is the right one for the
task
> you have to do.

Comparing libraries is important for determining suitability to task, but is not the purpose of the table.

In article <bs5el9$25qq$1@digitaldaemon.com>, Walter says...

[...]

>> under Arrays:
>> Covariant arrays:
>> D: No
>> C: No
>> C++: No
>> C#: Yes
>> Java: No
>
>Not sure what covariant arrays are.

As far as I know, this means the ability to treat an array of subclasses as if it were an array of superclasses:

class B { /* ... */ }
class D : B { /* ... */ }

class X
{
void f(B[] ba) { /* ... */ }

void g()
{
D[] d = new D[];
d.length = 1;
d[0] = new D;
f(d);
}
}


I believe that Java does in fact support this. The difficulty is that it
can open a hole in the type system; imagine for example, that f() above
added a new B onto the end of the array. Then in g(), the assumption that
each element of the array is a D (or subclass of D) is broken. This is
explicitly banned in C++ - you would get a syntax error. C# gets
around this by checking in array element assignment that the assigned object
is indeed a subclass of the actual type of array elements. I am not sure
how Java treats this problem, if such a check is made in the element assignment.

Ian

"Ian Johnston" <Ian_member@pathlink.com> wrote in message news:bs779c$2cto$1@digitaldaemon.com...
> In article <bs5el9$25qq$1@digitaldaemon.com>, Walter says...
>
> [...]
>
> >> under Arrays:
> >> Covariant arrays:
> >> D: No
> >> C: No
> >> C++: No
> >> C#: Yes
> >> Java: No
> >
> >Not sure what covariant arrays are.
>
> As far as I know, this means the ability to treat an array of subclasses
as
> if it were an array of superclasses:
>
> class B { /* ... */ }
> class D : B { /* ... */ }
>
> class X
> {
> void f(B[] ba) { /* ... */ }
>
> void g()
> {
> D[] d = new D[];
> d.length = 1;
> d[0] = new D;
> f(d);
> }
> }

Ok, I see.

>
> I believe that Java does in fact support this. The difficulty is that it
> can open a hole in the type system; imagine for example, that f() above
> added a new B onto the end of the array. Then in g(), the assumption that
> each element of the array is a D (or subclass of D) is broken.

Yes. I had it implemented in D for a while, and took it out for just that reason.

> This is
> explicitly banned in C++ - you would get a syntax error. C# gets
> around this by checking in array element assignment that the assigned
object
> is indeed a subclass of the actual type of array elements. I am not sure how Java treats this problem, if such a check is made in the element
assignment.

A runtime check would be necessary.

I admit Java does lag a bit but:
I think it depends who writes the Java program
as to how it performs. I know that I have written an
Email application(not a small one) in Java which can appear as fast as
outlook express, and never "locks the system".
I have 256 megs of ram and a Athlon 2100(not that that
matters because they are both on the same machine.)
One of Java's greatest advantages is that it is
very very easy to find info and tutorials when you
are learning, and everyone is pleased to help.
Finding a decent tutorial on MFC for example, is
like trying to find a virgin over the age of twelve.

Phill.



"Charles" <sanders-consulting@comcast.net> wrote in message news:bs4m1m$vmh$1@digitaldaemon.com...
> Actually I cant help myself I have to flame here.
>
> Java sucks.  Almost all applications that use Java on my machine are un-bearably slow.  They often lock my machine, and Im on a 2.4 mhz / 600+ RAM!  No other application runs that slowly , not even games.
>
> And the dependence on such a huge virtual machine is a big hit to the language, especially to mimamlist progammers as myself ( D's toolkit fits
on
> a floppy ).
>
> What is it about Java that you like ?
>
> C
>
> "Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bs4jkq$rv4$1@digitaldaemon.com...
> > About the compairison table:
> >
> > especialy about Java:
> >
> > Resizeable arrays:
> > Java has resizeable arrays in java.util.* you have one. Now you could
say
> it's
> > part of the library not of the language, but where do you draw the line
> between
> > language and library in Java? Is java.lang.Object Part of the language
or
> part
> > of the library? All classes implicitly inherit from it, so I guess it is
> part of
> > the language. But if the package java.lang.* is part of the language why
> isn't
> > java.util.*?
> > At least there should be a note, but I would prefer a "Yes".
> >
> > Associative arrays:
> > Same as above.
> >
> > Templates:
> > Make a note about Java, that 1.5 will have generic types.
> >
> > Compatibility -> direct access to C:
> > What about JNI? This should become a Yes.
> >
> >
> > Compatiblity -> Use existing debuggers:
> > Why should I want to use "existing" debuggers to debug Java oder C#
code?
> >
> >
> >
> >
> > And than I miss some points in your table:
> > under Features:
> > Documentation in the sourcecode:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
> >
> > don't know where, maybe arrays, as there are your strong typedefs:
> > system independet floatinpoint arithmetic:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes (strictfp)
> >
> > don't know where, maybe arrays, as there are your strong typedefs:
> > unsigned types:
> > D: Yes
> > C: Yes
> > C++: Yes
> > C#: Yes
> > Java: No
> >
> > under Arrays:
> > Covariant arrays:
> > D: No
> > C: No
> > C++: No
> > C#: Yes
> > Java: No
> >
> > under OOP:
> > Reflection:
> > D: VERY limited (if this stays a yes/no-table No)
> > C: No
> > C++: No
> > C#: Yes
> > Java: Yes
> >
> > under Performance (below Templates <- sould be called generic types)
> > Automatic type deduction:
> > D: No
> > C: No
> > C++: Yes
> > C#: No
> > Java: No
> >
> > under Other:
> > Container/Collections:
> > D: No
> > C: No
> > C++: Yes
> > C#: Yes
> > Java: Yes
> >
> > under Other:
> > GUI, Grafic routines, Internet (sokets, ...)
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
> >
> > under Other:
> > Object serialising:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
> >
> > under Other:
> > Remote Procedure Call:
> > D: No
> > C: No
> > C++: No
> > C#: Yes
> > Java: Yes
> >
> >
> > These points might help to choose, which language is the right one for
the
> task
> > you have to do.
> >
> >
>
>

 java.util.ArrayList
is resizable. However it cant contain primitives.
Although you can use the wrapper classes(Integer,
Double, Float etc)

Phill.

"Walter" <walter@digitalmars.com> wrote in message news:bs5el9$25qq$1@digitaldaemon.com...
> Some interesting points!
>
>
> "Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bs4jkq$rv4$1@digitaldaemon.com...
> > Resizeable arrays:
> > Java has resizeable arrays in java.util.* you have one.
>
> java.util.Vector
>
> > Now you could say it's
> > part of the library not of the language, but where do you draw the line
> between
> > language and library in Java?
>
> Vector is a container class, and has nothing to do with the [] array
syntax
> of Java. [] arrays in Java are not resizeable. Vectors can only contain Objects, not ints, longs, etc. Where I drew the line is if a feature is
part
> of the so-called core language or not, i.e. if it is built in to the semantics of the compiler. The reason for this is that one can build libraries that do just about anything, as Microsoft's COM libraries for doing virtual function calls in C demonstrate. But few would argue that virtual function polymorphism is a feature of C, even though those C COM techniques *do* work.
>
> > Is java.lang.Object Part of the language or part
> > of the library? All classes implicitly inherit from it, so I guess it is
> part of
> > the language. But if the package java.lang.* is part of the language why
> isn't
> > java.util.*?
>
> If the compiler translated [] syntax into references to java.lang.Vector
(as
> it does specially for java.lang.String) I would give it a "yes".
>
> > Associative arrays:
> > Same as above.
>
> Same as above <g>.
>
> > Templates:
> > Make a note about Java, that 1.5 will have generic types.
>
> There have been proposals for templates for Java for years. When it ships officially, please remind me and I'll amend the page.
>
> > Compatibility -> direct access to C:
> > What about JNI? This should become a Yes.
>
> JNI gives C access to Java, not the other way around. JNI cannot call existing C code that has not been rewritten to work with JNI. Try calling printf() from Java <g>, or any C function that has parameters that are pointers, structs, chars, or returns such types. Furthermore, any JNI functions have to be turned into a separate DLL to be callable from Java, they cannot be linked in.
>
> > Compatiblity -> Use existing debuggers:
> > Why should I want to use "existing" debuggers to debug Java oder C#
code?
>
> Because some vendors specialize in making debuggers or specialized
products
> that work with the debug output, different debuggers have different strengths and weaknesses, and being free to choose among them is better.
>
> > And than I miss some points in your table:
> > under Features:
> > Documentation in the sourcecode:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
>
> I don't agree. Java's convention of putting documentation in the source
code
> is just that, a convention, not a language feature. Similar things have
been
> done with C, C++, Matthew has done it with D.
>
> > don't know where, maybe arrays, as there are your strong typedefs:
> > system independet floatinpoint arithmetic:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes (strictfp)
>
> In my opinion and in the opinion of people who write serious numerics
code,
> Java's requirement that intermediate results get truncated to 64 bits is a bug, not a feature. I suspect that is why no other language does it <g>.
>
> > don't know where, maybe arrays, as there are your strong typedefs:
> > unsigned types:
> > D: Yes
> > C: Yes
> > C++: Yes
> > C#: Yes
> > Java: No
>
> I missed that.
>
> > under Arrays:
> > Covariant arrays:
> > D: No
> > C: No
> > C++: No
> > C#: Yes
> > Java: No
>
> Not sure what covariant arrays are.
>
> > under OOP:
> > Reflection:
> > D: VERY limited (if this stays a yes/no-table No)
> > C: No
> > C++: No
> > C#: Yes
> > Java: Yes
>
> I intend to improve this in D, but as yet it is, as you say, very limited.
>
> > under Performance (below Templates <- sould be called generic types)
> > Automatic type deduction:
> > D: No
> > C: No
> > C++: Yes
> > C#: No
> > Java: No
>
> Do you mean for function templates?
>
> > under Other:
> > Container/Collections:
> > D: No
> > C: No
> > C++: Yes
> > C#: Yes
> > Java: Yes
>
> This is a library issue, not a core language issue. Note also that D has strong core arrays and core associative arrays which render many of the container/collection classes in other language libraries irrelevant.
>
> > under Other:
> > GUI, Grafic routines, Internet (sokets, ...)
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
>
> Library routines. I agree that Java, for example, has a very strong and extensive library.
>
> > under Other:
> > Object serialising:
> > D: No
> > C: No
> > C++: No
> > C#: No
> > Java: Yes
>
> Library.
>
> > under Other:
> > Remote Procedure Call:
> > D: No
> > C: No
> > C++: No
> > C#: Yes
> > Java: Yes
>
> Library.
>
> > These points might help to choose, which language is the right one for
the
> task
> > you have to do.
>
> Comparing libraries is important for determining suitability to task, but
is
> not the purpose of the table.
>
>

Phill wrote:
>  java.util.ArrayList
> is resizable. However it cant contain primitives.
> Although you can use the wrapper classes(Integer,
> Double, Float etc)
> 
> Phill.

Right, but doing so is about as convenient as using multiple inheritance from C. :)

 -- andy