Ted Neward (DevelopMentor, TheServerSide.Net) and Bruce Tate (Bitter Java) talk about the relationship between Java and .NET, underscoring the issues with interop between the two platforms. Presentations are played using the Microsoft Windows Media Player.
Ted Neward and Bruce Tate Talk Java
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Hosted by Microsoft only available on Microsoft technology !
So be sure, the guys are going to say that .net is good and Java is bad, LOL
Whatever they claim, .net is dommed to fail not for technical reason but for strategical ones. Such a problem would have happend to Java years ago is if was invented by IBM and not Sun Micro.
If MS did not have build their clone of Java, and just have continued to be the leader on the Java market (both on VM & IDE) then the story would have been different … but now they are in trouble 😉
Whatever they claim, .net is dommed to fail not for technical reason but for strategical ones.
Strategical?(lol). Is that you G.W??-)? Yeah, all of MS’s strategies have doomed it before. Wow, you sure sound bitter that someone has come out with something that has addressed all the shortcomings of Java. You should be happy that .NET is giving Java competition. God forbid that Sun hadn’t given Java a proper printf 8 years ago. But at least Java will now have generics even if its a broken implementation. Hint…it’s all objects under the hood and suffers from the same boxing and unboxing performance penalties. I guess you’ll also be especially bitter when Mono is shipping with all distros and Java users still have to download it from Sun. Just face it, Java is fine for servers but failed on the desktop.
Yeah, and I guess the presentation should have been all about how Java is so great. LOL.
is there a text transcript anywhere?
“But at least Java will now have generics even if its a broken implementation. Hint…it’s all objects under the hood and suffers from the same boxing and unboxing performance penalties.”
Java advocates do not understand the difference between objects and valuetypes. I tried to explain it again and again, Don’t even bother…
Oh, and they do not give a damn about perforance. They even tried to argue that modern garbage collectors are so good that creating and garbage collecting an object is just as fast as pushing something on the stack.
Before the features of java1.5 were announced I had many discussions with java advocates that said that automatic boxing and unboxing, generics and foreach are evil and unnessecary. Now that java finally supports this, they sound like this was a huge innovation and the best thing since sliced bread.
What the hell is the purpose of posting videos as executable files? Why should I execute a binary from an untrusted source just to watch a video when there are perfect alternatives like avi and wma or, god forbid, mpeg?
What the hell is the purpose of posting videos as executable files? Why should I execute a binary from an untrusted source just to watch a video when there are perfect alternatives like avi and wma or, god forbid, mpeg?
Because they just wanted to hear you bitch and whine about something.
“Because they just wanted to hear you bitch and whine about something.”
I thought that microsoft had this new policy of taking security seriously. Encouraging users to download binaries is the opposite of security consciousness.
If MS did not have build their clone of Java, and just have continued to be the leader on the Java market (both on VM & IDE) then the story would have been different … but now they are in trouble 😉
Umm, last I heard MS was barred from developing and distributing any Java technology by a settlement with Sun over the development of J++ using the Java license and the MS Java VM. How they can be in any more trouble developing .Net than they would have been if they continued to try to develop Java VMs and IDEs I don’t know.
“Before the features of java1.5 were announced I had many discussions with java advocates that said that automatic boxing and unboxing, generics and foreach are evil and unnessecary. Now that java finally supports this, they sound like this was a huge innovation and the best thing since sliced bread.”
Before the features of .NET were announced I had many discussions with Microsoft advocates that said that high-level languages with garbage collection and (at least an attempt at) platform independence were unnecessary. Now that .NET finally supports this (not sure about the platform independence, though), they sound like this was a huge innovation and the best thing since sliced bread.
>Oh, and they do not give a damn about perforance. They even
>tried to argue that modern garbage collectors are so good
>that creating and garbage collecting an object is just as
>fast as pushing something on the stack.
State of the Art Java implementations use copying GCs
(the Sun JVM uses Generational Garbage Collection algorithms
among others); this breed of GC in fact allows for
object creation (at least the memory allocation part,
not the initialization with the constructor) to be as
fast as stack allocation. Why? Because they don’t allocate
memory blocks from the heap; instead memory allocation
actually works similar to stack allocation; this is
possible because of the “copying” property of these GCs;
they allow to have large continuous areas of free memory
where this allocation can happen in a stack like manner,
instead of having to search for free blocks + update
management structures as is the case for malloc.
Sun claims that a “new” (the memory allocation part of it)
now only takes 10 instructions (CPU instructions), which is
much cheaper than anything malloc can provide, and comparable
to stack allocation.
No one claims that Garbage Collection is free; but
research has shown that more than 95% of all created objects
are garbage before the next GarbageCollection; with a
copying Garbage Collector, they don’t have to be touched
again, only the live objects have to be rescued to
an other memory area; so GC is very cheap as well.
You have to keep in mind, that all of these objects
have reference type semantics, thus they are not only
reachable from the activation frame they were created
in, but from anywhere; this is important, as value
types have to be copied around (eg. if you use them
as return values, parameters,…); also: if you create
shortlived objects on the heap and free them again explicitely (ie. by calling free()), this will be way
more expensive than with a copying GC (1 malloc +
1 free in explicit memory management compared to one 10 instructions for GC allocation).
“I thought that microsoft had this new policy of taking security seriously. Encouraging users to download binaries is the opposite of security consciousness.”
Microsoft usually releases videos as self-extracting zip archives.
Interesting. You seem to be quite a bit better informed than most java advocates I had the misfortune to meet on the net.
“Sun claims that a “new” (the memory allocation part of it)
now only takes 10 instructions (CPU instructions), which is
much cheaper than anything malloc can provide, and comparable
to stack allocation.”
That is indeed very impressive. But it is still much slower than just incrementing the stack pointer, which is one instruction: addl $16,%esp.
And all that generational garbage collection does not do you any good if you have a long-lived field of tiny objects.
For example if you need a large array of 2-vectors for vector drawing: the outlines of a few complex polygons.
This is no short lived data, so every object will have to be copied out of the thread-local nursery. There is also a memory overhead for GC and the virtual method table (typically 3 pointers or 12 byte on 32bit architectures).
This is not a big deal when your object is of normal size, but if your object is an Integer object which stores just 4 bytes of data the management information consumes *three times* as much memory as the payload.
Another problem with tiny boxed objects is that you completely lose cache consistency. An array of value types such as an int[] is a continuous block of memory. An Integer[] refers to data which can be spread all over the heap. Current CPUs are extremely inefficient in such a situation.
Another problem with tiny boxed objects is that you completely lose cache consistency. An array of value types such as an int[] is a continuous block of memory. An Integer[] refers to data which can be spread all over the heap. Current CPUs are extremely inefficient in such a situation.
Why would you have an Integer[] array? Java cannot prevent you from writing stupid code.
If you need an array of 2d points, just use an int[] array where odd entries are x co-ordinates, even entries and y co-ordinates.