Board index » kylix » Re: Java vs .NET

2005-01-12 04:47:35 PM
kylix1
Michael Schnell wrote:
be released in a couple of months, though.
Micha
 

Itanium support in XP Home/Pro was dropped. Server 2003 still supports it
and so does .NET.
Dan
"Micha Nelissen" < XXXX@XXXXX.COM >wrote in message

Rudy Velthuis [TeamB] wrote:
equivalent), is COM/COM+.
I have seen some third party ORMs for NET, but have not tried them. ORMs are
surely a possible replacement for entity beans, but not for Stateless and
Stateful Session Beans. I do not know of any equivalent in the MS framework
that uses a truly managed code environment. In my conversations with
Microsoft, they suggest using COM+ (not a real option to EJBs nor JMS).
Of course, I do not propose to be a NET guru (though we have done some app
development with NET), so if I am missing something, I would appreciate the
info.
I do not know of any RMI type framework for NET. MS seems to rely heavily on
Web Services for any remote work in NET. Web services are useful, to be
sure, but there is not as of now, a way to leverage resources across a
clustered environment. FWIU, both MS and IBM are working on Enterprise
frameworks for using network centric management for Web Services, but these
solutions are in the planning phases, and unfortunately, they plan to
develop their own divergent implementations (IBM more open, MS more tied to
NET and MS Operating systems). Java has such services now, that can be
leveraged by using EJBs, RMI, and Web Services, by exposing only those
services needed to be exposed through the Application Server management
space, or through JMS/JMI.
AFAIK, I understand MS is working on a persistent object store and somethign
equivalent to session beans, but they postponed a delivery until Longhorn.
If this is incorrect, I would appreciate additional information.
Have a great day Rudy.
 

{smallsort}

Vassil Nazarov wrote:
complexity ;).
In most cases speed differences between native code and NET/Java is
negligible at best, unless of course, we are speaking of graphic intensive
GUI based clients.
 

to run Microsoft products on.
But OTOH PPC is related to IBM and IBM is one of MS's enemies. So maybe
there will be other "platforms".
-Michael
 

So the .NET framework is not comparable to the JVM?
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message

Robby Tanner wrote:
is NEVER interpreted, always compiled, before it runs.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"If you can count your money, you don't have a billion dollars."
- J. Paul Getty (1892-1976)
 

Oh, I see, you were objecting to the term "interpreter" being applied to it.
Byte code would be a similarity between the JVM and .NET, would that be
accurate?
Rob
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in message

Robby Tanner wrote:
byte code. .NET IL is not really byte code, and was always designed to
be compiled.
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Well-timed silence hath more eloquence than speech."
- Martin Fraquhar Tupper
 

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >wrote in
--
Iman
 

Iman L Crawford wrote:
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"If the brain were so simple we could understand it, we would be so
simple we couldn't."
-- Lyall Watson
 

Hot Spot Detection
Adaptive optimization solves the problems of JIT compilation by taking
advantage of an interesting program property. Virtually all programs
spend the vast majority of their time executing a minority of their
code.
Rather than compiling method by method, just in time, the Java
HotSpot VM immediately runs the program using an
INTERPRETER,
and analyzes the code as it runs to detect the critical hot spots in the
program. Then it focuses the attention of a global native-code optimizer
on the hot spots. By avoiding compilation of infrequently executed code
(most of the program), the Java HotSpot compiler can devote more
attention to the performance-critical parts of the program, without
necessarily increasing the overall compilation time. This hot spot
monitoring is continued dynamically as the program runs, so that it
literally adapts its performance on the fly to the user's needs.
<SNIP>
This is a JVM technology but I suppose .NET is using similar.
--
Vassil Nazarov
 

Vassil Nazarov wrote:
--
Rudy Velthuis [TeamB] rvelthuis.bei.t-online.de
"Many a man's reputation would not know his character if they met on
the street."
- Elbert Hubbard (1856-1915)
 

Robby Tanner wrote:
JITed code is compiled in a cached state manner, The VMs load a class (JVM
or CLR) and the JITs inspects the assembly or jar/classpathj and then
compiles it to native executables (binaries) that are cached in memory.
Most now (HotSpot and the NET JITS) also employ an ahead of time
comilation, where through reflection and introspection, classes are
compiled ahead of time, that is before they are used.
In some cases, JITed code can be faster than compile time compilations. This
should be easily understood in that runtime compilation can take into
consideration hardware performance and machine features, such as CPU power,
memory, cache, etc., on a machine by machine basis, Compile time binary
code, can only operate off of a generalization method, which means that
machine independent power cannot be taken into consideration.
The downside to JITed code is a slower startup time, more need for memory
and processor power for good performance. However, several benchmarks
(google for them) show modern Hotspot code running actually faster than
their native C++ equivalents.
For more info on JIT compilers, look here:
java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html
Both of these article are old and out of date, but does a good job
explaining JIT technology:
www.javaworld.com/jw-03-1998/jw-03-hotspot.html?021698#JIT
members.fortunecity.com/spuri/rtcg.html
There may be some performance hit on start-up but once the app loads, JITed
code can actually performed better than compile time code. Why? Because
certain optimizations can be made at run time, that are not possible at
compile time (memory optimizations,
More info can be found here on how JIT compilers work.
 

Howdy!
Java guy), but for creating persistent objects and saving object states,
I thought that's what serialization was for?
And as far as remoting goes, I thought .Net had a whole system.remoting
namespace that could work over HTTP or just normal TCP?
Then again, I'm a .NET newbie.
Respectfully,
clint