Slashdot Mirror
Quest For "Unbreakable Java" Unites ABAP & Java
jg21 writes "Writing an article about "A Java Server That Never Goes Down" is pure hubris, but a German developer who says he's been "eating, sleeping, and drinking Java" for 8 years doesn't seem to care and his article brings to light the aspects of VM we rarely think of as he introduces "user isolation" and tells about some interesting work SAP in Germany is doing in that area, merging the Java and the ABAP worlds."
I have heard of it jokingly referred to as "German COBOL."
If you enter the world of SAP, be prepared for a thousand acronyms.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Yeah, what the author meant with crash proof is that when a crash happens, only the user whos request the application was processing gets an error, and because of the shared closures, the crash may not even be that bad for the one user.
This scenario breaks down when: there is a bug in the shared classes or the shared closures implementation, when there is a bug causing corrupt data to be written to the shared closuers, when one or more processes trigger a bug which cause them to hog a scarce system resource like memory or CPU time, when a OS bug or a hardware failiure is encountered, etc, etc, etc.
The ideas outlied are sound for an extremely high availability system, but they are not enough to make the clain unbreakable.
Some improvements to the outlined strategy: Use a validator to check that the information written to the shared closures is always correct. Mirror the shared closures to another computer. Have a backup computer which automatically picks up if the first one falls down.
Try out fish, the friendly interactive shell.
Sure, the java developers will make various excuses, but I loathe every Java app I have ever run.
.jsp extensions). You 'loathe' all those websites?
Every one? I doubt that very much. If you have used commercial websites you are sure to have used a significant number of websites powered by Java application servers (check the number of
This is the norm, not the exception. It is not flamebait.
Generally, they are memory leaking pig apps.
Eclipse, Tomcat, JBoss, ant and all such widely used and successful applications are all memory leaking pigs? This would be surprise to the developers of these applications who have honed and tuned them over the years, and the thousands of contented users.
How about the thousands of Java games running on mobile devices in a few MB? Are they memory leaking pigs too?
Sure, there are memory leaking pig Java apps. There are memory leaking pig X apps where X is the language of your choice.