Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Why (not) Java?

By Jayson in Technology
Wed Oct 18, 2000 at 04:50:13 AM EST
Tags: Software (all tags)

A discussion in my Algoritms and Data Structures class prompted me to wonder why Java hasn't broken into the true mainstream. Alot of the class disscussion was about how MS will rule the world with C# (blah, blah, insert proMS stuff here) and unfortunately, I personally do not see where Java has it's faults. Sure, it's big, and interpreted bytecode, but is this a nice trade off for cross-platform issues.

My university teaches Java, almost exclusively, and their take on it is that it is a highly robust language that teaching one class will undoubtedly not tie the student to any one platform. Unfortunately my CS department seems extremely pro-MS. To the point though, most nay-sayers of Java use the following standard objections:

Java is slow -- not on many of the machines today, not to mention IBM with Jikes has caused me to even wonder why I ever used the JDK.

Java lacks access to memory directly -- I hate memory leaks. Being a linux user I have to deal sometimes with poorly written software that leaks as bad as windows 98. But then again, I would *love* to have access to pointers in Java.. so it's a trade off.

I can't think of any of the other major arguments against Java, but with the advent of Java3d and other add-on API',s could we see Java becoming an application language? Or is it tied to web page applets forever?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


How often do you use Java?
o Java, coffee? huh? 17%
o I have the JDK *somewhere* on my machine 42%
o I use it for class, that's all 13%
o I do major development in java 23%
o I *am* 100% Pure Java Certified 2%

Votes: 143
Results | Other Polls

Related Links
o Also by Jayson

Display: Sort:
Why (not) Java? | 104 comments (93 topical, 11 editorial, 0 hidden)
Pointers in Java? (4.25 / 8) (#3)
by kovacsp on Tue Oct 17, 2000 at 10:19:48 PM EST

Java didn't make sense to me at all (in my early CS days) until I reazlied that all non-primitivies were actually pointers. (If it walks like a duck and talks like a duck...) I think you want direct memory access, not access to pointers.

As for Java itself: I find it easier to do some quick prototyping in Java. Especially when performance doesn't matter (i.e. class assignments) its usually easier to get a Java program working than to work out all the issues in C++.

One thing that really irritates me: Reading from stdin. I've never been able to figure out a really good way to read integers or other non-string types from stdin. Anyone?

Well.. theres a way. (4.00 / 1) (#27)
by dieman on Wed Oct 18, 2000 at 12:17:49 AM EST


Nice little class that lets you take input from stdin for exactly what you want.
[ Parent ]
Do pointers and primitives work in an od way? (none / 0) (#40)
by squigly on Wed Oct 18, 2000 at 09:08:38 AM EST

I reazlied that all non-primitivies were actually pointers

I've never really though it right that "void fubar(Object item, int numblist[], int i)" assumes that the first 2 parameters are references and the third is not. Its not really confusing, but a little anomolous.

People who sig other people have nothing intelligent to say for themselves - anonimouse
[ Parent ]
direct memory access (3.00 / 1) (#47)
by interiot on Wed Oct 18, 2000 at 02:21:30 PM EST

And ideally, you should only need direct access to memory if you're talking directly to the hardware, in which case you shouldn't be using Java at all.

[ Parent ]
Java... (3.58 / 12) (#4)
by pb on Tue Oct 17, 2000 at 10:27:57 PM EST

Disclaimer: I use Java for class, because I wanted to learn it, and see what the big deal is. My University is switching their intro CSC classes to Java as well; it doesn't affect me since I took those classes when they were taught in C++, but I figured I'd check it out anyhow. So far, I'm not too impressed.

The problem I've seen with Java so far are is that it's overly complicated, at many levels. Instead of figuring out which features they needed or wanted, they simply hacked on extra keywords, making the equivalent of 'const' in C into something very ugly and complex. And often, they decide that certain features lead to abuse, so instead they'll just cripple the language, and harken back to the days of S&M programming in strongly-typed languages, where you have to prove that you know what you're doing by doing something you know you should never have to do to get done what you need to do, when it would normally be one line of code in C...

Also, they added 'packages', which I hate, because it breaks the notion of what a protected variable is. A protected variable in C++ can only be accessed by the class it belongs to, or its descendants. In Java, anything in that package can also mess with it. Now, if I want to make a variable in a class 'protected', in the C++ sense, I have to put that class in its own package, and put the rest of the code outside of that package, and make a directory for the package, and include it... Aaaahhhhhhh! If anyone knows about an easier way to get around this, please let me know.

For a much more detailed rant on how Java sucks, check out this one by JWZ. He's obviously messed with it more than I have, since I'm just starting out, and he brings up some good points about it.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall

The JWZ rant (4.20 / 5) (#16)
by Dacta on Tue Oct 17, 2000 at 11:38:38 PM EST

I don't think you are quite being fair to the context of what JWZ was saying. I think it is meant to be a constructive criticism of Java. A quote:

I think Java is the best language going today, which is to say, it's the marginally acceptable one among the set of complete bagbiting loser languages that we have to work with out here in the real world. Java is far, far more pleasant to work with than C or C++ or Perl or Tcl/Tk or even Emacs-Lisp. When I first started using Java, it felt like an old friend: like finally I was back using a real object system, before the blights of C (the PDP-11 assembler that thinks it's a language) and C++ (the PDP-11 assembler that thinks it's an object system) took over the world.

[ Parent ]
The JWZ Rant (2.66 / 3) (#22)
by pb on Wed Oct 18, 2000 at 12:05:15 AM EST

Well, I think I am, but the important part is that you read it! I read the whole thing, including the top, but here's a quote from the bottom for you:

Stay tuned, I'm sure I'll have found something new to hate by tomorrow.

(Well, that's how this document originally ended. But it's not true, because I'm back to hacking in C, since it's the still only way to ship portable programs.)

I gather that from the top, he was trying to give Java a fighting chance, but eventually lost at that as well.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

The protected rant (3.25 / 4) (#33)
by Carnage4Life on Wed Oct 18, 2000 at 12:50:00 AM EST

A protected variable in C++ can only be accessed by the class it belongs to, or its descendants. In Java, anything in that package can also mess with it. Now, if I want to make a variable in a class 'protected', in the C++ sense, I have to put that class in its own package, and put the rest of the code outside of that package, and make a directory for the package, and include it... Aaaahhhhhhh!

Ah yes, this is probably the stupidest language design decision I have ever seen. It has no benefits and causes a lot of discomfort for programmers to hack around. Also Sun changed this in midrelease of JDKs, so this means that there is still a lot of code out there that is written in such a way that protected data is expected to be private inside its own package. I am surprised that a lot of security issues have not cropped up because of this (or maybe they have?)

[ Parent ]
Midrelease of JDKs? (none / 0) (#81)
by sab39 on Fri Oct 20, 2000 at 04:27:21 PM EST

This was changed pre-1.0. How is that "midrelease"?
"Forty-two" -- Deep Thought
"Quinze" -- Amélie

[ Parent ]
cold feet (3.00 / 1) (#39)
by nontoxic on Wed Oct 18, 2000 at 08:19:31 AM EST

i don't want to step into the middle of this. all i will say is that java at the time of introduction was merely a proof of concept; it has since grown and matured. whether or not its growth validates or is invalidated by its marketing hype is another question.

this rant is one of the oldest anti-java rants i know of. perhaps by comparing the rant in chronological order we can gain a proper understanding of the direction of java's progress, and whether not it will ever prove itself in the eyes of 'C' programmers.

[ Parent ]

Proof of concept? (3.00 / 1) (#44)
by pb on Wed Oct 18, 2000 at 10:57:57 AM EST

That's a good rant, and I admit that Java interpreters/compilers have gotten better, and of course computers have gotten faster.

But that's it; I think the rest of his points are still valid. The programmer in question was a C++ programmer, but apparently he still understood some of the power of C, since he likes to have his pointers. After all, he might need them someday.

That's the advantage of not hiding fundamental details from the programmer: when they really need it, they can do what they want. The advantage of hiding it or disallowing it is basically just protecting the programmer from himself, but there are times when this is not necessary or desired. (JWZ's rant has a lot of examples of this...)

I doubt Java will ever prove itself to C programmers; however, the real problem is that in the long run, I bet there will just be less C programmers. :(
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Java != C++ (3.50 / 2) (#46)
by interiot on Wed Oct 18, 2000 at 02:17:36 PM EST

Isn't C++ a strongly typed language?

const is already an ugly and complex thing in C... it means six different things. One of them is easy to do in Java via static final.

Yeah, "protected" means something different in Java, but I guess I've always just accepted that Java is a different language from C++. You don't have any functions outside of objects, you don't have multiple inheritance, and you have this weird thing called an interface. You just have approach the design differently, as you would have to do if with any other language.

[ Parent ]

It's all relative... (3.00 / 3) (#50)
by pb on Wed Oct 18, 2000 at 03:08:31 PM EST

C is more strongly typed than BCPL, but that isn't saying much; it's more weakly typed than Pascal. Since C and C++ still allow the casting of (void*) pointers to arbitrary types, and Java just looks at you funny, I'd say that Java is more strongly typed.

For the rest of this post, pardon my ranting, but...

I suppost this is a matter of opinion, but protected means something profoundly stupid in Java. If I wanted package-level access, I would have made it "friendly". I can't see many instances where the Java version of "protected" would be useful, and I don't appreciate Sun creating a similar language and redefining all the keywords; that is unintuitive at best, and hostile at worst.

'const' in C just works. It is a pretty simple concept to understand.
const MAX_LENGTH = 80;
public static final int MaxLength = 80;

See what I mean about the keyword madness? If Java had a preprocessor, then I could do this instead, to get around this ugliness, and actually get a real constant!

#define MAX_LENGTH 80

But it doesn't, so I can't...

Java does have multiple inheritance, it just only allows it with "interfaces", which are really "pure virtual classes", or whatever the hell they're calling it this week, in sheep's clothing. AND they can STILL have name clashes, so I don't see how it helps that much. Also, two separate interface implementations can't be readily re-used.

So, yes, you have to approach language design differently. As if you were dropped into a hostile and confusing language that LOOKS like many other languages, but by default does very stupid things. People had some of the same complaints about the Object System in C++, and they were right, but that's a completely different rant...

Most of what I don't like about Java is that they took a lot of what was good in C and C++ and completely threw it out the window. Then they took the rest and they broke it slightly. And then they constantly change the spec every 6 months or so, just in case anyone actually catches on. So I'm not very impressed yet.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
This is a pet peeve of mine too... (none / 0) (#71)
by vsync on Fri Oct 20, 2000 at 04:08:54 AM EST

I actually wrote a paper demonstrating how early binding for constants causes problems. I can't see why they decided to do it that way; it creates (yet another) exception to the shiny OO component-based paradigm they had.

"The problem I had with the story, before I even finished reading, was the copious attribution of thoughts and ideas to vsync. What made it worse was the ones attributed to him were the only ones that made any sense whatsoever."
[ Parent ]
Interesting... (none / 0) (#95)
by pb on Sat Oct 21, 2000 at 04:37:47 AM EST

FWIW, I agree; pre-processing should be done explicitly and should be transparent to the compiler. After that, "variables" declared constant (um... I mean static final) should have more type information embedded in the bytecode, to be reconciled at runtime, and probably at startup, most of the time.

But, as they say, "variables won't; constants aren't".
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
um, hello (none / 0) (#89)
by delmoi on Fri Oct 20, 2000 at 10:53:23 PM EST

If you want a variable that can't be accessed from outside the class, regardless of the package, declare it private!!!

Don't knock java for something for not having something it actualy has!
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Um... Hello? (none / 0) (#93)
by pb on Sat Oct 21, 2000 at 04:25:08 AM EST

I think you missed the main point I was trying to make in the first place.

The way protected variables should work (and *do* work, in C++, but not in Java) is to only let members of the base class or its Descendants manipulate them; let's call this class scope. Friendly variables (the default in Java) have package scope, in that anything in that package can use them. Private variables are local to the base class, and public variables have global scope.

However, in Java, protected variables have both class scope *and* package scope. I want *only* class scope for my protected variables, and therefore I have to put the base class (and its descendants too, probably) in a separate package. Then, I have to put that package in a separate directory, and use that package, and it just gets uglier and uglier...

So, no, I don't want a private variable. I want a <I>protected</I> variable that doesn't have package scope. If Java actually has this, then I won't knock it.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
protected vs. private (none / 0) (#88)
by delmoi on Fri Oct 20, 2000 at 10:47:03 PM EST

Now, if I want to make a variable in a class 'protected', in the C++ sense, I have to put that class in its own package, and put the rest of the code outside of that package, and make a directory for the package, and include it... Aaaahhhhhhh!

or you could just declare the variable/member 'private', but you know, whatever...
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
No (none / 0) (#94)
by pb on Sat Oct 21, 2000 at 04:27:47 AM EST

Okay, I was wrong: you didn't understand what I was talking about. One post would have sufficed, though.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
.. (1.62 / 16) (#5)
by Nyarlathotep on Tue Oct 17, 2000 at 10:30:02 PM EST

I gota vote -1 on this story. Java is a pile of dog shit which Sun rushed to get out before Microsoft released something simillar. I expect that C# is a pile of dog shit which microsoft rushed out before Java got a bigger market share. Who needs their lame asses?

Lets talk about programming langauge stuff which is really interesting like:

Just imagine if someone had been clever enough to create a standard langague/bytecode for expressing code AND optimization to a compliler, i.e. your C complier would have three parts (1) write bytecode and some global optimizations (2) additional global optimization code works with byte code (3) complie byte code and preform local optimizations. Actually, C it's self would not be a bad choice for this intermidiate language if you had a way of expressing more optimizations to the complier. Anyway, langauge would be a great intermediate langauge for varous research langauges and would drastically reduce the turn arround time to getting an interesting news langaugae to produce efficent code. This would greatly help the development of functional and object oriented langauge which wish to take advantage of subtile global optimizations which are not available to C.

Plus, when some nimrod at Sun comes up to you and says "lets write a virtual machine," you can say "no lets go add security to a powerful and efficent existing bytecode."

Actually, I had the amusing idea that you could replace the X protocol with an "upload your front end and the X server will run it for you" based protocol. You X programs could be designed to run more efficently accrost the network since each program would have it's own way of talking to it's front end.

Ahh.. The way things could have been if only the academics and/or OSS programmers had done Java first. Regardless, Java is a piece of shit.. we should talk about intereesting ideas instead.

Campus Crusade for Cthulhu -- it found me!
Your post is why you should have voted +1 (4.28 / 7) (#6)
by wookWook on Tue Oct 17, 2000 at 10:32:56 PM EST

Dude, the point of this site isn't to post what you like to page 1, its to post what you think warrants discussion. :-P

[ Parent ]
Do you even know what you're talking about? (4.42 / 7) (#9)
by Speare on Tue Oct 17, 2000 at 10:44:46 PM EST

One, get a dictionary, or stop typing when you're enraged. You misspelled compiler so many times I stopped counting.

Two, many optimizing compilers already DO the work you are talking about: a generic pcode, then another pass to optimize for a given native platform. It's not a reverse-osmosis carbon filter, it's a compiler; tacking on a third or fourth optimizing pass isn't going to help much.

Three, the Java platform wasn't rushed out of any fear of Microsoft's development: MS didn't have anything like it, unless you count the embedded VBA.

Java's worst problem is its own marketing and popularity: everyone has many different opinions on its VM, its syntax, and its standard libraries. Once people have significant projects developed for any of these three levels, refining them while maintaining backward compatibility is a bear. Just ask Microsoft, after twenty-odd years of having to support INT 21h.

On topic to the top-level story, Java's other issues come from "riding the fence" between being a truly isolated sandbox with no pointers or native code, and being cracked to allow Java applications to access legacy code or native hardware features.

[ e d @ h a l l e y . c c ]
[ Parent ]
Duh moron (2.66 / 3) (#25)
by maketo on Wed Oct 18, 2000 at 12:11:28 AM EST

Where exactly do you make your point on "Java is a pile of shit" except on telling us the insides of the Sun / MS strategy on releasing their products? The rest of your post is as computer literate as my cat's.
agents, bugs, nanites....see the connection?
[ Parent ]
Smart cat! (1.00 / 1) (#49)
by tzanger on Wed Oct 18, 2000 at 02:38:52 PM EST

The rest of your post is as computer literate as my cat's.

Your cat can post? And its posts are computer literate?

[ Parent ]
Won't do your homework, but .. (3.00 / 10) (#10)
by recursive on Tue Oct 17, 2000 at 10:48:40 PM EST

I refuse to do somebody's homework. But here are some aspects to consider that the average language flame war misses:

  • type system: polymorphism (ad-hoc/parametric), safety, higher-order functions, closures.
  • module system: independence of interface and implementation, separate compilation.
  • definition: by implementation, or by a language report.
  • orthogonality of concepts.

-- My other car is a cdr.

Functional (none / 0) (#98)
by plop on Sat Oct 21, 2000 at 06:22:24 AM EST

The languages that fit your criteria (ML, Haskell, Erlang etc.) aren't mainstream enough to be flamed about :)

[ Parent ]
Native code (3.00 / 9) (#13)
by enterfornone on Tue Oct 17, 2000 at 11:11:33 PM EST

Java is a nice language. It's certainly a better teaching language than C++ for learning OO (my first OO was Eiffel which is nice but far less relevant to the real world).

What Java really needs is native code compilers (I think Cygnus have one in the works). While bytecode is good for cross platform web apps, most people want native code for real applications.

Then again lots of people are starting to use Python for real apps so perhaps it's not that big a deal. Binding for GTK, QT (even MFC) would be useful too.

efn 26/m/syd
Will sponsor new accounts for porn.
Defeats the purpose (1.00 / 2) (#21)
by maketo on Wed Oct 18, 2000 at 12:01:17 AM EST

Dont you think? Native compilers are going to break the concept of Java like a child's toy. Python, having so many ports to different platforms, is practically in the same position as Java on the portability side. In my experience, it lacks the momentum and the mass of code found around for Java.
agents, bugs, nanites....see the connection?
[ Parent ]
Native compilers (4.33 / 3) (#28)
by fluffy grue on Wed Oct 18, 2000 at 12:28:08 AM EST

Native compilers defeat the purpose of java-bytecode. They do not defeat the purpose of java-language. Java-language is quite neat. And with free software, the source code is much more useful than a bytecode-compiled thingy for distribution purposes anyway.

And personally, I have some serious issues with Python. As far as languages go, it looks, feels, and smells like a toy language to me. If I'm going to go interpreted, I'd rather use something less ambiguous, like TCL (TCL also existing on most platforms and being much more portable IMO than Python, especially between different encodings and linebreak/whitespace semantics, and it's got the really neat thing about being both functional AND imperative at the same time).
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

oops (4.00 / 2) (#29)
by fluffy grue on Wed Oct 18, 2000 at 12:30:26 AM EST

Was a bit hasty in hitting 'post'. Yes, I'm aware that as a language, Python has some functional-ish constructs, but the language itself is imperative, not functional, whereas TCL is functional-imperative in a way that it's natural to program it in either way (or a combination thereof). Basically, TCL is a functional language with an imperative syntax, whereas Python is an imperative language with a little bit of functional syntax (but not in ways which are important, and its functional constructs seem to be more syntactic sugar than anything).
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

python... (none / 0) (#60)
by dragondm on Wed Oct 18, 2000 at 07:07:28 PM EST

I would hardly call Python a 'toy language'. Having worked on some moderate-to-largeish systems in python I can tell you it scales MUCH better than perl, tcl or most other scripting languages I've seen.

As a language, python is a very nice _clean_ OO language. That plus it's ability to write Python classes in C (or java for jpython) helps scalibility an awful lot. Yes it is (quite deliberately) imperitive. So is TCL. Plus I'm not quite sure what is less ambiguous about TCL's pseudo-shell script syntax. TCL is ok as a shell script replacement, and mebbe a macro language, but I wouldn't push it further than that. Plus python has been ported to more systems than TCL (and I haven't had much problem with portability)

Also, python is not interpreted. It is bytecompiled (the bytecompilation happens automatically) C python has it's own bytecode, jpython bytecompiles to java bytecode.

[ Parent ]
java assembler (none / 0) (#42)
by mikpos on Wed Oct 18, 2000 at 09:21:00 AM EST

As mentioned, the Java language and the Java bytecode are two completely different things (you can thank marketing, I'm sure, for giving them the same name).

While having a native Java compiler would be cool, I think the opposite would be even cooler: a JVM gcc back-end, so that you could compile your C code (or C++ or ObjC or Chill or Fortran or ...) code for the Java virtual machine. I'm not sure how practical this would be (since the Java virtual machine seems to do garbage collection instead of conventional memory management), but it would be cool nonetheless.

[ Parent ]

I've been waiting for this, actually (none / 0) (#61)
by fluffy grue on Wed Oct 18, 2000 at 08:58:50 PM EST

It'll be really nice for when MAJC comes out. :)
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

JVM running other languages (none / 0) (#73)
by jacob on Fri Oct 20, 2000 at 10:51:16 AM EST

I don't know first-hand, but a friend of mine who worked on an experimental Java (to JVM) compiler as a research project told me that the JVM and Java are coupled a bit more closely than you might think. It does not have the concept of pointers anywhere, for one thing, and I believe exception stuff is built-in.

However, that doesn't mean that you couldn't make a C-to-JVM compiler with enough work. You could, for example, have the program at startup just declare a huge array and then implement its own new and delete functions that would manually manage that array. Pointers would just be references to the array. That's really just a funky JVM version of happens with C on non-virtual machines, at least with modern operating systems. A C implementation that used that trick could even have the nice property that the C programmer could declare GC'ed and non-GC'ed data, where GC'ed data would just get allocated via a JVM new() and non-GC'ed memory would get allocated into the array manually. It would be like the optional garbage collection in C++ that K5 covered a few days ago. I imagine exceptions could be handled similarly, turning them into an optional asset for the programmer.

Interesting... Does anybody know if that has been tried?

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]
Mobile Agents (4.50 / 2) (#31)
by HypoLuxa on Wed Oct 18, 2000 at 12:45:11 AM EST

If you look into the future of some developments, you will see where bytecode is imperative. The concept of Mobile Agents are programs that can move from one machine to another during their execution. They move themselves, all of thier instructions, their current state, stuff stored in memory and just hop on along to wherever they are going to resume running. In a mobile agent framework, it's imperative to jump from one platform to another without have any platoform specific dependencies to trip it up. I think the emphasis needs to be put on increasing the speed and reliability of current java implementations, so bytecode can be faster and run better, but not lose crucial portability.

BTW - I am no expert on mobile agents, it's just something I've read a little about. If you have an corrections for me, let me know.

I'm guided by the beauty of our weapons.
- Leonard Cohen
[ Parent ]

Mobile Agents (none / 0) (#43)
by B'Trey on Wed Oct 18, 2000 at 10:28:43 AM EST

Bytecode is necessary for Mobile Agents. And Mobile Agents likely will become more popular in the future. But I think it'll be a long while, if ever, before Mobile Agents replace standard apps.

[ Parent ]
SPHERE FOREVER (none / 0) (#91)
by delmoi on Fri Oct 20, 2000 at 11:12:55 PM EST

Forget this Java/C++ stuff, Spherescript is the future, err.. make that javascript
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
who cares about the bytecode (none / 0) (#90)
by delmoi on Fri Oct 20, 2000 at 11:06:55 PM EST

I doubt that native-targeted output would really be much faster then then current bytecode/JITcompilation. It might even be slower, since the JIT can do optimizations that a static compiler can't.

What I'd really like to see is good native librarys, maybe even a way to access C++ class libs(Kind of like the way you can access win32 functions in VB). I'd love to be able to write games in Java, but I can't even go full screen or get good timing info on windows!

"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Common misconception re: pointers in Java (3.45 / 11) (#14)
by fluffy grue on Tue Oct 17, 2000 at 11:17:06 PM EST

Yeah, I know, Sun hasn't exactly been wonderful at pointing this out (all their marketing literature propagates the myth that Java has no pointers as a 'feature'), but guess what: Java does have pointers, to the point that almost everything is a pointer.

In fact, the only things which aren't semantically pointers in Java are the fundamental datatypes (int, double, char, etc.). True, the language itself has no syntactic way to express pointers, but syntactically, non-pointers are the exception, not the norm (and that's where the Double, Int, Char, etc. types come in - they're pointers to fundamentals).

Evidence: Everything is passed around by reference. The = operator just assigns a new reference. You must do a .clone() in order to create a new separate instantiation of an object. For example, the Java code:

Double MyFunction(Double c)
    Double a, b;

    a = c;
    b = c.clone;
    return b;
is equivalent to the following in C++:

double *MyFunction(double *c)
    double *a, *b;

    a = c;
    b = new double(*c);
    return b;
Basically, in Java, nearly everything's a garbage-collected pointer. Yeah, you can't do the neat pointer arithmetic tricks that C/C++ allow, but in my experience, those are just asking for trouble anyway, and some compilers are smart enough now to optimize loops on arrays to do a pointer traversal through it rather than re-indexing from the base anyway, right?
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

Not really... (4.50 / 2) (#20)
by pb on Wed Oct 18, 2000 at 12:00:57 AM EST

Using gcc on Intel with -O or higher does this. (forgive my funky variable names; I felt whimsical)

static x;
double mint[100];
for (x = 0; x < 100; x++) mint[x] = x * x;

Turns into this loop: (this is just the loop, but rest assured that at the beginning, %eax is 0, %edx is 1, and %ecx points to the base of the array.

imull %eax, %eax
pushl %eax
fildl (%esp)
popl %eax
movl %edx, %eax
fstpl -8(%ecx,%edx,8)
incl %edx
cmpl $99, %eax
jle .L6

Note the (%ecx,%edx,8): if I'm not mistaken, that's doing the re-indexing from the base. Fortunately, this sort of nonsense is built into the x86 instruction set, so that line isn't really any less efficient, at least.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
Well, yeah (4.50 / 2) (#26)
by fluffy grue on Wed Oct 18, 2000 at 12:16:15 AM EST

That's the other thing - reindexing from base on base-indexing architechtures such as x86 doesn't suck. It'd be interesting to see if the optimizer would actually optimize pointer indexing in the case of register starvation, at least.

Also, I hate to fall back to this argument (being in general a proponent of gcc as a compiler), but gcc isn't the best compiler out there. :) What version of gcc is that? FWIW, on gcc 2.95.2 using -O9 -mpentiumpro it puts out pretty much the same code as yours (using base-indexed addresses).

Well, blah. I added in some code for causing register-starvation on gcc, and it still base-indexes it. When I try this code on a SPARC machine using gcc, I get the similar following:

        !#PROLOGUE# 0
        save    %sp, -912, %sp
        !#PROLOGUE# 1
        mov     0, %l0
        add     %fp, -816, %l1
        mov     %l0, %o0
        call    .umul, 0
        mov     %l0, %o1
        st      %o0, [%fp-16]
        ld      [%fp-16], %f4
        sll     %l0, 3, %o0
        fitod   %f4, %f2
        add     %l0, 1, %l0
        cmp     %l0, 99
        ble     .LL6
        std     %f2, [%l1+%o0]
From what little SPARC assembler I know, it looks like it's base-indexing still. I don't think there's any systems at NMSU where base-indexing is less efficient than pointer-incrementing though.

Okay, okay, I admit it. Java's lack of pointer arithmetic does lead to some inherent slowdowns given gcc-caliber optimizers, but it's mostly splitting hairs on modern CPUs anyway. :)
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

GCC and suckage (4.50 / 2) (#34)
by pb on Wed Oct 18, 2000 at 12:58:18 AM EST

I'm using gcc 2.96 20000731, (the infamous Red Hat snapshot version) but it generally seems to work.

I would argue that gcc is pretty good on x86, although I don't have much to compare it against, at the moment. However, it definitely has competition on the SPARC; here's what cc (Sun WorkShop) does with -O; it looks like it does The Right Thing.

/* 0x0024 6 */ call .mul ! params = %o0 %o1 ! Result
= %o0
/* 0x0028 */ ld [%i0],%o1 ! volatile
/* 0x002c */ st %o0,[%sp+92]
/* 0x0030 */ ld [%i0],%g2 ! volatile
/* 0x0034 */ sll %g2,3,%g2
/* 0x0038 */ ld [%sp+92],%f2
/* 0x003c */ add %g2,%i2,%g2
/* 0x0040 */ fitod %f2,%f2
/* 0x0044 */ st %f2,[%g2] ! volatile
/* 0x0048 */ st %f3,[%g2+4] ! volatile
/* 0x004c */ ld [%i0],%g2 ! volatile
/* 0x0050 */ add %g2,1,%g2
/* 0x0054 */ st %g2,[%i0] ! volatile
/* 0x0058 */ ld [%i0],%g2 ! volatile
/* 0x005c */ cmp %g2,100
/* 0x0060 */ bl,a .L900000113
/* 0x0064 */ ld [%i0],%o0 ! volatile

"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
[OT?] base addressing vs iterators (none / 0) (#45)
by codemonkey_uk on Wed Oct 18, 2000 at 11:33:56 AM EST

Interesting ... this prompts two related questions...

Firstly, Java may not support "pointers" directly but does it support the iterator idiom on its container classes? IIRC iterators compile down to near optimal efficiancy.

Secondly, (and this is the OT bit) how well does gcc generate iterator style loops? Iterators are the "natural" ideom in C++/STL, where as base-indexing is the "natural" ideom in C/arrays...

..that is, how does the code generated for:

vector<double> mint(100);
for (vector<double>::iterator x = mint.begin(); x != mind.end(); ++x) *x = 0;

compare to:

static x;
double mint[100];
for (x = 0; x != 100; ++x) mint[x] = 0;

(ignoring the setup costs), and are there systems where base addressing will be more efficient than iterator style loops (and for those that don't know, incrementing a pointer over an array in C *is* an iterator style loop).

"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Java Iterators (4.00 / 1) (#52)
by alder on Wed Oct 18, 2000 at 03:28:38 PM EST

IIRC iterators compile down to near optimal efficiancy

You've obviously confused STL iterators, that are templates, and essentially "inlined" with Java Iterator(s), which are classes that implement java.util.Iterator interface. Due to this difference STL iterators really in most cases are optimizable by a C++ compiler, and Java iterators are never (and cannot be) optimized by a Java compiler.

Even if we forget for a moment that Sun's compiler does not optimize anything and imagine an ideal Java compiler, I doubt it will be able to do any optimization without template "inlining", and Java does not have templates (though it would be much better with genericity than templates, IMHO). IIRC, there are very, very few compilers (not Java :-) that can do optimizations across function calls, and no one can optimize across virtual calls, which is exactly tha case with Java iterators, where methods are called through invokeinterface...

[ Parent ]
Wrong... (none / 0) (#83)
by sab39 on Fri Oct 20, 2000 at 05:00:20 PM EST

Double, like String, and Integer, and most of the other "primitive-like" builtin types, is immutable. Your code will simply not work.

The way to do things like this is to return AN object, which contains a field for each value you want to return (frequently you'll find that this is what you are really doing, eg returning the X and Y coordinates of a single point) or to create your own class that is mutable and pass that in. Or, the hacky way is to pass in a 1-element array of doubles and return your result in the first element. There are a bunch of ways to do it, and yours isn't any of them ;)

"Forty-two" -- Deep Thought
"Quinze" -- Amélie

[ Parent ]
Not quite (none / 0) (#92)
by delmoi on Fri Oct 20, 2000 at 11:17:11 PM EST

In java, primatives are never pointed to, they are always passed by value. all objects are passed by refrence, though.
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Who uses it? (2.57 / 7) (#15)
by AgentGray on Tue Oct 17, 2000 at 11:31:16 PM EST

What I'm curious to see what platform it's used on the most. Does anybody in the Linux environment use it?

I don't.

We use it :) (1.66 / 3) (#19)
by maketo on Tue Oct 17, 2000 at 11:56:37 PM EST

Linux + tomcat + jdk + cocoon + xerces (I just pushed the last two onto the managerial team)....We use it for client web sites, more complicated ones that is. The simple ones are done in PERL ;>
agents, bugs, nanites....see the connection?
[ Parent ]
Re: Who uses it? (4.00 / 1) (#24)
by loner on Wed Oct 18, 2000 at 12:10:38 AM EST

Well as a contractor I've used it at two different companies in Sili Valley. Both were using it to implement the server-side programs for their commerical web-based software. They were both basically using JSP + Java servlets + JDBC. And it worked like a charm.

Java was tailor-made for web-server programming. The servlet concept replaces CGI programs with the difference that they stay in memory for better performance (by design not as an add-on like mod-perl). I've used both Perl and Java for web-based programming and I find Java much easier to deal with for such a concept.

As far as platform, in both cases the engineers developed using Allaire's JRun -- or some other servlet engine -- on the platform of their choice (Windows, Unix) with the production system running on Solaris which seems to be the most popular web server at least here in Sili Valley.

I'm an old-timer so I wasn't even aware that Java was being used in class. To me it's the language of choice for serious web developers.

[ Parent ]

I do (none / 0) (#62)
by gawi on Thu Oct 19, 2000 at 12:15:54 AM EST

The only problem I got with Linux and Java dates back to the Blackdown pre-release of JDK 1.2. Garbage collection was not performed under some conditions (it has been fixed now). For released versions, everything is going very smoothly. My main usage is servlet development. I'm currently using the IBM JDK 1.3.0.

For the record, I've also been using it in Win32 and Solaris environments.


-- Are you in denial?
[ Parent ]

I use it (none / 0) (#85)
by bendawg on Fri Oct 20, 2000 at 05:47:01 PM EST

Our company runs jrun on Solaris for our production servers. But, I do all of my jsp and servlet development on a Linux machine. I'm also doing a project at home on a Linux machine running apache and jakarta-tomcat. I use the IBM jdk instead of Sun's, it seems to be quite a bit nicer. I tried to use swing to create an graphical application once (using blackdown before swing was really ready). I found swing to very buggy at the time, and haven't done any graphical applications with java since then.

[ Parent ]
Where have YOU been? (3.38 / 13) (#35)
by Carnage4Life on Wed Oct 18, 2000 at 01:01:37 AM EST

I wouldn't have been surprised to see this article a year or two ago but seeing it now is rather incongruous. Java is mainstream. Servlets, Enterprise Java Beans and JSP are used quite a lot in industry. Java has become so popular that I have been asked about my Java/XML experiences in depth at the last 4 interviews I have attended. Old school C hacks (e.g. Kernighan from K and R) are writing books that use Java code. A majority of the programming jobs on Monster.com, Hotjobs.com, etc are looking for Java programmers.

To be honest, the only people who I have seen who think that Java hasn't arrived are a few of the Linux/Open Source groupies on slashdot who seem to know how to use grep and write a Perl script and think they are l337.

PS: By the way I voted -1 for this article because it lacked substance.

PPS: Applets are a brain dead idea. Even Sun has stopped pushing them, in fact Sun has cancelled almost all their Java GUI applications and are focusing more and more on the server and distributed component architectures that lie therein.

Bloat (2.44 / 9) (#36)
by evvk on Wed Oct 18, 2000 at 02:47:20 AM EST

You know, not everyone has the huge amounts of memory to run java. It may sometimes be pretty fast, but I don't see that as an excuse for bloat. And not everyone wants to/can afford be upgrading their computers every half a year because programmers are lazy (or others won't let them do their job well). And I don't like to wait for simple programs to start for a minute. (Big Swiss Army Knife programs don't do anything well anyway).

What it comes to teaching only Java, people should be exposed to a wide variety of different languages to learn new ways of thinking - and learn functional (but not lisp, it is a horrible mess :-) and logic programming languages as well. And people should be trained to avoid creating memory leaks. If the language prevents memory leaks, the mistakes will just be somewhere else. This may also make programmers too careless ("I can't make a mistake, the compiler doesn't let me"). Prove the programs correct (functional languages are helpfull here), don't test their bugness with users.

java = applets ? (1.75 / 4) (#37)
by hany on Wed Oct 18, 2000 at 03:25:22 AM EST

I can't think of any of the other major arguments against Java, but with the advent of Java3d and other add-on API',s could we see Java becoming an application language? Or is it tied to web page applets forever?

Java alredy IS application language (if I count servlets as applications).

Or other way: Java is not tied to web pages - it is used far more on servers (for example).


One useless academic's opinion (2.83 / 6) (#38)
by Alik on Wed Oct 18, 2000 at 07:19:37 AM EST

Other studies have limited the amount of coding I currently do, but I'll tell you why I personally avoid Java when I do code: it's a pain in the ass. Unless one works with it on a regular basis, the language appears to change every few months. I don't want to deal with a language that's likely to keep breaking older code. Therefore, I plan to wait for the language to reach a stable state (shouldn't be more than a few more years), at which point it'll be time to really learn it.

There are other reasons. When last I tried Java, two years ago, I found WORA to be an utter joke; my classes never did the same thing on different architectures or with different compilers or interpreters. It is my impression that this has since gotten a lot better as the underlying tech has matured.

Finally, there is the agony of compilation. This is probably a personal failing, but I could never get things to compile properly. I found _Mr. Bunny's Big Cup O' Java_ (a wonderful little book) to be dead on: Java compiles .java files into warnings and error messages, as a side effect producing .class files containing bytecode. I will never forget (or forgive) being told that my program could not be compiled because there was "bad magic in this file". (I am not making this up.)

In all, at least part of what you're seeing may come down to the fact that people got burned by Java when they tried to be early-adopters and are treating it cautiously until they're sure it's not going to hurt them.

breaking code? (4.00 / 1) (#64)
by gawi on Thu Oct 19, 2000 at 01:07:53 AM EST

I don't think you have any idea of how stable is Java as a programming language.

If you are talking about the API, it is reasonably stable. Deprecation is a good mechanism to indicate potential gotcha with your old code. But it will still compile. Some compilers likes Jikes can compile 1.0 compliant code given the right compilation flag but that's the only language-level related option. Compare this to the dozens of flags you can mention in a C++ compiler. At this point, I'm not sure if you are seeing this as a good thing of a bad thing. :-/

Also, you are the first person I know complaining about compile-time errors.


-- Are you in denial?
[ Parent ]

Leverage of Architectural Advantages (2.66 / 3) (#41)
by eskimoses on Wed Oct 18, 2000 at 09:19:36 AM EST

One key problem with Java actually lies in the fact that it is so portable. By targeting the least common denominator of computer architectures, Java fails to leverage the advantages of a particular architecture.

For one, this poses a problem in architectures with optimized instruction sets, such as systems with fast vector operations. Native Java compilers may make inroads on this front.

Secondly, this disadvantages systems with software architectures already designed to handle industrial-scale operations. Take IBM mainframes, for example. The CICS transaction system has years of development, improvement, and careful tuning behind it, and yet Java applications running on a mainframe are compelled instead to use Java's transaction system.

This won't be any help to mainframe customers wanting to jump on the Java bandwagon; suddenly the performance of their Java programs is nowhere near what it would have been written in C, because it no longer leverages the system's built-in transaction architecture.

In a sense, Java turns a supercomputer, mainframe, or workstation into the least common denominator: a PC.

Tradeoffs (none / 0) (#48)
by interiot on Wed Oct 18, 2000 at 02:31:20 PM EST

So it's a tradeoff: speed vs. ease of coding/portability.

Tradeoffs between execution speed and portability have been made before... C vs. assembly for instance. Or hardware abstraction layers (eg. common sound or video API's) for another.

Sometimes the tradeoff is a good one and it becomes the de facto standard. Sometimes it's not worth it because it's just too slow. But just because it makes things run slower doesn't mean it's instantly thrown out.

Bjarne Stroustrup has said "no language is better than every other in all possible ways". So just because Java isn't appropriate for simulating nuclear reactions on a mainframe doesn't mean that it doesn't have its place.

[ Parent ]

Java Complaints (4.60 / 10) (#51)
by Mark 'Kamikaze' Hughes on Wed Oct 18, 2000 at 03:22:37 PM EST

Ah, the standard laundry list of complaints. First, a bit of history, so you know where I come from here: About five years ago, I first saw Java applets, and laughed it off as a stupid web animation tool. Four years ago, IBM came out with JDK 1.0 for OS/2, and I gave it a try, and within three months I'd permanently abandoned C and Objective-C, my former languages of choice. I've written a few dozen lines of C in the years since, and I'd like to never do it again. I also do Python and PHP (well, and far too many bash scripts...), so I'm not a one-track programmer...

On native compilers and speed: Just-In-Time compilers and Hotspot already do compile your bytecode to native machine code. They do it at program startup time. The one flaw in this plan is that they currently do not cache the machine code, and so there's a nasty startup delay (Hotspot a bit less so than JIT). The current speed is, for most tasks, 80-95% of the speed of equivalent C programs. The worst-case, high-CPU, array-intensive code (thus getting a bounds check on every test, and so on), can drop that to about 50%. The speed in the first few years was far far worse, and if you turn off the JIT, you can still experience that 5% efficiency. So don't do that. If you do blatantly foolish things like

for(int i = 0; i < s.length(); ++i)
    s2 += s.charAt(i);
Then yes, you will see worst-case performance. You should learn the native idiom, by looking at what's in the libraries:
int len = s.length();
StringBuffer sb = new StringBuffer(len);
for(int i = 0; i < len; ++i)
    sb.append( s.charAt(i) );
s2 = sb.toString();
After all,
is actually just syntactic sugar for:
new StringBuffer().append(s1).append(s2).toString();
(and the default size of a StringBuffer is only 16 chars...) String addition is almost never a good idea.

"But I miss templates, multiple inheritance, pointers, and operator overloading!": Too bad. C++ programmers have proven, starting with Bjarne and his thrice-damned iostreams, that most programmers cannot be trusted with certain features. It's all their fault, they abused the concept and ruined it for everyone. Feel free to punch the next C++ programmer you see in retaliation, but please don't ask for these things in Java. Pointers in C (and the lack of garbage collection and array bounds checking) are the cause of almost all software crashes and security holes in "modern" software.

Things Java is really missing: Enumerated types are my #1 complaint. Especially if they could have had a way to get the NAME of the enum as a string, unlike C's brain-damaged implementation. Sure, you can make a class to do it, and I have a standard superclass for Enums in my own library, but it was a horrible omission. The runner-up is not pretending that primitives are objects, too. The primitives SHOULD have been objects, replacing those silly wrappers. IMO, they got almost everything else right.

Write Once, Test Everywhere: Aside from the brain-damaged early implementations of Java on the Mac, and early variations between browser-supplied JVMs, this really does work almost all of the time. I initially wrote Java under OS/2, and it worked perfectly under Windows (and Mac once I'd learned what to avoid). Now I develop under Linux... and it works perfectly everywhere, too. But you do have to test your apps and applets on multiple platforms, there's no other way to catch all the 'gotchas' in cross-platform computing.

Sun sucks: Yes, it does. Scott McNealy is so paranoid he makes Fox Mulder look like Neville Chamberlain, and the political battle around standardizing Java was just insane. But that doesn't change the fact that Java's a kick-ass language, often in spite of Sun's best efforts.

Applets suck: Yes, they do. Applets are useless, except as clients to a server-side application. I never browse the web with Java turned on, I turn it on ONLY for specific pages that have some applet client I need. That said, they're also really really great, because they're a zero-effort installation. No download/run/click through the wizard stuff, no fiddling with config files, and best of all, no risk of viruses. Just go to a web page, and turn on Java support. Bang (well, after the download...), you're running.

Ultimately, it's the best language I've yet seen for writing applications. It's not appropriate for device drivers or writing operating systems; that's what portable assembler, aka C, is for. It's not a good scripting language, as it has no 'eval', fairly poor support for running external programs, and pretends that all OS's have the same kind of filesystem. For that, use Python (or whatever...). Java Servlets and JSP (which are actually compiled into Java servlets by the JSP engine) are a good competitor for PHP, but I think PHP's a simpler and more elegant language for dealing with database-driven web sites, and it's a good deal leaner.

-- Mark Hughes
Templates and References... (4.00 / 1) (#67)
by XScott on Thu Oct 19, 2000 at 06:12:54 PM EST

I agree with most of your comments. I don't particularly like Java, but that's just because I hold a grudge from a couple of years ago when I tried to get work done with it. I'll try to be fair and assume for the sake of this comment that performance and portability are actually a reality (if they aren't now, at least they _could_ be someday).

I rather like Java's decisions regarding Multiple Inheritance. At most one base class, and an arbitrary number of interfaces is definitely the way to go. I now do that in C++ when I'm creating a hierarchy of classes.

I have a tough time swallowing no references and no templates in Java though. Your reply of "Too Bad" doesn't really cut it. To this I say "It's Too Bad that Java isn't going to find more acceptance".

A lack of pointers is fine. You don't need to do *p++ in your loops, and the compiler should know what you mean and still do things efficiently. But passing fundamental types by reference sure would be nice when you need more than one return result. Creating a temporary object to wrap up your double is really pretty wasteful when the function is recursive. (Imagine a divide and conquer algorithm for a 2D image, traversing a tree where each node has 4 children, but the tree goes about 8 to 10 levels deep. The stack didn't grow too big, but boy did you create a lot of temporary objects just because you couldn't pass by reference directly. I had an actual problem like this several years ago.)

Next, using the Object base class for collection classes is just as (well, almost as) bad as using void * in C++. Java doesn't need to use C++ syntax or looseness (the Microsoft ATL is a perfect example of abusing templates) to implement this, but parameterized types are good in a language which tries to keep you from doing stupid things. The Java way opens a pretty big hole in an otherwise tight type system.

I'm still sticking to C++ for my personal projects despite what they want me to do at work.

-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Problems that are no problem. (4.00 / 1) (#78)
by Mark 'Kamikaze' Hughes on Fri Oct 20, 2000 at 02:11:07 PM EST

XScott wrote: A lack of pointers is fine. You don't need to do *p++ in your loops, and the compiler should know what you mean and still do things efficiently. But passing fundamental types by reference sure would be nice when you need more than one return result. Creating a temporary object to wrap up your double is really pretty wasteful when the function is recursive. (Imagine a divide and conquer algorithm for a 2D image, traversing a tree where each node has 4 children, but the tree goes about 8 to 10 levels deep. The stack didn't grow too big, but boy did you create a lot of temporary objects just because you couldn't pass by reference directly. I had an actual problem like this several years ago.)

Well, sure, doing lots of object creation when you don't need to is not a good idea, but that ain't the language's fault. Instead, you should make a little container class: public class MyDoubleWrapper { public double value; }, and you can instantiate it once and just pass it around by reference. I suspect that redesigning your code to be more OOP would also solve that problem - any time you're passing the same value to many methods, it's a very good sign that that value should be an object, and the methods should be on that object instead of wherever they are now. c.f. Martin Fowler's book <u>Refactoring</u>.

Next, using the Object base class for collection classes is just as (well, almost as) bad as using void * in C++. Java doesn't need to use C++ syntax or looseness (the Microsoft ATL is a perfect example of abusing templates) to implement this, but parameterized types are good in a language which tries to keep you from doing stupid things. The Java way opens a pretty big hole in an otherwise tight type system.

That would be true, IF Java wasn't able to determine the class of an object held in an Object reference. But it can.

for(Enumeration e = vector.elements(); e.hasMoreElements(); )
    Object foo = e.nextElement();
    if( foo instanceof Magic)
        throw new IllegalArgumentException("I can't do any magic to a "+foo.getClass().getName());

You have to learn the local idiom in order to properly use any language. C++ has its own bizarro behaviors (IMO, it has nothing but bizarro behaviors), and you can easily write totally broken code in it if you don't understand its idioms. The same goes for Java. For those who really need to learn more, I'd highly recommend Bruce Eckel's fine book Thinking in Java, 2nd Ed.. You can read it free on his web site, or buy a print copy. <subliminal>give Bruce more money so he can write more books</subliminal>

-- Mark Hughes
[ Parent ]
Re: Problems that are no problem. (4.00 / 1) (#80)
by XScott on Fri Oct 20, 2000 at 02:47:11 PM EST

I'll think on your comment about refactoring the code to be more object oriented. I'm not sure it applies, but I'll think on it some more.

Just to be clear, I needed to get two values out of what was pretty analogous to a trig function. Just to keep it simple, pretend it was a polar to rectangular conversion. In C++, I'd declare it like:

   void PolarToRectangular(double a, double r, double &rX, double &rY);

and call it in the obvious fashion. In Java:

  void PolarToRectangular(double a, double r, Double X, Double Y) { /* ... */ }
  void SomeWhereElse() {
    // ...
    Double TempX= new Double()
    Double TempY= new Double()
    PolarToRectangular(a, r, TempX, TempY);
    x= TempX.doubleValue();
    y= TempY.doubleValue();
    // ...

That's pretty ugly (or at least wordy), and if the function gets called frequently and I don't want to create a zillion objects I need to keep TempX and TempY as members of the class or make them static (does Java have local static variables?). Would you really have me create a PolarPoint class, and a RectangularPoint class with member functions defining the conversions? That's pretty heavy duty overkill, and it still requires creating a lot of temporary objects for a very simple task.

But I said I'd think about it. Do you have a better solution to this problem? It's pretty close the problem I was working on.

Your solution to templates (using run time type checking) doesn't catch the error at compile time. That's usually not prudent when it can be avoided with parameterized types.

-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Of course.... (5.00 / 1) (#82)
by sab39 on Fri Oct 20, 2000 at 04:51:57 PM EST

First off, your code won't work. Double (as all other "primitive wrapper" classes) is immutable; you can't set its value after creation.

The idiomatic way to do this in Java is something like this:

class PolarCoordinate {
  double a;
  double r;

  PolarCoordinate(double a, double r) {
    this.a = a;
    this.r = r;

  RectangularCoordinate toRectangular() {
    /* ... */

class RectangularCoordinate {
  double x;
  double y;
  RectangularCoordinate(double x, double y) {
    this.x = x;
    this.y = y;

  PolarCoordinate toPolar() {
    /* ... */

When you come to actually use this, you probably already have a PolarCoordinate object (because you would be using these in the rest of your code anyway) but even if you don't, your code looks like:

RectangularCoordinate rc = new PolarCoordinate(a, r).toRectangular();
x = rc.x;
y = rc.y;

Don't ever try to use the builtin wrapper classes as references. That's not what they're for, and it doesn't work :)


PS the only reason my use code looks ugly is that my class names are too long - it would look a lot nicer if they were RectCoord and PolarCoord :)

"Forty-two" -- Deep Thought
"Quinze" -- Amélie

[ Parent ]
Re: Of course.... (4.00 / 1) (#86)
by XScott on Fri Oct 20, 2000 at 06:24:49 PM EST

Thanks for the clarification on the immutable wrapper classes.

You have to admit that is a lot more code to accomplish something fairly trivial. Do you really prefer that to the more straightforward way you can do it in C++?

In a performance sensitive application, if you were doing these conversions thousands of times per second would you be comfortable with the number of short lived objects being created?

-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
Re: Of course... (none / 0) (#102)
by sab39 on Mon Oct 23, 2000 at 11:29:04 AM EST

Well, admittedly Java isn't exactly optimal for high-performance, computation-intensive code... And to some extent you have a point - that's a lot of code for a simple operation.

But to some extent you're missing Java's strength here. It's common wisdom (I know that it's referenced, for example, in ESR's latest book) that programmer time is generally more expensive than computer time. Java's strength is in saving programmer time - programs tend to be written much faster in Java than in other languages (depending on what the program is, of course - use the right tool for the right job).

"But", I hear you say[1], "How can it be saving programmer time if you have to write all that code just to return multiple values?".

(First of all I'd point out that it's not really *that* much extra code; if you really wanted to minimize the amount of code you could write:

class PC { int a; int r; }

PC r2p(int x, int y) {
PC pc = new PC();
pc.a = ...;
pc.r = ...;
return pc;

which I count as only 3 lines more than the equivalent C++. But that's not really the point...)

My real answer is that the time taken in writing the extra code is recouped in the greater reusability and transparency of the code. Reusability: the Coordinate objects can be reused throughout your application whenever you need to represent a point in space, so you only need the overhead once. Transparency: the structure of the code reflects its function much better than the equivalent C++ code does. In the C++ case, all you know is that you're putting two numbers in and getting two numbers out. In the Java case, you know that you're performing an operation on a RectangularCoordinate that gives you a PolarCoordinate. That's a lot clearer, especially for someone other than the original author coming to maintain the code later.

Your point about short lived objects is also a good one, but these days Java VMs are heavily optimized for this case (since it happens so often in well-written java code). Since I'm not a VM guru I don't know exactly how it works, but tricks like generational garbage collection and object reuse eliminate a lot of the performance hit of having lots of short-lived objects.

Also, if you choose your data structures wisely, you'll often find that the same objects can be used throughout your application. So in some cases, perhaps, your objects won't be quite so short-lived because you can store them and pass them to other code. For example, if you are doing conversions of a list of points, you might store those points as a list of Coordinate objects and pass that list of objects to the code that will eventually use them.

If none of that convinces you, or if your application is going to do a lot of conversions without needing to store the results (eg because it outputs them immediately), there are still ways you can go. If, after profiling your code, you find that your bottleneck is in object creation and garbage collection, you can change your API and do your own object reuse:

public void toRectangular(RectangularCoordinate rc) {
rc.x = ...;
rc.y = ...;

(the Java equivalent of this C code:

void toRectangular(RectangularCoordinate *rc) {
rc->x = ...;
rc->y = ...;

and just as efficient).

So, yes, I do take your points; the "natural" way of doing these things in Java doesn't necessarily give you great performance, and it's a lot of code to write if you can't then reuse those objects elsewhere. But Java's strengths shine through when the applications start getting bigger and more complex, because then it starts getting likelier that you *can* keep using the same objects throughout the application.

[1] Doesn't that phrase always sound so patronizing? Sorry...
"Forty-two" -- Deep Thought
"Quinze" -- Amélie

[ Parent ]
Re: Of course... (none / 0) (#103)
by XScott on Mon Oct 23, 2000 at 08:44:27 PM EST

Well, admittedly Java isn't exactly optimal for high-performance, computation-intensive code... And to some extent you have a point - that's a lot of code for a simple operation.
Some people would claim it could be optimal. I think compiler writers can be pretty clever when they try, so I'll assume Java could eventually sneak up on C++. In other words, I'm not arguing against Java as a language on performance grounds (even though I think that's probably still legitimate).

As an aside, I've certainly been bitten by the performance issue though. Even if one particular platform has a great JIT and amazing performance, it's not really WORA when it runs 20 times slower on a comparable machine with a different OS. And while this was several years ago (maybe things have improved), the great JIT was still significantly slower than same application written in C++.
Java's strength is in saving programmer time
The Python crowd has been flying that flag for a while, and I think they have a better claim to it than Java does. You're probably correct that Java has C++ beaten in this regard, but I wouldn't say it is by much. Python and Perl programs (depending on whether you are Pedantic or Pragmatic) are likely to be much shorter than either Java or C++. I think C++ could come asymptotically close to Java in this regard if there was a well designed standard C++ library for GUI things and the like.

In the C++ case, all you know is that you're putting two numbers in and getting two numbers out. In the Java case, you know that you're performing an operation on a RectangularCoordinate that gives you a PolarCoordinate. That's a lot clearer, especially for someone other than the original author coming to maintain the code later.
I disagree with this. I could rephrase it to favor C++ by saying, "In the Java case, all you know if that you're getting one Object from another Object. In the C++ case, you know you're converting rectangular coordinates to polar coordinates." If I named my function ConvertRectangularToPolar(...), I think most programmers would have a pretty good idea of what I was doing. If my Java code looked like PC= RC.getPC(), most programmers would need some clarification. It's just a naming issue.
Doesn't that phrase always sound so patronizing? Sorry...
Not at all. You're just being a good advocate trying to anticipate my objections.

I don't think we'll come to an agreement about the one true way to structure the code though. I'm slowly coming to side with the Perl folks in that "there's more than one way to do it" is a good thing. In our example, my first choice for how to do it would be to create a simple function that takes some fundamental types as references. My mind just likes that simple solution. Java doesn't let me do that, so I need to work around the language and learn the Java way to do it. I guess that's ok, but it feels kind of constricting.

I also haven't heard anyone give a good reason for why pass by reference of the low level types should not be in Java. Pass by reference doesn't necessarily imply user level pointers (and pointer mistakes), and since all class Objects are passed by reference it would be inconsistant to argue that this is a bad thing in general. Can you offer a reason for why pass by reference should be excluded from the Java language for the core types?

What's your take on the lack of parameterized types? (The standard "Java doesn't have templates" argument.) Substituting the Object base class and pushing off the type handling until runtime could (and very likely is) hiding bugs that could have been detected by the compiler before the program was ever run. If Java did templates in a good way (similar to how it did inheritance/interfaces in a good way), would you have any argument against it?

-- Of course I think I'm right. If I thought I was wrong, I'd change my mind.
[ Parent ]
memory leaks (none / 0) (#79)
by lux on Fri Oct 20, 2000 at 02:13:25 PM EST

Pointers in C (and the lack of garbage collection and array bounds checking) are the cause of almost all software crashes and security holes in "modern" software.

I've seen lots of memory leaks. In the java code produced by coworkers. And, of course, garbage collection itself can cause problems - when the GC kicks in, performance steps out for coffee.

Don't forget the huge memory footprint that Java incurs outside of memory leaks. If I wrote C++ code that needed as much memory as most java apps I'd be embarassed.

If you aren't worried about processing pauses (i.e. you're serving out webpages, where people are used to waiting 10-15 seconds for a response) and you can spend lots of money putting plenty of memory on all your systems, the tradeoff may be worth it.

Just don't tell me you don't have to worry about memory leaks. You do. They're real. And GC makes them harder to find.

[ Parent ]
Enumerations solved (none / 0) (#87)
by ryanc on Fri Oct 20, 2000 at 07:31:42 PM EST

Things Java is really missing: Enumerated types are my #1 complaint.

I think JDC Tech Tips addressed this recently, but I can't find a reference. You can create a new class for each enumerated type you want, and then use the singleton pattern to fill in the values. This has the advantage of type safety, and unlike C/C++ you can no longer get away with things like dayOfWeek = Monday + 2 * (Thursday - Tuesday);.

public class DayOfWeek {
  private DayOfWeek() {}
  public static final Monday = new DayOfWeek();
  public static final Tuesday = new DayOfWeek();

And then after that you can just use DayOfWeek.Monday or whatever, which is of class DayOfWeek, just like you would expect. I personally find this solution much better than treating everything as an integer.

[ Parent ]
More Java Complaints (none / 0) (#97)
by plop on Sat Oct 21, 2000 at 06:06:23 AM EST

> "But I miss templates, multiple inheritance, pointers, and operator overloading!": Too bad. Actually James Gosling is now proposing that operator overloading be added to Java. You were correct about C++ ruining multiple inheritance (although languages like Dylan handle multiple inheritance far better) but do remember that C++ also ruined operator overloading (with cin/cout). Operator overloading makes a lot of sense especially when dealing with numbers. Think about the BigInteger/BigDecimal classes. Adding 2 numbers involves something like bigInt1.add(bigInt2) which just doesn't make as much sense as bigInt1 + bigInt 2, especially for more complex expressions. What if I wrote a method that would apply a certain equation to arbitrary types of numbers? Java has 2 major problems making this awkward, basic types aren't objects, and the operator overloading problem whereas a language like Dylan has a Number class/interface which all numbers inherit from with the basic operators hence making this problem very simple. Back on the topic of multiple inheritance, sure a lot of programmers can easily fuck it up, I blame the initial OO hoopla when everybody had to use every wow wee feature of the language to feel good about themselves, when MI was used when SI would do, or even when no inheritance was required in the first place. However, that doesn't stop you from coding properly/responsibly in an MI language, whereas in the case of an SI language like Java, you're screwed if something emerges that might better be handled in MI, a glaring example of this is the Java I/O system with it's long winded and ugly decorator patterns to do anything useful with I/O. Also there is the necessary separation between input and output (into different objects, Java's SI hierarchy can't handle it otherwise) even though in many situations it is preferable to express them as the one object. I can go on for hours about how Java gets on my wick, but don't get me wrong, I hate C++ more, but not because of Multiple Inheritance and Operator Overloading.

[ Parent ]
Speed (3.00 / 1) (#53)
by dj@ on Wed Oct 18, 2000 at 03:41:57 PM EST

It's interesting to me that assembly programmers used to make the same complaints about C when it first emerged. Eventually, ease and speed of development "won". Java is definitely taking over. Even if Java the language doesn't "win", the concept of an abstraction from the underlying OS MOST CERTAINLY WILL!!! Eventually, as a user, you will care as much about the operating system as you do today about the BIOS.

C++ abstraction from the underlying OS = POSIX (none / 0) (#75)
by daani on Fri Oct 20, 2000 at 11:37:28 AM EST

[ Parent ]
Java != ByteCode... (3.00 / 2) (#54)
by Parity on Wed Oct 18, 2000 at 05:24:04 PM EST

Okay, this is obvious, Java the Language is not Java ByteCode; but it makes me wonder, has anyone out there tried putting together a different language that compiles into the same bytecode and runs on the same JVMs?

I'm not a Java/JVM expert (was that obvious? ;)), so maybe the bytecodes are too horribly closely tied to the language... but, I have trouble imagining that to be true (after all, bytecode is just an abstract, idealized machine language, so... )

Parity None

Many Compilers produce Java ByteCode (4.50 / 2) (#55)
by drewcifer on Wed Oct 18, 2000 at 06:20:21 PM EST

The first that pop to mind are the JPython Project and the Kawa scheme interpreter/compiler. Both of which are very nice projects.
For a much more comprehensive list, check out this site

[ Parent ]
Very cool. ;) (3.00 / 1) (#58)
by Parity on Wed Oct 18, 2000 at 06:52:28 PM EST

Thank you, you have just ruined any remaining productivity for this workday. ;) I think I'm going to have to try some of these toys... I mean, tools... ;o Parity Space

[ Parent ]
Java != ByteCode... (2.75 / 4) (#56)
by kingsquab on Wed Oct 18, 2000 at 06:22:13 PM EST

You are describing one of the concepts included in Microsoft's .NET architecture. The virtual machine would not be tied to one particular language, although C# would (presumably) be the best fit.

[ Parent ]
Borelo (4.00 / 1) (#69)
by Nishi-no-wan on Fri Oct 20, 2000 at 12:47:59 AM EST

Software AG's Borelo is kind of a cross between the Natural Language and Java. At least, that's how I see it from a Java perspective. Natural programmers that I've talked to disagree.

But, like the question asks, the output is all Java byte codes.
Swinging for the stars
[ Parent ]

Other languages running on JVMs (4.00 / 1) (#74)
by ajf on Fri Oct 20, 2000 at 10:51:21 AM EST

Off the top of my head NetRexx and JPython are two JVM-based implementations of existing scripting languages.

"I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
[ Parent ]
Why I hate Java (3.00 / 1) (#57)
by stimuli on Wed Oct 18, 2000 at 06:41:28 PM EST

I could write for hours on all the things I hate about Java, but I'll just mention one that I don't often see commented on:

Operating on linear structures (arrays and lists) is a primary programming task, and the smoother a language makes it the better. In Java we have C style arrays (strongly typed), Vector's (weakly typed), ArrayList's (weakly typed). The latter two don't accept primative types. Each is accessed by different means (via for(;;) loops, Enumaration's, and Iterator's respectively). Added to these types are Strings, StringBuffers (linear groups of characters), StringTokenizer (produces a lazy list from a String), not to mention the other linked list types. There is a fundamental abstraction common to all of these, but the combination of Java's weakness as a language and crappy, poorly conceived library design, forces me to code differently to each one.

Compare this to a language like Haskell, where when you write code to operate on a list of objects, it will happily accept any list of objects, strictly typed or polymorphic as you choose.

I think one finds this same lack of foresight throughout Java and its libraries. I for one hate the language.

Naturally I'm a Java programmer by trade *sigh*

-- Jeffrey Straszheim

Iterators and Lists (4.00 / 2) (#63)
by gawi on Thu Oct 19, 2000 at 12:47:20 AM EST

Each is accessed by different means (via for(;;) loops, Enumaration's, and Iterator's respectively).

Enumeration is the old-way of iterating elements of a structure, if you want to to iterate your Vector with an Iterator, you can do so because Vector implements the List interface.

Added to these types are Strings, StringBuffers (linear groups of characters), StringTokenizer (produces a lazy list from a String)

I fail to see to problem here. Having a String class is a must. Or were you complaining about yet-another-array-of-char? What is your alternative? template <class charT, class traits = string_char_traits<charT>, class Allocator = alloc > ?? Hmph! A String is an immutable object. A StringBuffer is optimized for buffer manipulation. What is the problem?

Clearly, there are some redundant mechanisms with the Collections and some former classes (like Vector and Hashtable) but frankly if this is the only criticism you can address to Java, I don't think you are sufferring that much. Been doing any C++ lately? You should, just to understand what pain really is.

Compare this to a language like Haskell...

Made me look... ;-) Interesting...

but the combination of Java's weakness as a language and crappy, poorly conceived library design

There is room for improvement in Java and the language will evolve according to developers needs. Go to java.sun.com to post your request for enhancement if you have some ideas.


-- Are you in denial?
[ Parent ]

I hate Haskell (none / 0) (#65)
by fantastic-cat on Thu Oct 19, 2000 at 05:29:19 AM EST

OK I don't hate Haskell it's an elegant and well thought out language but then it's not very quick and I've never seen a large system built in Haskell (and would dread the prospect of having to build one myself). My main problem with Java is that you can't access the memory directly, the garbage collection is shit and most of the VM implementations are abysmal.

also a Java coder by trade.

[ Parent ]

I don't hate Haskell (none / 0) (#96)
by plop on Sat Oct 21, 2000 at 05:36:55 AM EST

Haskell is not very quick if you use the HUGS interpretter, however if you use the Glasgow Haskell Compiler it claims execution times of around 1.3 times that of C code (which easily outpaces Java and in some cases C++). It also happens to be a very good language for writing large applications in, being very strongly typed, very safe, mathematically proveable code and usually expressing code in about 1/4 (often less) the amount of space as Java. But Haskell has the disadvantage that every other language that doesn't look and act like C suffers from, the "real world" programmer's reluctance to venture from what they know. The fact that it also happens to be a functional language may be more of a hurdle, it's a much greater leap to move from imperative programming to functional programming than a syntax change (imperative languages like TCL, VB and Python enjoy some success despite not looking like C), it's an even greater leap than moving from procedural to OO programming. It brings a cynical tear to my eye everytime I see a l33t PERL hacker scoffing at the conformist VB yuppie.

[ Parent ]
Partially agree (none / 0) (#84)
by sab39 on Fri Oct 20, 2000 at 05:04:39 PM EST

I agree with your points about the necessity for strongly-typed lists (and partially with your point about putting primitives in them, although I'd prefer to see an easier way to "box" primitive items so they can be put in regular Object-based lists).

The good news is that Sun is working on adding generics to Java, and although it won't be in any release soon, it is winding its way through the Java Community Process (Sun's half-hearted effort at a standards track) as we speak.


"Forty-two" -- Deep Thought
"Quinze" -- Amélie

[ Parent ]
computers only give us answers (2.00 / 1) (#59)
by scali on Wed Oct 18, 2000 at 06:52:33 PM EST

For one thing, Java the language is different from Java the environment. As a language, it's fine. Nothing special, cleans up a few of C's broken operator precedences, but is very clumsy at various simple things like using primitives with methods that want classes. Life continues.

However, as a general API, it is by far the best. It's UNIXlike, in fact. A lot of little tools to open socket connections, read files, interact with web browsers, make games, etc. JWZ's critique is missing the point: He's locked into thinking in the ways of his previous languages. It's fighting the language to make things lean and overhead-free. (If you really want speed, use Jikes' obfuscation, dump everything into one class file, make everything public static final. Maybe browse _Practical Java_.)

Blah blah, etc. There is no tying to applets. There is no theory. Rid your mind of these things. You use an applet when it is natural to do so; you eat whatever you feel like at the moment.

Why I have a seething hatrid for Java (2.60 / 5) (#66)
by Zanshin on Thu Oct 19, 2000 at 01:56:17 PM EST

I DO have a seething hatrid for Java. It's not because it's completely non-functional, you can certainly get stuff done in Java, it is for oh so many other reasons.

1. Bondage and discpline. Personally, I'm not into that kinky programming language stuff. Gimme something I can work with and that I don't have to write 10 billion lines of code to do one simple thing.
2. Speed. Java has been slow, and compared to its semi-close equivalents (I suppose C or C++), it is still slow with all the new tweaks.
3. Functionality. Java offers little functionality over basic C or C++. Windows are a bit easier than programming with the MFC, but that's about it.
4. Hype. Java has been wayyyy over hyped for years. Sure, it's a spiffy little language with some neat features, but it is not all it's made out to be. This has caused Java to be used in far too many places where it shouldn't be. And, consequently, shoved down the throats of people who don't want to deal with Java's faults.
5. The rubber hammer syndrome. Already a bondage and descipline language (see 1), Java goes that extra mile and makes sure that almost every tool you use has been stripped down and padded. In the real world we use real tools. Yes, sometimes these tools are dangerous, but often powerful and dangerous go hand in hand. I wouldn't expect someone to build a house using a circular saw with a plastic blade, similarly, deciding to use Java can often be crippling in and of itself.
6. Perl. Perl offers many of the advantages of Java, but with fewer of the downsides. It's portable, it has tons of functionality, it has tons of power at your fingertips, it's pretty fast, it works great in tons of environments / circumstances. Perl has been doing the cross-platform compatibility thing long before Java got into the picture. And it keeps on doing it.
7. Javascript (aka ECMAscript). In many of the places where java may look like a good candidate for usage, javascript is often the better choice. Javascript is simple, lightweight, it is not bondage and discipline, it has tons of built in no-nonsense functionality, development times are shorter...
8. Flash. Graphics and interactivity on the web are now standardized and handled by a plugin. Flash has won the battle. It is faster, more portable, easier to "program", and much more focused on the needs of web graphics.

This leaves Java with almost no niches where it can live. The last refuge of Java seems to be the classroom, where bright-eyed students don't mind the faults of Java because they don't know any better (literally).

The one key neato thing that Java did that was special and unique (compiling to platform-independant byte-code) is not dependant on the Java language, nor is it as important or useful as some claim it to be (at least not in practice, yet).

Technically... (3.00 / 1) (#72)
by Farq Q. Fenderson on Fri Oct 20, 2000 at 08:13:34 AM EST

The one key neato thing that Java did that was special and unique (compiling to platform-independant byte-code)

I wouldn't call this unique. Infocom has the Zmachine, which does the VM thing, only it's intended as an adventure game VM (Zork runs on it, baby). The Zmachine has implementations on a much vaster range of platforms than the java vm... there are others too.

farq will not be coming back
[ Parent ]
Indeed... (3.00 / 1) (#99)
by pb on Sat Oct 21, 2000 at 07:37:20 AM EST

Pascal had P-code, Emacs has E-lisp... lots of people have done the interpreted-byte-code thing.

However, Infocom definitely made it more fun! So did Sierra, for that matter, and there are some free AGI and SCI interpreters out there... :)

"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
you just speak to applets (4.00 / 1) (#76)
by mulvaney on Fri Oct 20, 2000 at 01:14:37 PM EST

I think that most of your points are well taken as far as java applets are concerned. Your complaints about java seem to boil down to these:

1. Speed

This has been refuted by others. The speed issue is a red herring. Java has a bad start up time, no one will argue with that, but if you think that java is otherwise slow then you probably haven't used it much lately.

2. "bondage and discipline"

From these arguments I gather that you are a perl programmer. While perl is useful for quick scripts, and if written carefully can be used for much more, Java is a whole different beast althogether. It comes down to which paradigm you want to use. If you want to do object oriented programming, you use Java. If you want to do procedural programming with an object-like interface, you can use perl.

3. "other tools are better"

This is perfectly valid, but it depends on the program you are writing. I've never done any animation stuff for the web, but it seems like shockwave is much more popular than Java applets. Personally, I wouldn't write an applet unless I needed something that wasn't available in any other way. As to your specific examples:

a) shockwave style plugins

Agreed, these are often better than applets, but I don't have the experience to talk about it.

b) perl

(full disclosure: I program in both java and perl. Lately, I've been using a lot more java, but that is just because of the project I'm working on. They are far and away my two languages of choice, but I like to use them to hammer different nails.)

perl has the cross-platform thing down as well as java, but they don't force you into it in the same way. It is very easy to write non-portable code in perl. I don't see that as a huge advantage/disadvantage either way; probably because I don't see cross platform portability as a major selling point of java. to be sure, it is nice, but I think that java has a lot more going for it than that.

One problem with perl is that it is very easy to outgrow yourself. It is great for doing simple things simply, and it can make hard things easier. But one of the hardest things is to write maintainable code, and this is something that perl doesn't make any easier.

c) javascript

I don't think that javascript competes with java very much. I think the point you are making is "javascript-enabled forms" vs. applets. I try to use html enhanced with Javascript as much as possible, as they are much faster for the user than an applet. I think the only time that an applet is better is when you need a richer graphical control than the basic HTML form elements provide.

d) C/C++

C is great for drivers and such, but it doesn't compete with Java. C++ is very close to Java, and I think a lot of people would go either way on that one. If one was clearly superior, it would be the standard. But I think while there are different advantages to each, it comes down to personal preference.

Java's advantages are, primarily, ease of use. You seem to disagree, but most developers who spent any time with Java and C++ would say that their efficiency went up dramatically with Java. The primary reason is usually the automatic garbage collection, but I think another reason is that the Java language encourages developers to make better design decisions.


[ Parent ]
Python, maybe? (none / 0) (#100)
by psicE on Sun Oct 22, 2000 at 09:44:38 AM EST

Sounds like you mean Python? #'s 1, 3, 4, 6, and 7 all fit it perfectly. Obviously #2 and #5 are only possible with assembly^H^H^H^H^H^H^H^H C or C++, but you can write Python modules in those two languages and use your Python code as bindings if time is really of the essence.

As for #8, of course Flash is easier, it's solely for graphics. I haven't seen many sites that use Java for graphics anymore... Can you name one?

http://www.python.org, in case you've never heard of it before. Waaaaaaaaaay too easy considering what you can do with it. 20-line webserver. :) And it has built-in object-orientation, but it's not mandatory (thank god).

[ Parent ]
A major advantage: the libraries (4.33 / 3) (#68)
by cwong on Thu Oct 19, 2000 at 09:45:46 PM EST

I have not seem mentioned one of the main advantages of Java that I really appreciate: the presence of a large and somewhat complete library. Consider what comes standard with the language. Out of the box, you have classes for i18n, string handling, date&time handling, file I/O, network, threading, IPC, database access, collection classes and GUI programming. With other languages, you could get the same thing from third parties, but they would not be standard. This is another form of portability: programmer portability. A Java programmer can move to another Java project in another company and still have the same standard, extensive library he worked with before. He would be instantly productive.

I disagree that slowness is an issue with Java today. With Hotspot and JITs everywhere, Java is already pretty fast even on slower machines. My main problem with Java implementations is bloat. While the platform has made great progress with speed, it still has a large memory footprint and startup time.

I suggest that direct memory access is unnecessary for most applications. Apart from that sort of pseudo-pointer you get with references, do you generally need more? Part of what makes Java programming a pleasure for me is not having to second-guess the "inside" of the program. With C/C++, memory corruption is easy and causes wierd program behavior. A corrupted stack could cause a crash upon returning from a function call, for example, or an array overrun could change the value of a variable somewhere. All that and memory leaks are absent from Java, leaving me free to concentrate on the logic of the application itself.

Pointers vs. Addresses (none / 0) (#77)
by Parity on Fri Oct 20, 2000 at 01:53:52 PM EST

Being able to explicitly create and manipulate pointers is a very useful thing; they don't (unless you're doing -very- low level work) need to be real memory addresses, nor do they need to be able to be operated upon in the addition/subtraction sense. More to the point, it would be nice if the language had a syntax such that,
A <assign> B always assigns by value, A <assignref> B sets a 'pointer to' or assigns a 'reference to', and invoking
f(A) always passed by either value or reference and f(<signifier> A) always passed by the other. Or maybe it would be more Javalike to have the type of A determine the action of the assign operator and the specification of f() determine the manner of passing of A. Anyway. I'm sure there are ways to do whatever you want, but really, pointers are confusing enough without making them sometimes-but-not-other-times implicit in the language and never explicit. Why add obscurity and take away tools?

[ Parent ]
..but not... (none / 0) (#101)
by WWWWolf on Sun Oct 22, 2000 at 03:53:36 PM EST

Out of the box, you have classes for i18n, string handling, date&time handling, file I/O, network, threading, IPC, database access, collection classes and GUI programming.

But no equivalent of curses.h... Grrr. Or qsort(), for that matter.

Granted, Java library is decent and fairly compherensive, but today, here, now, I'm stuck without the ability set terminal to raw mode...

I like Java in general, but when it doesn't do the job, it can be a pain in the neck.

-- Weyfour WWWWolf, a lupine technomancer from the cold north...

[ Parent ]
Why Java? (4.66 / 3) (#70)
by Nishi-no-wan on Fri Oct 20, 2000 at 01:00:31 AM EST

Many have commented about the cross platform angle being a both a blessing and a burdon. As for me, to comes down to this:

I can develop on the platform of my choice (FreeBSD) and distribute on the platform of the users' choice (most often M$).

Note, I develop servlets. I'd still be rather hesitant to develop a Swing application for "real" use. I do write "throw away" utilities every now and then for personal use, though.

Nonetheless, with this setup, I'm happy, the user is happy.

Ah, the simple pleasures in life.

Swinging for the stars

usage of java (none / 0) (#104)
by mnf999 on Wed Nov 01, 2000 at 07:32:30 PM EST

this is a first post on k5... I came here believing the level was better than on slashdot but I see that the trolls are the same here.

java's usage in the industry is today dominant, IT development (today the bastion of "fancy" web software dev (corba, ejb/j2ee)) is dominated by java (j2ee, by Gartner group).

But I guess a bunch of kids in .edu know better and think it is cool to troll about C and semi knowledge on kernel hacking...

Sorry about the flame, I am fresh from /. and am still trigger happy.

Why (not) Java? | 104 comments (93 topical, 11 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!