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."
Isn't this what Oracle did with the Oracle virtual jvm that started in 8i? and that was a looooong time ago. Though having used SAP I can see why it would take them years to catch up with the rest of the world.
If a process crashes then all memory that the process has access to is suspect. If that's all the jvm contexts then they're all suspect.
Score: -1, Idiot Who Has Never Written A Line of Code in His Life Yet Wants To Sound Like a Hardened Programmer By Making Retarded Comments About Stuff He Clearly Knows Nothing About
> Well, recently Sun VM and Linux kernel developers have done a lot to improve threading support in kernel and the combination of SUN VM 1.4.1 and kernel 2.6 scales very good.
That does not change the fact that those threads are handled by a virtual machine that provide no isolation between them.
--
Mickaël Rémond
http://www.erlang-projects.org/
Haha, I stopped reading the article at that point. If this article is written for programmers with experience in Java, I see no reason to dumb it down like that. I am surprised he didn't just compare it to MSDOS. Like he said, Java was designed for embedded systems, and that's why "all those passengers are in one ship" The problem he points out lives in the original design. When you start changing the original design quite much, you no longer end up with the same product. .segmond
I have programmed professionally in at least 8 languages, including C, C++, perl, and PL-SQL, and have worked in several others in academic or limited settings.
I have been doing Java since 2000, coming from C++.
Java isn't bad. It is complete; it has a threading model with appropriate concurrency controls. It isn't that different from other imperitive object-oriented languages. It has automatic garbage collection. After startup, on our applications, the performance difference with C++ is negligible, and what we save with automatic GC is quite bankable.
My employer used two strengths of Java to justify the move from C++: platform independence, and garbage collection.
I don't know what jbich wants to see in a language.
I've been doing a lot of Java in the last few years, and I like it.
There are some warts. It uses a lot of memory, RMI should be transparent, the package setup is not very helpful, and iteration is still uglier than python, but in general most things are there for a reason, with an eye on large project development. This is where things make sense -- you can move, refactor, or whatever and once it compiles it probably runs.
Swing is a two-edged sword. It probably doesn't do exactly what you want out of the box, but you can beat it into working pretty closely to what you want.
And the cross-platform stuff really works.
It gets better if you heavily use the collection classes and the libraries.
-- ac at work
I used to code in C (7 years). I used to code in C++ (another 7 years).
I have used Perl and Python.
I prefer Java for the following reasons:
1) I like programming in an object oriented style.
2) C++ has lots of gotchas. My favorite is having to recompile client code for a class when the size of instances changes.
3) Java has a thriving job market. Smalltalk was to hard to get ahold of a widely used compiler (fork over a thousand dollars or more).
And then once you learned it, you had to move to the few towns in which there was a job.
4) You can write cross-platform code that uses serial ports, network sockets, GUI code, encryption and much more without doing #ifdef or automake or autoconf stuff.
You just write the code once, as they say.
5) I work on big programs that take a year to write. So the power of the language to help me organize things makes a big difference.
So Perl, in particular, is out!
C code gets hard (for me) to manage after about 15,000 lines.
I use an IDE written in Java all day and I do not think it is horribly slow. Emacs, of course, runs more quickly, but I have to remember a lot of strange key combinations to get anything done and it looks like crap.
I guess YMMV. Hate and loathe all you want. It leaves more work for me.
You are entitled to your opinion.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
that's bPfaTA
How come when I talk to a company executive, they're implementing SAP.
Nobody ever seem to have implemented it.
The Kruger Dunning explains most post on
I apologize in advance if I sound confrontative, however, I find few things on Slashdot more tiresome than when any language X comes up, instead of sticking to the topic, hordes of people are going to yap about their favourite languages Y, Z, W, V...
.asmx files) and throw it up on a webserver in the /bin folder, and I can have me a webservice, or a simple way to access compiled code from a script.
However, with Java client apps it's write-once, debug-everywhere, since every VM has its quirks you have to troubleshoot, and suddenly I have several versions of my software to troubleshoot (last time I did that was circa 99, so maybe it's better now)
I have personally never come across it, though I had a collegue who claimed to have run across a bug where the JVM on IBMs AIX didn't follow the specifications (forgot where).
The thing works, but the memory leaks were terrible, even making sure I set everything to null after using it, it was a memory bleeding dog.
Er, yes, memory management can be a bit more than nulling objects. Did you every find out what caused it?
And this stuff runs much faster... almost as fast a C. Sounds absolutely nuts, but it's true.
So does Java these days for most parts. And Microsoft have the usual advantage of designing their own system on their own operating system. Come back when they have ported their framework to as many operating systems and devices as Sun has.
The language features are much more clean, like my favorite:
foreach (SomeObject i in SomeCollection)
Java has it too these days.
but there's a ton of language features that I don't want to get into here.
I can say without any irony or sarcasm: Thank you.
It's the stability and deployment that really got me. I can just compile my code to a DLL (and a couple of stub
WAR files...Tomcat....
If I neglect to patch a server, it would stay up longer than the Java boxes.
Are you claiming that there are memory leaks in the virtual machine itself?
Being bitter is drinking poison and hoping someone else will die
Thats not Java, thats your programming.
[Re C#] It's the stability and deployment that really got me...And this stuff runs much faster...
Right... My experience is otherwise. The JIT in Java 1.5, JRockit and other high performance JVMs leaves .NET for dead, even for Desktop Graphics, which was an area I was expecting big improvements in due to its tight binding with Windows, vs the much maligned Swing and AWT. And your ease of deployment example differs from Java how exactly? As for stability, it seems you have become a more competent programmer since you left Java, but your experience with .NET obviously does not go too deep within the networking libraries, or other areas where stability is lacking compared with Java.
or a simple way to access compiled code from a script.
As in groovy, beanshell, jython, jcl...
Like most Java-bashers, he uses proof by vigorous hand-waving...
I blame Windows.
fork(2) is way better than threads in any application where the forked part doesn't need much communication with the parent. Because when a forked process crashes, there's no way for it to harm the parent. Even if you do need communication, fork mixed with pipes, sockets, signals, or shared memory can be great - a little more programming effort than threads, but you can have better-defined interfaces, you limit the damage a single failure can cause, and you often needn't worry as much about synchronization. Copy-on-write, implicit in fork, is also very useful - I just had to make a threaded program, and I basically had to implement copy-all-the-time (or I could have, at the cost of speed, implemented copy-on-write). If I could have just forked, I could have had processor-supported copy-on-write, which would have been faster, simpler, and smaller.
But alas, for whatever reason, Windows has no fork. (Let me qualify that - Microsoft SFU has it by somehow going outside the Win32 subsystem (has Microsoft released this API? If not, why not?), and Cygwin somehow fakes it in an inefficient way.) It's a really bad situation - all reasonable definitions of "cross-platform" include Windows, and thus exclude fork(2), so we're all stuck with the fragile solution of using threads and rolling our own copy-on-write.
Ummmm, no. Cygwin could detect the type of Windows running at startup and then execute different code based on the platform. Cygwin could load the NtCreateProcess function dynamically when NT is detected and use the old style copy everything method for 9x. One code base, and one binary that behaves differently based on the platform.
See LoadLibrary, GetProcAddress, , GetVersionEx and VER_PLATFORM_WIN32_NT.