Probably most of you have C++ expirience so may be you can outline avantages of using Java on server side.
I see obvious disadvantages:
1) Speed - even JIT doesn't come close to C++ native code.
2) There are ways to develop cross-platform highly effective C++ code.
3)Many people complain about Java memory leaks that are killing the server. In Java i don't have control over it.
4)Does it make sense to use J2EE on NT server?
5)The whole issue of "cross (platform/AS)" is questionable at least, since code for different OSes is diffirent. The same applies to different App. Servers.
This is not question about M$ vs Sun ($un) - this is question of Java vs C++.
Well first some stats i have heard that with the latest jits/hotspot java method invocation can be within one clock cycle of C++.
Now on the other hand one could contstruct an app which runs faster in C++ than in java assuming same algorithms etc however the time for most complex C++ would take 30-40% longer and memory leaks can arrise from bad c++ code or libaries etc..
So all in all except for the most performance critical apps ie real time i think overall java is more productive and more cost effective.
Having taught C++/advanced C++ for several years vs teaching java I find that people pick up java faster than C++/
I loved C++ but being a consultant and having to meet tighter and tighter deliveries i find java to be more
cost effective all the way around.
I am preparing a voice chat application with Java Server and VC++ Client. I have read the discussion above. Some of them sound really good. I want to know something specific though. When I send data(converted to bytes) from client to server the following problem occurs:
On sending data in fixed packets continously, the packets forget their limits and multiple messages go simultaneously. The server receives them this way. The server unable to send the data efficiently to the client now, costs the application in terms of audio quality.
Noise and disturbance is present. While the server broadcasts the data, the noise gets in.
Can NEone help me locate what the problem is. Is it related to Java Vs VC++ or not. Maybe, java is not being able to intercept the messages so fast.
If you are talking about brute performance then you are probably correct, C++ will outspeed Java.
BUT and this is a crucial point, scalability is not the same as performance. To scale C++ code (and get transactions and all that cool stuff) you are going to need a middleware server, which means in the case of C++ either COM+ or COM/MTS or a Corba system (don't know much about what i am talking about with Corba, so I could be wrong).
In this case, COM+ is certainly less portable than Java, in the sense you have to run Windows (and this is not the time for an idealogical discussion about MS and Sun). At least with J2EE and well-designed EJB you have the chance to run on different ~operating systems~ (as distinct from platform...).
Anyway, Java is pretty portable, especially on the server side (Sun has been running a deployathon, for example).
Others may be in a better posityion to comment on other types of corba middleware.
I was at JavaONE recently and the same comment came up at a birds of a feather meeting I attended. I really can't answer yea or neah to the speed element. From experience however I think portability across app servers can be 100% provided that the server is spec compliant and the Application in question uses only the parts of the spec that the app servers are BOUND into to providing and not 'features' that MAY be implemented. The test suite that Sun uses to verify J2EE compliance only tests required features. If you develop an Application with these features you can almost be sure your application will work on all compliant app servers.
99% of the response time comes from the DATABASE SERVER, therefore, it really does not make any difference whether C++ is any faster than Java. Who cares if we can optimize 1%. Functionality that does not interface with the database usually does not cause performance problems anyway.
1. It is easy to find Java techies than C++ in the market.
2. Java is richer/easier than C++
3. Once the system gets complex, issues like memory leaks are really pain. As an application programmer why should I be worried about it anyway?
Not necessarily - it completely depends on the application.
DBMS systems can be tuned to run extremely fast indeed.
I've found the DBMS to be the least of my worries when looking at Java based server performance.
First of all when you talk of C++ which version of C++ are you talking about Microsoft, borland, GNU, standard? Honestly, that says it all. If, like most people you are referring to the fast-food version of C++ - VC++ then even that says it all about un-interoperability. So you see C++ is utopian - Believe me, it is far more superior to Java in every aspect but this - no standard portable libraries. But who is going to experiment with their dough, anyway???
"fast-food" version of C++? You mean it is a very productive environment then. This would seem to be a good thing. :}
As for portable libraries, I suppose there's the standard C libs (and classes encapsulating these) and now the standard STL templates (you know, for "generic" programming! :-). Yes, there are many Microsoft specific libraries, such as ATL, WTL and the grandaddy MFC - not to mention access to "managed" libraries within .Net from VC7.
I think it comes down to platform. If you are going live within a Windows 2000 / COM+ environment, then using C++ or other languages that support COM+ or .Net would seem to be a no-brainer - high on the list being performance and cost.
If you are looking to deploy to Unix (for greater single box scaleability, say), then as mentioned, developing on W2K and then deploying to Unix with a Java toolset is ideal model that most follow.
But surely arguments along the lines of "syntax", easier to use (etc etc) are fairly weak (IMHO), because Java is a full first-calss member of the C-family (perhaps a more accurate name would have been Sun C^2 :). The many VB or COBOL programmers out there have traditionally never been comfortable with C-languages (C, C++, Java...)
Points about the database being on the critical path (or even owning most of the path :) are fair in many instances. But performance AND scaleability are also very dependent on efficient use of resources within the application tiers (such as database connections, memory footprint, processor usage...) and this is where a native implementation will always win over a VM. However, VM-based development should be cheaper to construct and perhaps maintain (hence popularity of Basic, including VB, and now Java in the mainstream).
VC++ is definitely the only good version of C++, from development and deployment standpoint (you don't have to write Make files!!!!!).
The standard libraries which come along with C may not be sufficient, and devlelopers have been spending life-times writing just libraries!!!
Regarding your point about knowing the dev platform before hand is what beats the purpose. Well today I am using all that COM, activeX....etc tomorrow if linux sends windows out then is that not a big issue. One should'nt be much concerned about dev platforms for anything!!!!.
Speed matters in real time applications and Java can never replace C in those applications but in secular applications who cares for speed. Was not dos/command-line interface faster than windows? People did a trade-off in favor of ease over speed! Speed is relative.:) It's absurd to compare a rocket launcing C-program (or even fortran program) to a mutual-fund Java web portal app!!
All good points. Here's my take:
1. performance - usually the response time boils down to database access, so there is not much performance to gain with C++. In functions without DB access, C++ can have an advantage.
Also, on a large project, Java will (hopefully) be cheaper to develop. The cost savings in development should more than offset a bigger server.
2. true - however, I think the J2EE APIs give you more platform choices.
3. I haven't experienced this problem, so I don't know.
4. J2EE on NT should be as viable as any other O/S. Like everything, it may be a little slower on NT.
5. Yes, any app that is tightly bound to the O/S will have portability issues.
Designs are not plain black or white they have several variant parameters. Like when you talk about dbms, it is important to know what is nature of the application. Is it simple, typical E-commnerce which has more reads than write? or are more intense and frequent writes.... So these kind of things can make dbms the weakest link in the speed chain. So, citing individual experiences wouldn't help much unless we all are on the same page!!!
I worked for some years on a client/server financials system that was written in C. I have since spent 2 years developing in Java.
1) C generally (I expect the same is true of C++) will pan Java on like for like code execution speed. However, as pointed out above the effect of this is diluted by access times to the DB. Further more, the overall time is often due to a few small bottlenecks in the system, and a good code profiler will probably be a better investment than switching languages. (You can, after all, re-write those tight loops in C/C++. But I have never felt the need to do this).
Despite it slowness, Java can win in other ways. The built in threading can give you design options not available to C/C++ that needs to be portable.
2) Yes and no. You can of course write anything in C++ that you can write in Java. But its a lot of work. There is lots of useful things that come with Java that don't come as standard with the C/C++ compilers from the hardware vendors. GNU gcc will probably give you portable code, but even then you will not get all the nice things like threading, garbage collection, java.util and JDBC.
I have toyed with the idea of using a JVM as the wrapper around C code to give access to some of these services, but I have yet to try it out.
3) I have not hit memory leaks in Java, except where listeners have been registered for events and not unregistered (but this is a coding error).
4) I use J2EE on NT for development. Nothing wrong with that. It's portable to real machines afterwards.
5) This is certainly true when porting C code, every new platform is lots of porting work. Most java code I have written has not needed modification for different platforms.