Slashdot Mirror
Why Linux Lovers Jilt Java
BrightIce writes: "The Java Developer Journal has an interesting article about Java in the Linux world. It tries to explain why the Linux folks dislike Java, what the future might bring regarding M$, C# and Java, about Sun and Microsoft, and Java and Embedded Linux." I know why I hate it: it takes too.long.to.get.to.my.method(half, of, the, time); and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders." (oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here too, even tho that is definitely fair use). Other than that, my only problem with Java is that the VM in Netscape is crap. Oh, and their licensing. And the fact that it's bloated. And the fact that I don't have enough time to type in all the reasons it irritated me *grin*
This shows the disadvantage of writing "C/C++", as if C and C++ were the same language.
Strings are one of the ways in which C and C++ differ. C typically represents strings as null-terminated arrays of characters; C++, however, represents strings using the std::string class. (Or, if you want to be pedantic, the std::basic_string class template.) In C++, it is important to distinguish between strings and string literals.
See Koenig and Moo's Accelerated C++ for a nice introductory discussion.
Giving him some credit, it IS possible that he is refering to the generated accessor methods which are necessary to allow inner classes to access private variables of the outer class. These are impossible to access from Java, but nothing stops you from getting at them if you write your own bytecode.
But if that is his point, he could use a course or two in expository writing.
Before you say "Use JNI, it's the VM not java", let me explain to you why you have your head up your ass.
I'm not saying "use JNI" because then I would be sacrificing portability so YOU take your head out of YOUR ass and stop putting words in my mouth and then giving counter claims to stuff I've never said. Very poor manners!
I'm pretty sure he was refering to API bloat, which you *could* argue is there.. Memory overhead is not really an issue, however, and you can get memory much cheaper than you can get coders to write the same stuff in C so that it would save a couple of megs of ram. Besides, you can optimize very well for size in Java too by not using heavy weight stuff like String objects for everything. If you plan on using a lot of strings, roll your own 8-bit string containers and write a separate handler class for it to minimize overhead for methods in the string container class. Just because you're not programming in assembly doesn't mean you have to - to quote you - have your head up your ass when you make design decisions.
It is a "True OO" language. It's is a "High Level" language. The higher level the language, and the more OO the language, the slower it runs and the more memory it takes up. That's a FACT.
Yes, you are very right there. There doesn't have to be a huge overhead in OO (as opposed to using structs with function pointers for instance) but the way you write an OO app usually means that you have a lot of method calls going on from object to object. If you want to write a very fast and also size optimized Java app, you can do it the same way you would in C. Yes it will be slower. Yes it will eat more RAM. But it will most probably also be fast and small enough, unless you're coding an OS, a game or a web browser.
As an obvious starting point, garbage collection. It's very nice and you can be lazy about keeping track of your objects, but it causes overhead.
Ah, you might think it's obvious and a big overhead, but it's not. First of all, garbage collection happens much more rarely than people think and it doesn't take nearly as long as people often think. In a large application, gc is more efficient than manual malloc & free. Why? Because complex apps have complex object life cycles that you have to track yourself if you have no gc. You might have references to memory from several places in an app with several threads and it's not easy to know when something can be freed. Having a *good* gc implementation do the work for you allows you to focus more on your own code. In many systems, you will find very gc-like structures for stuff like exception handling, with pointers pushed on a stack that is then cleaned up when you leave a method early due to an exception. Gc is much more convenient and not a big overhead at all. By re-using objects, you can also minimize (almost to zero in many cases) how often gc is called. That is, unless you have your head up your ass.
No crashes, no speed issues, no Netscape VM's.
Yes, I'd have to agree with that, but no Netscape, no life for most Unix-based people. Sad but true, because there is no practical alternative to Netscape as our window on the online world, yet. I guess you must be using Winblows to get around that problem, but we're not sufficiently masochistic to do that. Better to drop any prospect of using Java instead, and that is exactly what hoards of Unix/Linux/BSD people have done.
It's a pity that Java gets blamed for something that isn't the language's fault, but that's life. If you want it to change, either get the existing Netscape Java developers replaced by people that admit that there's a problem and will take less than 5 years to fix it, or else find us an alternative browser that really works, not a toy.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
The rest of my posting still seems to hold some truth :-)
Computers make very fast, very accurate mistakes
of course, i'm completely biased, as i work for the company (Vita Nuova) that distributes it. it's not as bad as it might seem though, because the only reason i went for this job was that i'd already fallen in love with the language! but seriously, Limbo is a truly excellent language which, like Java, takes much of its heritage from C but, unlike Java, gets the fundamental language design right.
i know that Java is here to stay, but if you've done much Java programming, you'll know that there are reasons why you might want to keep an eye on alternatives. Limbo is a language that C programmers will like but C++ programmers will probably hate. there's no object-hierarchy! so you actually know what code is being invoked by a function call. debugging code does not require an intimate knowledge of obscure class hierarchies.
o it's completely type-safe. unlike java, it's impossible to get a run-time type exception.
o the syntax is very readable, but terse enough not to frustrate a C programmer...
o the type system is rich enough to make data-structures easy to create and manipulate, and the type syntax is beautifully clear. consider:
x: list of array of (string, int);
o memory management is automatic (garbage collected) but unlike most other GC languages, memory usage is economical and predictable, because almost all data structures are collected by reference counting. so when memory is tight, you have tight control on what memory is allocated, and when it's freed.
o and best of all, programs written in Limbo are completely portable, because they're surrounded by an entire virtual operating system, Inferno.
i could rant on for ages about nice aspects of the system, which is not surprising, given the people involved in its creation (Rob Pike and Dennis Ritchie amongst others).
anyway, we've had a free download available for some time, but our resident Windows-head has just come up with an Internet Explorer plug-in that runs Inferno inside a web page. the download is under 720K.
we've had fun coming up with a few demo programs so you can see how it performs compared to Java and what a typical Limbo program looks like. you can even even get a shell prompt inside IE. (not that you can do a lot from it, as it's sandboxed...).
have fun! and bear in mind that the binaries of these programs will run unchanged under any incarnation of inferno... the "applet" API is identical to the normal one.
i hope that at least some people will Get It...
cheers, rog.
PS. i'm sorry we don't have a linux or netscape version, but we will have!
So you're saying that you could not have completed the project in 20 years' time? In that time we've gone from MS-DOS to Linux under Enlightenment under GNOME. Java might be great, but it ain't that great.
Good luck on your release. You're right, though--I'll be shying away from it because I distrust Java. Es tut mir leid.
Hmm.. I'm guessing you say 'P' because it is the next letter in BCPL?
... B evolved into C, which should evolve into P, and finally into L (or C+=2 :) )
-----
On the good side I really like the design of Swing. Sure it's slow and buggy, but it's nicely designed and powerful.
Many people mentioned IBM's VisualAge for Java and their 1.3 JVM for Linux - these are great products.
For embedded space, don't forget about their VisualAge Micro Edition as well - you can try it at http://www.embedded.oti.com This is developed by the Object Technology Inc. subsidiary of IBM. They have a VM available something like 20 platforms including Palm.
There's even a version of the VisualAge Micro Edition IDE for Linux as well, which runs very fast, especially when you take into account that it is running on top of the JVM itself.
> you want a language that has every convenience built directly into the language? use BASIC. :6
:-( My employer MADE ME! Boo-hoo-hoo...
I do, though not by choice
This is a name-space issue. It solves a fundamental problem with C, and helps alleviate the same problem in C++.
:)
In C, if I were to arbitrarly include packages off the net into my app, there is a chance that two packages will define and export the function named 'foo'. Even in C++, you can produce non-class functions.. The general rule, however is to put all package functions scoped inside the class as static methods.
If C were designed like C++, then you wouldn't have printf at all, you'd have
System::IO::printf(...)
You still can make that function if you are sufficiently paranoid.
Java simply said that they weren't going to allow ANY main-scoped functions, so nobody could be lazy about abusing the name-space.
I'm not advocating java here.. Just defending Packages (since I love them in Perl.
-Michael
-Michael
Are you sure about this? Last time I checked, both GCC and VC++ did exactly this. Besides, it's not the compiler that runs the macros, it is the preprocessor. The preprocessor doesn't know anything about C syntax, and is in fact just a simple macro language tacked on to every C implementation, I've never seen a C preprocessor that understood C++ comments before, and in most of them you can even be burned by:
/* Some comments that are
#define foo bar
too long to fit on a line */
Maybe the preprocessor has gotten better recently and I've just never noticed because I avoid comments on lines with macros like the plague?
I read the internet for the articles.
Linux users don't like Java?
I don't know if that's true. But they certainly have an opinion about it: this is the most discusted news since the Florida election results.
There are ways around this, such as the "restrict" keyword being added to C99 and template metaprogramming, but the issues still remain.
Ok, so I wish it had a bit stronger type system, perhaps a-la Bruce's LOOM, which allows you to express covariant types. This is needed because the method Animal::eat(Food) can't be overriden by Cow::eat(Grass) in Java's type system (where Grass is a subclass of Food).
Appart from that, tho, what exactly is your beef with Java the language (as opposed to the various implementations floating around)?
Which features did you have in mind?
OK, here goes:
import java.io.*;
public class HelloLine
{
public HelloLine()
{
try{
System.out.println("What is your name?");
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String inputString = br.readLine();
System.out.println("Hello, "+inputString);
}catch(IOException e){System.out.println(e.toString());}
}
public static void main(String args[])
{
new HelloLine();
}
}
How friendly it is: Having never done this specific problem before, I looked up the readers in the JavaDocs and knocked this out in about 10 minutes. Took me longer to post than to type. I guess I understand your complaint against System.in. No, they don't expect anyone to use System.in. That's why there are readers that take an InputStream and let you do some higher level operations on it. Read the JavaDocs and find the proper reader for what you want to do.
All of you Java-haters, are you creating code on your own, or using an IDE? Or do you just hate applets because they crash netscape? I have never seen an IDE that 1. generates Pure Java code (they all use their own class wrapper stuff that REALLY makes the code ugly). and 2. Creates even somewhat attractive code. These statements are from someone who had to evaluate the big 4 IDEs for my old job. We recommeneded emacs.
Planning to be moderated ± 1: Bad Pun.
hah! love the sig, American Movie is fucking hilarious.
A have to say I don't think you know what you are talking about.
First off, you are mixing up the notions of OO and "High-Level". I presume by "High-Level" you mean a "High-Level" of abstraction. It is quite possible to have an OO language which provides very little abstraction (you could take a subset of C++ and call it an OO language, and it's certainly not that high level).
"Garbage Collection" is probably not the right term to use either. What you're talking about here is automatic memory management. There is not necessarily overhead in automatic memory management, and certain techniques for automatic memory manage can reduce overhead substancially.
Good OO programming can actually significantly reduce the size of a program. Java has been used in embedded environments for this precise reason. By reusing code you save a lot of space.
Sure, assembler code can achieve essentially anything that is possible in software because it is a form of expressing the exact instructions you are sending to the processor. That being said, in the real world, you don't have an infinite amount of time to optimize your code. You have a fixed amount of time, and as a consequence your assembler programming team is usually going to get it's butt kicked. C compilers have been outperforming hand assembly for quite a while now, and Java is certainly capable of the same feat. It's just a matter of time.
Java's real overhead comes from the VM. There's a signifcant amount of overhead in that. Now, in some projects, the relative overhead of the VM is puny, and so Java proves to be an exceptionally efficient language. In others, the VM is 10x the size of what you'd expect the whole program to consume. There you are screwed.
For specific tasks, C (which is considered pretty low level by most) has been beaten by APL, Lisp, Self, Smalltalk, and yes... even Java. It just depends on how well the people writing the software for these different languages tuned it for specific operations. If you are working at a low enough level, you can do that for yourself, which is a nice advantage in some situations. Unfortunately, the price you pay the rest of the time consumes more than enough of your time that you'll never have a chance to do that optimization.
sigs are a waste of space
No, you can't. At least you can't compile the output. First you need to do a "grep -v '#line' on the output first. Of course, this makes debugging much harder since it's not possible to get a correct line-number for the error anymore. Besides, the C preprocessor ain't that great either, because it's not really that powerful. Mainly, (1) not being Turing-equivalent, and (2) not knowing anything about C syntax are the idiocies that's knocking me off.
To cope with (1), I've been toying with the idea of using eRuby as a replacement for cpp and general language-independent preprocessor in my projects, but since I've been busy doing other things than C programming lately and the other languages I use doesn't have much use for that, I haven't got any real experiences yet.
On the other hand, I have seen some preprocessors for java that seems pretty darn nice (not that I have used them much, I personally can't stand java myself either). Here I should probably have some URL's handy, but that is not possible because I'm to lazy to look them up, and if you are really interested, you can find them yourselves.
Well, that's a problem with a conditional branch, but a goto is an unconditional branch. You should be able to place that code in memory right after the goto, if desired, especially if you're doing any run-time profiling.
:)
At a low level, I'd say an if statement would be more bothersome than a goto; also, a lot of times even a regular ol' compiler could do loop unrolling...
But yes, that is a fascinating aspect of it, IMO; it probably isn't a huge issue in Java, though. When Java's that close to the hardware, I'll be quite happy for them!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Order of includes is tricky? Usually you include what you need, and if they need anything, they include it for themselves, and they don't include it twice...
:)
When would order matter?
Also, I haven't messed with win32, but would that be like using AWT *and* Swing? Even if you could do it, why would you want to? Actually, scratch that, that's my opinion of win32 coding anyhow!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Just to clear up a few things:
1) The head-up-ass remark was not meant as a direct response to the parent of the message I posted but as a general remark to those who claim that java native compilers are the work of god and solve all of java's speed/size problems. I just meant to point out that there is more to the bloat and just VM overhead, it is the nature of the language and can't be cured by a compiler. The comment I replied to was very sensible and I meant the poster no insult. I apologize if you took it personally.
2) I'm not confusing OO with High-Level. You are correct in the rest of your post though. Java is both. And both OO and High-Level tend to lead to larger memory footprints and slower execution.
High level does this simply because of the abstraction and some of the things that this entails.
OO does this, atleast in java's case, because you tend to write lots of little classes with lots of little methods with a whole lot of inter-communication. It is the same as the difference between a monolithic kernel and a microkernel. The microkernel may be better organized, easier to maintain and such, but there is a performance and a memory hit associated with said flexibility.
3) I am not stating that any of this is a BAD thing. It's great. I am not the biggest fan of java as a language, but of higher-level more abstract languages, I am a huge proponent. All of this new found processor speed has to go somewhere and I say it should go to adding more and more levels of abstraction to make software development as well as software use easier and easier. Java IS a good language, and it IS bloated relative to C, as it should be, and that's NOT a bad thing.
Justin Dubs
I argue that Java's support of things like real interfaces and simple memory management, and its lack of support of things like macro processing and global functions, encourage good object-oriented design.
No, no, no! As long as implementation means writing source code, IDE's will be nothing but glorified editors and build/run shells. Some are prettier or more convenient than others, but none affect whether you can produce a nicely designed and implemented application. (Unless of course by application, you mean a dog and pony show GUI that you could whip out in VB in ten minutes.)Use whatever IDE you thinks sucks least, or just use vi and make.
Disclaimer #1: I haven't touched Smalltalk in 15 years. Maybe it's neat too.
Disclaimer #2: If down-to-the-metal performance is more important than support of good design, then use C or assembler.
Disclaimer #3: Java is not perfect. Some things, like its definition of protected, are just broken, IMHO.
"Rub her feet." -- L.L.
sprintf(), snprintf().
sprintf(text, "Count = %d", Count);
PS.
My 2 cents on all this...
Java is a RAD tool, C is a programming language.
Development in Java is development in Java. If you do it right (meaning don't setLayout(null)), it'll work.
I don't understand this. Can somebody explain?
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Goto has lot's of valid uses. First, it's great for program-generated programs. Second, it is sometimes a convenient and very clean way to avoid carrying around one or more boolean variables around in deeply nested if's and while's. Third, it's sometimes useful as a performance-hack. Fourth, there are lot's of reasons I probably haven't thought about yet, but there is no reason to outlaw something just because you don't like it!
>I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders".
Maybe you should have called it Taco Invaders
Then again, maybe not... That sounds an aweful lot like the title of a Pr0n movie.
Java code, which is why I've shunned it, is ugly because it's bloated. The actual code is, not talking about run time. It's rather stupid that you should have to set up a stream to avoid System.out.println. Java just looks silly to me. It's supposed to be a programming language, not something that resembles english.. (class blah extends blahblah)
Dacels Jewelers can't be trusted.
The Java implementation in *every* modern browser, be it Netscape, IE, or anything else, is either so horribly broken or outdated (or both) that it's not worth seriously programming for. Use the Java plugin instead; it's fast and works with every browser out there (Win32, Solaris, and Linux included), except on Macs. It's a small download for users, and in this age of Flash animations everywhere, a little plugin download doesn't really turn people away.
http://java.sun.com/j2se/1.3.0_01/jre/index.html
Thanks for the tip on 'quiz them first to make them feel bad' - I feel more like a BOFH already.
Years ago, people programed computers by rearraning pluggable wire connections.
Years later, we had machine code, them ASM, then started to get more functional languages like Fortran, Cobal, C, etc. Now we seem to be moving into OO languages with Java, Smalltalk, C++, etc. (let's forget how *pure* they are).
The same thing has happened with OS's and programs. People are becoming removed from the hardware. More layers are being inserted inbetween.
Both of those things are OK because memory keeps getting cheaper and computers keep getting faster. This enables us to force the computer to do more work so the numan has to do less. That goes for using the computer, programming the computer, assembling the computer (anyone remember the pre-PnP days?)
So, I argue that the fact that Java is slower isn't a bad thing. It's faster development at the cost of runtime speed, just like Justin Dubs said. The older technologies will probably never die out (Lego Mindstorms uses pluggable wires of sorts), but they will no longer be mainstream.
Who knows what the future holds?
Actually, that's not inefficiency at all, which is my point
What I meant by inefficiency was the fact that the compiler can't optimize aggressively at the goto target, because it can't predict the processor state. You have to explicitly flush the register file and reload at the target instruction. (like a mini context switch, say; that would be pretty bad...;)
Just junk food for thought...
i disagree. the java socket interface is not abstracted enough. it's still tied to TCP/IP. plan 9 and inferno have the cleanest networking interface i've seen.
want to make a connection?
connection := sys->dial("tcp!slashdot.org!httpd");
that's all! the address is a string with a protocol explicitly mentioned, so can easily be passed in dynamically as an argument. the program itself is protocol independent. if i had an ATM interface, i could use "atm!someATMaddress!56446" and the program would continue to work unchanged. IPV6? no problem, just change the underlying implementation...
not to mention the fact that access is through a filesystem-like abstraction - the actual network interface might not even be on the local machine...
On the whole we don't fare much better or worse than the rest of the Western World. You don't really get a choice of where you want to be born, and that's likely to be the same country you live in for the rest of your life.
(end comment) */ }
(end comment) */ }
[an error occurred while processing this directive]
well you see the thing about java is it's already obsolete, look at all the other tools we have today. if only it wasn't adopted so universally, we could get rid of it entirely.
Why the hell does sun care if slashdot uses the java symbol thingy? And java invaders is cool. what the hell is up with sun?
Sanchi
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
"Sun will port [the new jvm] to popular platforms other than Solaris and Windows just as soon as they find any". This is the kind of arrogance that keeps 'em down. Personally, I trust IBM more with java than I do Sun.... (Visual Age, jikes anyone?)
I never have Java on, even in Windows or MacOS. I've found it to be the source of at least half the crashes in Netscape, and that isn't tolerable, for someone who is using Netscape every day of the week.
On the other hand, Javascript I find at least marginally useful, and so it gets left on unless I run into a page that repeatedly crashes my browser.
--
Matthew Walker
My DNA is Y2K compliant
Matthew Walker
http://www.tweeterdiet.com/ - My Diet Tracking Tool
Java on Linux started out as a reverse-engineering effort and a barely tolerated port.
Then there was the Sun/Inprise JDK and the poor way Sun initially acknowledged the contributions of the Blackdown folks.
Java on Linux will be taken seriously by the ISV community when Sun starts supporting Linux seriously.
The problem is that it can be difficult in a large program to ascertain which areas will need the optimization. Sometimes it's relatively obvious. Programming with some view towards efficient implementation and optimizing are distinct operations. Optimizing in and of itself isn't a problem. It's engineers who spend lots of cycles worrying about optimizing algorithms they haven't written yet. Once it's been demonstrated that an algorithm works (as in, it's been implemented and run against data), some profiling has been done and it's actually necessary to spend spare cycles examining performance then optimizing is worthwhile. Never optimize if you don't need to, it's useless work and there's plenty of shit that actually needs to be worried about on a decent sized programming project.
On the other hand if you're designing a db and you have performance requirements then your job is to design it efficiently.
Essentially, I'm lazy, the less code I have to write, test and optimize the more I get to read and think and avoid the carpal tunnel.
It shows a really deep lack of understanding of java and what it can/cannot do... As for thinking that "the VM in Netscape is crap" as the extent of your interaction with java then you have some serious shortcomings in your thinking. Java is so much more than just applets running in a browser - if all the articles in the JDJ haven't shown you that, then what have you been getting that magazine for (assuming you have a subscription...)??? In terms of server side development and deployment, java is the main workhorse out there. period. At my current place of employment, we've developed a whole secondary lending instruments trading/auction system. It includes a java gui (which has run beautifully on each platform we've tried it on), EJBs using weblogic and ariba meanwhile talking to C++ and C programs to handle the feeds from Reuters and Bloomberg and make pricing comparisons based on these. We developed a communications protocol to handle the transmission of data between the different processes running and even communicating with an AI engine to perform data uploading etc... All of this was accomplished with two java engineers, one C++ engineer, one C engineer and one LISP engineer. Some of the beauty of java has been the development on other platforms and deployment on other platforms without changing a line of code... The EJBs were initially developed on NT (windows 2000) and then ported over to both Solaris and HP-UX - without changing a line of the EJBs... As I mentioned earlier, the GUI has been a breeze (using JDK 1.3) and we've tried it on several different platforms (including MaxOS X) - and again, everything ran great - the only problem was that I lost the ability to use our skins feature on the MacOS X for some reason that I'm still debugging)...
I believe Java on Linux has failed to catch fire since it requires some serious programming. It isn't as easy as writing a simple little perl script to do something - which is usually what most Linux folks expect - and it requires some serious software engineering since you can't just tack in pieces ad hoc (like say in perl where you can just call someone else's script and you build from that)...
Sorry to be inflammatory, but it really raises my hackles to see someone dump on a technology without first reviewing what the technology can do (which is what I perceived from the author's writing). Is Java overhyped? Yes - but in its defense, it does do some incredible things that M$ has still never gotten running completely. Will it solve the world's software woes? No - we're still decades away from that golden software tool, but it does get us closer to solving the problem of platform independent software development.
Coming from a someone who has writting software on Macs, NTs, Solaris, HP-UX using C++, LISP and Java...
peace. JOe...
peace. JOe...
The Linux community hates big binaries. Every time a piece of commercial software is talked about on /., the size of the binary gets mentioned, usually to complain how bloated it is (Wordperfect or Applixware anyone?). The same holds for free code too. You'll never read comments on a Mozilla posting without its size being mentioned by someone. Conversely, we love to mention how small the Linux kernel is compared to Windows.
And Java is BIG. My Jdk1.3 install is 187mb. You could probably install a minimal linux distribution in less space.
As for portability, Java is only as portable as its VM. Having autoconf and being able to ./configure; make; make install on any Unix-like system is a lot easier than Java, which allways seems ad-hoc and painful.
Things might change some with gcc3.0, which will probably have gcj (native java compiler) integrated in. That way, at least the startup times are small, and you won't even know your running a program written in Java.
It's pretty obvious that Python is the Next Big Thing. Anyone wanting to work in CS in the future is studying Python now.
making JAVA look good:
--GTK/Swing--
GTK/Swing is a Swing PLAF to make Java applications comply with the default look and feel of GTK+ and GNOME.
http://gtkswing.sourceforge.net/
--SkinLF--
SkinLF provides a skin system for Java programs.
supports GTK and KDE themes format
http://www.L2FProd.com/
Ok, well, my favorite solution is to write a method in to each of my classes for debugging. The code I use is:
static boolean debug = true;
static void Debug(String debugtext)
{
if (debug)
{
System.out.println(debugtext);
}
}
This way, I can write:
debug("This is a test");
In my code and when I'm done debugging, set the static debug to false.
Please try this at home!
-marick
heh, "write once, test everywhere" has been an unofficial slogan for Java since approximately 8 minutes after the official "write one, run everywhere" slogan was first voiced.
Having said that, I've written distributed systems using Java and CORBA where I've taken the compiled bytecode in compressed jar format and used ftp to transfer it from a windows box to a HP/UX box - and it's worked first time no problems. It can be done, and the majority of code doesn't even need any thought put into retaining cross-platform capability.
Most areas where cross-platform and cross-JVM abilities are lost are due to programmer laziness - using typed in strings instead of JVM specific constants (for things like path separators).
~Cederic
Say that to a smalltalk programmer. Java forces nothing of the sort. Besides string handling, it does force fairly strong typing (except for the ability to cast, which I'd trade in a minute for good Standard ML style dynamic strong typing, or even a templating system). But that isn't the same as forcing OO. If you have method overloading, and if operators are mapped onto methods, it becomes perfectly OO to have overloaded operators.
If you want constrained programming, go try to do some heavy I/O in a pure functional language.
oops... that should read: static void debug(String debugtext)... Java is case sensitive, I know... (that's what I get for not previewing) -marick
As already been pointed out, the person replying to you gave bad Java code. One can't extend Java's String class. But, your need for polymorphism, etc and way for an object to print itself is already built into Java.
;)
The class Object contains a method called toString() which returns a String. Since all Java classes extend (inherit) from Object, they all have this method. Granted, the default String returned isn't that useful so one simply overrides the toString() method in their class declaration.
With this in mind, a programmer can easily send output to any stream. I'll keep it simple and use System.out:
..
Vector aVector = new Vector();
..
for(Enumeration e = aVector.getElements(); e.hasMoreElements();)
System.out.println(e.nextElement());
That simple code snippet allows one to loop through a vector and print the objects no matter what they are. This is a simple and trivial example.
Since apparently you nor the person trying to extend the String class know Java, a little hint about the above code.. e.nextElement() returns an Object.
I think a lot of the differences in the exception models reflect the differences in philosophy behind the various languages. Smalltalk is very much a late-binding environment, deferring as many decisions as possible until run time, sometimes not making the decisions at all. Java does a small amount of late binding, but it is, for the most part, early binding, trying to make almost all decisions at compile time.
Smalltalk assumes that, hey, if the exception is important, someone, somewhere will catch it, otherwise, it will recover and continue. Java will throw up its hands and say,"OK, I got an exception, no one caught it, you're fscked!", but the compiler will try to prevent you from writing code that gets you in that position in the first place.
Perl is for system administration tasks, not full blown "Applications".
And on what basis do you make this sweeping statement. Back it up, and don't resort to the lame excuse "because its butt ugly". List your reasons and experience and then sign your post or go away.
It lacks any mechanism for non-blocking I/O, forcing you to use threads to handle multiple incoming connections on a server.
C/C++ have non-blocking I/O and select() which allow handling of multiple connections in one thread/process without a problem.
This is impossible in Java (you will block on a socket that has no data, starving a connection that does have data ready).
Considering that the average programmer is not savvy enough to write threaded programs correctly (without races/deadlocks), I would hardly call Java's network interface incredible in this respect.
No, it creates a StringBuffer object, initialises it with "Count = " and performs an implicit call to the append(int) method.
So go check the easily accessible always available API and it tells you what happens.
If you want it in hex or whatever instead of base 10, then it's time to dive into the java.text package, which - hey, would you believe it - provides a collection of classes designed to correctly format strings for you.
Maybe I'm odd, I've needed to output a number in hex once in the last 3 years of Java coding..
~Cederic
The new class must polymorphically substitute for more than one of the concrete base classes. This is extremely rare, providing you have done a good job of object modeling.
I suppose this is the root of the issue. The reason I disagree is that is impossible to ensure that you NEVER have to polymorphically substitute a new derived class for a concrete base class.
You create your concrete base class, which derives from any number of interfaces (abstract base / interface) and life is good.
Then one day, you need to extend the functionality of the base class to handle some new requirements. The other classes which operate on the base class type, are OK, and do not need to be touched.
What do you do?
aggregating the concrete base class in not an option, because your new class will not work with any of the other afore mentioned objects which operate on the concrete base class type.
You could reimplement the concrete class, inheriting from all the same interfaces, and aggregate the concrete base class, but this would be cumbersome. You would have to forward requests to your member aggregate concrete base class, and you would have to refactor any objects which previously used the concrete base class type.
If you use multiple inheritance, you simply derive from the existing concrete base, override the methods you need to customize, and your set.
You can argue that such a scenario will almost never occur, you will always use objects by interface, and not by a base class, but I disagree. You can say that good design would have prevented this, in most cases it would, but this situation will and does occur regardless.
When a scenario like this does occur, it is diffucult to solve in Java, while multiple inheritance in C++ is much easier by comparison.
type conversions probably account for 30% of all modern software bugs....
knowing if there is a type problem at compile-time is essential...
fool...
I don't think anybody has accused Java of being weakly typed or even typeless. But there's no reason why it shouldn't perform automatic type conversions when the context is unambiguous. Even C/C++ is smart enough to automaticaly cast integers up and down (though it will usually give you a warning), but its smarts stop at strings.
This article seems to contradict itself about halfway through. Primarily, it is saying you should worry about performance, and to not worry about it would be "lazy". Then in the middle it says the "wrong kind of programmer" writes "obscure code" for performance reasons. Afterward he continues to stress that imperative run issues such as linear searches and refetches are not performance issues!!
This is a very strange statement, especially considering the fact that the entire database industry has spent the past 40 years trying to perfect imperative search procedures to reduce search times. This IS a performance issue. Furthermore, stating that the VM makes refetch times "away to nothing", does not make it true that the this newly optimized refetch is any faster than C++-native optimization for refetches. The fact is that C++ affords you a multi-level programming paradigm from which to write powerful programs that communicate intimately with machine architecture. While at the same time affording a "lazy" programmer the ability to write an entirely insular OOP making use of all the features that an object-oriented language such as Java or the experimental Smalltalk has(d) to offer.
I find Java to be an extremely well thought-out and well-laid out programming language. In fact, its object model is clearly a superior demonstration of the capabilities of the object-oriented paradigm. Then there is the wonderful feature of portability, and let's not forget all those babysitting-features like buffer-overrun catches. However, it remains true that while Java is an interesting and novel exercise in the field of object-oriented design, its performance on a single machine is seriously compromised when compared to native-compiles. Saying that since Java forces you to structure your program a certain way, it makes you a better programmer is not a very strong assertion. In several fields, optimizing performance is the primary issue, producing a "correct", bug-free algorithm is not often relevant or even possible (e.g. Operating Systems). It is to this end that I say that while Java affords one to be more idealistic in programming, C++ is still the dominant solution-provider affording programmers enough flexibility and functionality to make use of the cutting-edge hardware which is wasted by Java's sluggishness. The C++ programmer, is right baby.
The performance issue is pretty much a dead one, and I have the suspicion that those who use that as an argument for why Java totally sucks haven't been exposed to Java as it's implemented today, and the kinds of apps that are built with it. I also doubt that they're aware of how much its used.
I do have one gripe about Java that seems to be legit, and that's that it is very verbose, and things can get weird, especially when it comes to things like iterating through lists. That being said, there are some nice advantages to the verbosity of Java, which is that people who are new to a prject can hit the ground running easier when the project is using Java than say, C++ where individual coding styles can really interfere with your learning curve.- ---------------
-----------------------------------------
I bent my wookie
-------------------------------------------------
I bent my wookie
I agree with most of your statement, like I said, not a good example, but I hoped it would show what I was trying to convey.
The point where I disagree is in multiple components aggregated into a larger component, instead of multiple inheritance.
Once you aggregate an object, it is now un accessible for future derivation. In most cases this is fine, in some it is not.
If you have a base class that does most of what you want, yet you want to customize a few operations, you have a few options:
- Derive from the base class and override the methods you want to customize further.
- Encapsulate the base class, and wrap the methods you want to customize (breaks type compatibility)
- Re-implement the base class and write the methods you want customized differently (waste of effort and duplicate code).
Granted, this is not your everyday scenario, but it does happen. My point is that when situation like this do occur, multiple inheritance is a good solution (not the only one, but a good one). The other possibilities may or may not be hard to implement, or all that difficult.
OK, I'll admit I'm relatively new to Java, and I haven't fully investigated reflection. I did see the FAQ, but that told me it was meant for debuggers and I probably shouldn't use it. If it's a commonly-accepted Java idiom, I'll have another look.
I'm ranting after an extremely frustrating day's Java (and to be fair much of the frustration was caused by the class libraries and Sun and MS's implementations rather than the language itself).
I honestly do like a lot about how Java works - I'm not using it because I have to - but some seemingly trivial things end up covered with unsightly kludgematter, making the code harder to read. The tutorials and docs give little advice along the lines of "this is how you'd normally do thing X from other languages that's a bit tricky in Java", unfortunately.
Java's not unique in having threading, standard dbi, networking and compiled bytecode, either...
--
This comment was brought to you by And Clover.
You hit the nail on the head. Just look at all the syntax errors in the stuff people are complaining about. I mean, stdin.readline()??? Nope. I was getting revved up to reply to everyone who made a derogatory comment with code as backup, but almost all of them are blatently wrong that it is obvious they do not understand the intricacies of Java.
Hey taco: import to.long.to.get.to.* and be quiet. Fair use? From the license: "You acknowledge and agree as between you and Sun that Sun owns the Java trademark and all Java-related trademarks, service marks, logos and other brand designations including the Coffee Cup logo and Duke logo ("Java Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at www.sun.com/policies/trademarks."
Wow, I'm usually in a good mood on Fridays.
Planning to be moderated ± 1: Bad Pun.
Interesting idea...but if I understand it correctly whatever implements the interface would still have to manually call the inner class methods, right?
Yes. Anything you want the inner class to handle would have to me forwarded to it via a method invocation. So for one operation on a concrete class, it would then perform a second invocation on its inner class to actually get the job done. Then pass back any returned value as well.
Data hiding is NOT crap. Without data hiding, anybody who uses your linked list can mess up the list for everybody else who wants to use the list. That's a bad thing. With data hiding you can make sure everybody only accesses the data in the linked list through your official methods.
OOP is in fact designed to model real-world items. Real objects have a bunch of attributes and a bunch of operations that can be performed on them. So do OOP objects. That means for business programming it's supremely useful. For writing assemblers, compilers, or scientific applications it's not as good. However, the features of OOP attempt to promote code that is both maintainable, by breaking code into smaller modules, and robust, through things like data hiding. Whether they do or not is left up to the programmer and the language designer.
In Java, you can write a main program that looks like this:
import a.whole.lot.of.junk.*;
public static void main(String args[])
{
Database myDatabase = new Database();
PayrollManager payroll = new PayrollManager();
myDatabase.readRecords();
myDatabase.updateRecords("firingList", "hiringList");
myDatabase.writeRecords(); payroll.issueChecks(myDatabase);
}
Assuming those classes are defined well enough, you can write a main program that looks like pseudocode and have it work. In fact, you can basically write pseudocode for as many levels as the design dictates, then switch to C-style programming for the basic operations, as long as you give things proper names. If you call methods a, b, c, d, e, etc. of course the code won't be readable.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Yeah, but all that work wasn't done by one programmer and assorted student helpers. The relevant metric is programmer time, not calendar time.
How long do you think it would take you personally to implement your own threading model, your own GUI, and your own CORBA-like remote method call system with support for distributed garbage collection? And to get it to work on Windows, UNIX, Macintosh, and OS/2?
As it is, Ganymede is almost a quarter million lines of useful, relevant code. Portability and high level class libraries aside, the Java language is so safe to work with that something of that scale is reasonably tractable for a single competent programmer to manage, and that was my point.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Win95 -- Recompile
Win2000 -- Recompile
Solaris -- Recompile
Some other flavor of Solaris -- Recompile
Linux -- Recompile
OS/2 -- Recompile
BeOS -- Recompile
...
catch the trend here?
Or even P. Two-and-twenty points to whomever gets that reference first:-)
Many of the people designing and developing Java have been deeply involved in Lisp and Smalltalk for decades (in addition to many Objective-C/NeXT and Taligent developers). And that shows. Many of the Java libraries are excellent, based on many years of experience in those other environments. And the current Sun Java implementation is very powerful, with generational garbage collection, dynamic code generation, sandboxing, and a host of other features. Smalltalk and Lisp runtimes never reached that level of completeness and sophistication.
Java continues the tradition of the Smalltalk and Lisp communities. What distinguishes it is that it adds a lot of features that make it suitable for mainstream and "industrial strength" use, and that's why it has succeeded where Smalltalk and Lisp haven't. When I'm by myself, I still like programming in Smalltalk or Lisp better because they "get in the way less". But maximum comfort is not the main goal of an industrial programming language, and for an industrial programming language, Java is the best compromise around as far as I'm concerned.
You mention IBM's VisualAge for Java being the only non-pathetic IDE for Java out there.
I've had a lot of experience with many Java IDE's (a little bit with a lot of different ones), but I concur. It's also worth mentioning that IBM's VA/Java was written in Smalltalk. IBM decided that Java wasn't a robust enough language to write a reflective, interactive environment in. In all fairness, I've heard that VA/J 3.0 has parts rewritten in Java.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Notice how Java developers never spend months on end porting software from one platform to another...? Also, sun has been considering completely opening up it's already fairly flexible API to the Public Domain (don't know what type of liscense though), enabling developers to continue to improve the language. Also, Java is a much easier to learn language than C++, and it is much more logical than C as well. Did I mention that it's extremely portable?
-----------------------------------------
Perversely greped and groped by PowerPenguin
You don't use public getX/setX (i.e. accessor) methods for everything. You probably should use getX/setX methods for everything (unless it's read-only in which case dump the setX) but change their accessibility of those methods to private, protected or default if they shouldn't be public.
But they should exist, and they should be used - doing that from the very start greatly increases the maintainability of your code, and oh, btw, adds in useful hooks for when you want to trace or breakpoint people setting those values.
As for "fascist standards" - in a business environment standards are essential if you want more than one person to work on any piece of code. Which, invariably, you do. One thing I love about Java is that no matter who has written the code, how many spaces they want to indent, where they put the curly braces, whatever their own personal cosmetic preferences, because everybody follows the Sun naming conventions I find it exceedingly easy to follow program flow and determine what type of call is being made where - is it an object, a method, a local variable, etc. And I've read the code of probably over a hundred different developers writing in Java.
Btw, the "Java API" is fantastic. I find myself constantly amazed with the simplicity and elegance of much of the design. There are some grotesque areas (don't ask me about date handling) but the majority of both the core APIs and the extensions (Swing, security, messaging, RMI, etc) are extremely well designed using solid principles and patterns.
~Cederic
>Swing sucks. AWT sucks. GTK+ should have Java hooks (now that Sun is a GNOME backer.) I cannot get an App that doesn't look like ass.
Get some decent Swing apps like Gnutella or jEdit. Use a decent VM. They look great.
And they look great on Win32, Linux, Solaris, Irix, HP-UX, Tru64 Unix, OS/2, Macintosh, some IBM OS's I never heard of, you name it.
>Slugishness. Java gets its ass kicked by C in speed.
No, it doesn't. Read the article Binaries vs Byte-Codes.
On the other points that you mentioned, some other replies dealt with them or I don't have a quick link at hand. You're generalizing a lot. Redundancy in Integer.parseInt - that's a problem? It's a class method, and there are class methods for other types in java.lang.Integer. No redundancy here.
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
As I understand it, multiple inheritance makes code less maintainable. In fact, in many cases, multiple inheritance is used for API reuse anyway, and Java interfaces do this just fine for me.
- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.
Yes, this is a problem.
Of course, most people don't even realize that you can write your own garbage collector (and JIT compiler, for that matter) and plug it in at run-time to the 1.3 JVM. This makes a lot of sense for people writing complex memory-intensive Java code, that's for sure.
Of course, it would be much better if there was some kind of profiling memory manager that would learn good memory management for a class as it is used in some environment. I think TowerJ's static Java compiler does this.
-marick
Now come on.
#include "me.h"
#include "ma.h"
isn't the same as
#include "ma.h"
#include "me.h"
that's elementary, check out your textbooks!
Get some decent Swing apps like Gnutella or jEdit.
I meant the Gnutella client FURI.
so you are saying, you asked the instructor in CLASS, why have setter and getters for all properties ? How is this different from just making the property public ?
And he marked you down ?!
if that was the case, your instructor may not be playing with a full deck. And that ain't Java's fault.
Woe be on to them, all who rise against poor people, shall perish in a the end. Buju Banton
> The fact that Perl support some OOP principles doesn't make Perl "OO". Hell, even Matlab is being advertized as being OO... I even have had arguments with people who say C is an OO language.
You are correct, but I'd like to make a point:
You can use OO principles in almost any language. It's just how well the language supports it.
Proof: Remember cfront compiled early C++ into C. Did that mean C supported OO? Well, no, not natively, but with enough work you could do OO in C.
Java, Perl, and Lisp, have their place, but their paradigms (OO, etc) aren't the end-all-and-be-all silver bullet. Use the right tool for the job.
The author of the piece in question implies that even Linux servers don't actually run Java. Huh? He claims that the Java is run on the client. Huh? Where has this guy been? Client-side Java has been eschewed by many corporations (mostly wrongly imho) for some time now. Servlets run on the server. Many organizations mandate that all server side business logic is written in Java for portability. Linux boxen are perfectly happy (with some gotchas in the current Linux Java implementations occassionally) running all of this Java code.
The talk of Linux on the desktop is just talk? Yeah, right. That's why I threw Windoze off my 3 home machines and went totally to Linux. Percentage wise there isn't a big shift yet. But let the Office tools (the GPL version of Star Office for instance) develop a bit and you may see a very different story.
Embedded folk don't like Java? Is the author ignoring the tiny device level Java offerings? Is he ignoring Java enabled cell-phones, PDA, toasters and so on?
The author also misses one huge reason that many geeks don't care for Java. It is the same thing that sells it so well to executives. The Sun overhype. We don't appreciate hype very much. We could care less about Java branded versions of all our known and trusted tools just to have the Java brand on them. It is tiresome reading tech docs on Java offerings that every few pages extol the virtues of Java while ignoring that many of those virtues have been around for a couple of decades (at least) in other environments. I get tired of Sun reinventing the wheel and calling it wonderful . I get tired of seeing Sun reinvent or just write a (closed-source!) API for something already present instead of bothering to interoperate with other language solutions. CORBA support was an afterthought it seems. Most of all I dislike the sheer mindless wordiness of Java. I can't capture half the patterns in projects within the strict little boundaries of the language. In terms of useability when programming Java is somewhere between C++ and Pascal in my opinion with a few good advanced features like garbage collection and some (but not nearly enough) reflection.
> Java is a RAD tool, C is a programming language.
Huh? A RAD tool is an IDE environment coupled to a programming language. Just because a tool is RAD doesn't imply some sort of lightweight or less-serious underlying programming language. See Delphi. Or C++Builder.
In writing apps for call control, the hardware used uses a bus for the voice data. All the software does is transfer sound files to the hardware when needed and provide call control, i.e. connect this line to this trunk.
The fact that it is Java-based has absolutely nothing to do with the scalability of the server application. I have written a highly scalable call processing application using C++. It can handle as many ports as are addressable by the hardware (assuming the processor/memory is sufficient). This app is handing 16 lines, about 2500 calls per day, using a PPro 200 with 64MB RAM (NT 4.0). In testing, I put 64 lines on the same box, and had no difficulty with it. If I wanted this to be scalable (so that calls could be connected from one to the other), I would have to write SOFTWARE that would run on both boxes and pass calls and data between each other, probably over TCP/IP. This is NOT a Java function. This is a application function. If I were to "plug in another box" for the job, install the same hardware, and run Linux on it, it would not work, because the hardware does not have Linux drivers (yet).
Furthermore, debugging being 5x harder than Java is bunk. I've debugged Java software. And what does it take to write software that is scalable? Give me a break! Software checks for hardware, creates a thread for each hardware port, threads take over their own port. Messaging is done between threads through a queue in the main thread. All done. That's why I am able to extend my app to provide other services, such as DISA-type outcalling and call forwarding to a list of numbers dialed simultaneously.
Oh, and while I'm bragging, I wrote this app in my spare time at home, to fill a need the company didn't yet know even existed. Now they are asking for all kinds of new features and buying me the dream hardware (Voicebridge cards, Dialogic cards, new backplanes, etc).
Hello little man. I will destroy you!
There are many reasons... the most obvious one is that multiple inheritance forbids certain things...
Say I've got a class A with method "doIt" and then, a pure virtual class B with method "doIt" and suppose then that I want class C to derive A and "implement" B...
C: public A, public B
that gets complicated... doesn't it? In general you can't inherit from two classes defining the same method... it's a mess...
In Java, it is clean and simple, you don't even think twice about it.
public class MyStupidString extends java.lang.String
public void print(String message)
{
}
Yes, but what about those of us who don't write code with bugs? What do we need all that extra crap for?
--
Bush's assertion: there ought to be limits to freedom
High-level languages are not always slower than assembly. For specific tasks, tuned high-level language compilers have more optimization hints. Plus "hand tuned" assembly isn't always optimal, especially across various Intel hardware.
"Ada Whips Assembly"
With the intent of getting an Ada waiver, a defense contractor wrote a portion of its software in Ada to prove that Ada could not produce real time code. The expectation was that the resultant machine code would to be too large to be effective for a communications application. However, the opposite was verified. After minor optimization, Ada compiled smaller and faster than assembly.
cpeterso
Comparing Java to Mozart, a standard consumer-producer multithreaded application running within:
The same processor:
Java execution time 17.6 seconds
Mozart execution time 3.9 seconds
Java code 72 lines
Mozart code 24 lines
Distributed processors:
Java execution time 1 hour
Mozart execution time 8.0 seconds
Java code 168 lines
Mozart code 30 lines
Seastead this.
import java.lang.system.*;
out.println("This does work.");
Frankly, I pretty much never work with system.out as I usually declare my own input/output streams connected to various other sources like sockets and StringWriters as the concept of being able to see the console just doesn't happen much.
Frums
Code crunching BigNums is very frustrating to write without operator overloading.
You're kidding- Java doesn't have operator overloading? I never programmed much in Java (ran through a tutorial or two), but I suppose I assumed it did. Ouch.
Then there's Smalltalk, where there's no need for operator overloading, because "operators," as you know them in C/C++ do not exist (well, the assign operator ":=" I suppose does), you simply define methods with names like -, *, and %. Your example of "s = (k - x*r) % q;" would be very easy to do, whether it be with integers (big, small, positive, negative, doesn't matter) or floating point numbers. Perhaps you should give it a look.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Note that it's System Out, not Standard Out, so unlike whatever C varient you are talking about, there is no assumption that you have a universal teletype emulator dangling off the emulated serial port that your program is talking to.
So, now you want the String class to know the details about whatever system-dependant output device that you may or may not (some Mac VMs for example) have, instead of the much easier proposition of the virutal output device knowing about strings.
Nah - given java's assumptions, your idea is br0ken. Let the goatse guy file it away for future reference
I've been working Java for about 3 months now. It's write once, debug everywhere. The Java langauge itself is a hell of a lot better than C/C++ (I've been a C/C++ programmer for 15 years). The OO concepts are cleanly implemented, if you can get past that com.name.space.verbosity. The JVM mess that's out there is horrible. You write your code once and then work around bugs in all the different JVM's you can get your hands on. Ugh! Disgusting. Totally defeats the original motto of Java.
I used to wonder what was so holy about a silent night, now I have a child.
The point where I disagree is in multiple components aggregated into a larger component, instead of multiple inheritance.
I didn't actually argue in favor of aggregation, but rather the basic OO principle that how an object behaves is more important than what an object is. With most popular OO languages it is true that in order to share the code behind common behavior, you must use some form of inheritance or aggregation. That is not a rule, however, and OO languages exist that do not tightly couple methods with classes; some even allow instance-level method definitions.
Once you aggregate an object, it is now un accessible for future derivation.
The class that is formed by either MI or aggregation is stuck with the classes it subsumes. I'm not seeing a weakness for aggregation here, but rather the standard "weak base class" issue.
If you have a base class that does most of what you want, yet you want to customize a few operations, you have a few options:
Most OO languages with a proper runtime will also allow you to insert your own method (re)definitions, which may also be a suitable option. Also, aggregation of a base class may have inheritance issues ("breaks type compatibility", as you say), but proper OO design would have you looking at an object's behavior when working with it, not its type. And as far as re-implementation efforts go, you have to weigh the cost of maintaining the extra code against the cost of maintaining a broken design. I've had projects that leaned both ways, so there's no one answer there.
I agree. But when would it matter?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
ML server pages project
ML Server Pages (MSP) is a web scripting language, a loose integration of Standard ML (SML) and HTML in the style of Sun's Java Server Pages, Microsoft's Active Server Pages, or PHP.
So far we have designed and implemented a usable proof-of-concept system, based on Moscow ML and the Apache webserver. Current goals are to obtain more experience with applications, and to improve efficiency, scalability, security, and functionality of the implementation.
The talk will present MSP script examples, details of the implementation, and ideas for future work. Feed-back on the design is most welcome.
cpeterso
-No multiple inheritance: There are cases where multiple inheritance can be nice, but for the most part it is a highly overrated. Most languages that DO implement multiple inheritance do it in such a way that it's a bad idea to use it regardless. For the most part, aggregation is actually much prettier than multiple inheritance.
- There tons of VMs out there which do not have the problems you describe for memory management. In particular, for real-time OS's this doesn't happen, and with Java's real-time extensions it's even easier to avoid this problem. Even the stock JDK 1.3 VM does most of it's GC in a background thread, and if that isn't good enough for you then you can enable incremental GC (and again, this does ad some latency, but if that's a problem, you should be using the real-time extensions). You mention incrememntal GC below (although you misunderstand how it works... there are still sweeps going on), so I don't know how you can complain.
- Having to call the finalize method of the base class makes a lot of sense. If you don't get this you obviously haven't done a lot of OO development. It's very consistent with the notion that the constructor for an object must call the constructor of it's super class.
sigs are a waste of space
Objects are nice but I've become disillusioned about OOP as some sort of software design holy grail. OOP requires a degree of formalization which scatterbrains like me don't want to deal with in certain applications. I'm a big fan of Scheme and LISP myself, and I rather like Perl (icky syntax, but great concepts). These languages enable you to cobble together an aggregate data structure in function A and pass it to function B, and so long as function B knows what function A is talking about, everything is cool. In Java you have to formalize your structures as objects and, once you have done so, any changes to the structure made in A must not only be reflected in B but also in the formalization. It may not seem like much overhead, but the time consumed in program maintenance really adds up.
I wish I could like Java more than I do. But it is a language designed by, and for, C++ weenies, with a few cool new features added and most of the advantages of C++ removed. It's like C++ with training wheels. It's a neat language, but its primary function in the grand scope of things is in education, and in thrusting the VM idea into the spotlight.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Ah :)
--
Never underestimate the relief of true separation of Religion and State.
Now, if we're talking about what constitutes object oriented programming I'll buy that there's a definition, but OO programming need not slow your program (see Gtk+, which is very fast and very OO, but not in an OO language).
An OO language need not be inefficient, but modern language design favors highly inefficient constructs (e.g. garbage collection) to efficient alternatives that are less flexible (e.g. simple reference counting).
C++, for example, was an OO language beforeRTTI was added. RTTI just made it higher level.
I don't think that OO programming is well suited to a great many tasks. Functional programming, IMHO, should be the default. However, some tasks are much easier and cleaner when an OO model is used.
Choose the right tool for the task.
For starters, I can't imagine an implimentation of Hello World that would take a single clock cycle to run. What did you have in mind?Second, try:
That should produce a pretty reasonable ~22-line assembly program which you could have written by hand in about 5 minutes.In C, I could write:
int main()
{
Database *myDatabase;
myDatabase = (Database *)malloc(sizeof(Database));
readRecords(myDatabase);
updateRecords(myDatabase, "firingList", "hiringList");
writeRecords(myDatabase);
issueChecks(myDatabase);
}
(No, I wouldn't do it that way ... but you could. In fact, with one or two minor changes -- changing the declarations to call constructor functions and changing hte main declaration -- your Java code would've compiled under C as it was.) But well-written C code does, in fact, read nearly as easily as pseudocode. (In fact, I find my bad transcription of your Java code to make more sense than the original. Tell me: does your database actually read records? Of course not: the program reads records and puts them into a database. The readRecords and company functions have no business being part of a database object.) In readability, I don't think that Java has anything on C.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
I *like* the syntactic sugar of operator overloading. Sure it can be abused, but I'm an adult dammit, let ME make the decision. And aparently the authors of Java think operator overloading is cool too, seeing as how the "+" operator works for the String class (nothing like hard-coded special cases, huh? :-)
:-)
I also love my destructors. Oh well. So much for having really nice clean concise code that doesn't require users of it to constantly remember to call close() methods in every case (requiring lots of try/finallys so that exception handling doesn't screw up and leave resources hanging when an exception is thrown).
But that being said, I think Java does make a lot of improvements over C++ so it's not like I'm horribly partisan one way or the other. It's just that giving up my guard classes, destructors, arbitrary scoping, type-parameterizaition (templates) and operator overloads is kinda a high price to pay sometimes for better error handling and exceptions, garbage collection (sorry, but memory leakes were never a huge problem for me, though I know they are for so many others), interfaces, and those wonderful class libraries (the C++ standard library sucks, imho).
Eh, you win some, you lose some, and everything is a trade-off...
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
I ment how it doesn't permit the declaration of functions independant of class as C++ does. Its not a major thing, just a minor irritation for me. I have no real problems with Java, other than a feeling that some of the limitations on the language are unnecessary. I prefer C and C++, but I'm willing to use Java for some things. I'm even enjoying using it (some bits have very pleasing syntax) for CS this year.
-RickHunter
In the speed department, I've written Java code that was 0-10% the speed of comperable C code. In the memory department, it depends on the size of the app. If the app is big enough the footprint of the JVM becomes negligable.
;-) to hook into C++. I'd argue that even in the C++ world, IIOP is about the easist way for C++ code compiled with one compiler can hook into C++ code compiled with another compiler, so you can't blame Java for that.
JNI is a pretty good and easy way to hook in the C code. IIOP is a pretty good way (notice I didn't use easy
sigs are a waste of space
I don't they naturally are, though, any more than an integer or a boolean is. They're values, and passing them around shouldn't require you to write glue classes; it just makes programs longer and more difficult to read.
Java is perhaps to be applauded for avoiding many of the problems other languages have differentiating a value and an object by having very few things that are values, but it makes programming slower. And String is still a bit confusing in that it's an object you can write as a literal, and isn't mutable.
Well, for every possible tuple I might want, yes. Do I really want a directory full of Custard$ResultFromABCMethod.class, Custard$ResultFromXYZMethod.class, Custard$ResultFromABCButWithAnExtraBoolean.class? I'm more likely to kludge it, I think, using private member fields as result passing. Or your casting solution which I guess would work quite well if I could escape my casting phobia. :-)
I wanted two timers to call back my class at different intervals. Obviously they'd both call the same method, so I wouldn't be able to tell between them without writing extra glue classes. It's also true when you want to call a single method in another class (where you can't change that to be the relevant Listener).
Well, the first few exceptions I stumbled across were MalformedURLException and InterruptedException. I know the URL isn't malformed because I made it myself; if this happens, I'd like the exception to bubble up to the interpreter and cause it to quit. InterruptedException should do the same. Why do I need to trouble myself writing code to handle these?
You're right; I ended up surrounding all my exceptable method calls with a try { ... } catch (SomeException e) { throw new RuntimeException("There was a SomeException"); }; this troubled me for readability reasons and because it was a hack I'd not seen documented anywhere as normal idiom. Put another way, why aren't most exceptions RuntimeExceptions? They all happen at run-time, don't they?
--
This comment was brought to you by And Clover.
Some C++ programmers even want to use private inheritance instead of aggregation!
Good point! If you find yourself with private inheritance, your doing something wrong. The only rational I can think of would be type preservation, but this would serve no purpose as you could not access the members of the preserved type.
At any rate, you brought up a major point. The majority of C++ coders misuse the langauge.
This is a major problem, and is related directly to the complexity of the C++ language itself.
However, this does not mean that all uses of multiple inheritance are misused or ill designed. In some cases, keyword SOME, it is very helpfull, and makes for a cleaner design and implementation.
*yawn* All languages are for all programmers, it depends on your need, C/C++ are for WHEN a programmer needs a hardcore language, Java does not suck, it depends on the application and the programmer.. as does ANY program, go away
Jeremy
No; I want the children to have access as well, just not anything else.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
What about Perl?
B uzzwordHere??
V B/DirectX/CSS/DOM/COM/GET/FUX'D++#::!! just to be a goddamn web developer (and remember, a Bachelor's in CS is highly preferred).
;-)
Seriously, other than the fact that Perl code tends to run slower (since its an interpreted language, I don't know if ASP or JSP are, because I haven't messed with them at all). Course, you can always compile Perl scripts if you bother to code them right.
I've been programming Perl for 5 years or so, and I've noticed a disturbing trend in the IT industry. Introductions of shit like ASP and JSP, which are damn near all but incomprehensible for all but uberhackers. Take Perl on the other hand, which has more documentation (not to mention modules) than you can shake a stick at. What exactly is my motivation to waste my time and energy learning ASP/JSP/Java/XML/C#/AddYourFavoriteTrendyLanguage
Oh yes, because the PHB's at the dot coms are hopelessly addicted to industry buzzwords. Oh please. Java was a good idea (write once, run anywhere), but that only works if wherever you want to run your Java program actually supports Java. Thats a bit like saying that I can expect my Perl scripts to run on any system that has a perl interpreter (which, I might add, is damn near all the systems I can think of, with the exception of the flaky Win32 port).
Maybe I'm just set in my ways. When I first started learning HTML and Javascript (which was ALL you needed to know to make a website, back in the day), I dreamed of the day that I could do something I enjoy (creating a slick website), and actually get paid for it.
Course, now you need to know Java/ASP/C++/DHTML/XML/SQL/B2B/B2C/Oracle/Delphi/
And people wonder why the dot coms are going belly up. Sheesh. One teenage kid's dream crushed by the greedy corporate media whores. Thanks alot. I don't wanna be a web-developer anymore. I wish I wouldda stuck with basketball instead of squandering my teen years on IT.
I'd personally like to thank MS, Nutskrape/AOL/Time/Warner and Sun (to an extent) for providing a dozen useless languages and incompatible implementations that the PHB's can cream in their shorts over. Do we really need all this shit, when the vast majority of web browsers still receive (mostly) the same damn hypertext we've been getting for close to a decade? The more I read slashdot (and I have been for several years now), the more I am convinced that a disturbingly increasing faction of IT developers are also just people who get a hard on for using buzzwords when telling thier menial worker friends what they do.
But thats okay, because regardless of what some of you may think, while the internet, and its assorted development schemes aren't going to die off soon, I'd dare to bet that alot of web developers are going to find themselves looking for a major career change within the next decade... Like say, law. America loves lawyers. Didn't you watch the news today?
I realize I'm being a dick about it all, but c'mon... the point is all the great "breakthroughs" in web development in the last 5 years has meant precisely dick to me. Honestly there ain't a whole lot anyone can do with all those languages that I can't whip up faster with Perl/HTML/Javascript/CSS. So far as I can tell, this is about as cross platform as it gets. (does ASP/COM work on Linux? How many perl functions besides crypt() don't work on NT?)
I don't claim to be the best coder in the world, and I can't hold a candle to some of the Perl gurus, but still... About the only other useful web development application worth mentioning besides is PHP, which, coincidentally enough, I've stolen features from and implemented in perl for my own Fake-SSI perl-based rendering core. Sure, I could have just used PHP, but I didn't need everything PHP offered, and didn't consider the download to be worth my time... I'd rather do it in perl and learn something in the process.
The problem is the IT industry (generally speaking), wants an easy job, and to be perpetually pampered for doing it. I, on the other hand, picked up the languages I have because I wanted to learn something, not because some dumbass employer required I know how to do it.
<-- End Rant -->
Sorry about this bitchy ass post, but if I would have been just a little older when I did learn what I know, I'd be set for life. Tends to make one a bit bitter. I planned on leaving my blue collar job for a career in web-development, but, truth be told, I think my current co-workers are a lot more fun than a buncha technobabble speaking, self-righteous jerks who think they are hot shit cuz they know Java.
After all, the vast majority of people couldn't care less about what the hell it is you say or do. Time to step off your self-made pedestal boys. I know I have.
Oh yeah, and there is a reason there are very few hot chicks who work in IT... they are not impressed by buzzwords. If only us guys were that smart...
(and no, knowing Java, HTML, Bill Gates, or perl for that matter, is going to make a chick drop down and fondle your nerdmeat, either. Already tried that. And for pete's sake, lose the damn Nerf toys already
-One Pissed off former IT drone
What could possibly hurt the security of the American people more than giving our own government the ability to hide its
With that said, you'll definitely have to do a first-round thinking planning out performance, but implementing performance is something entirely different. That means that you plan to have caching and use efficient mechanisms to store complex data, such as implementing a good tree or hash strucutre. However, when you do your first round, you should not use caching and use a dumb array to get it done.
I can see what you're saying, but you're not quite distinguishing between the two.
Hmm, maybe it's so that the person writing the program doesn't all of a sudden find that a FooException crashed it because it was added in Version 1.1.5.3 and the program was written to comply to version 1.0.4.2? It makes sure that - oh no, you always know what exceptions might be coming!
;-)
exactly. This is one of my favorite Java features! The exception throws clause is part of that method's signature. Python can't do this because it supports lambda functions. The code can't know at runtime exactly which methods will be called by whom.
Of course, C++ exceptions are even worse.
cpeterso
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
Multiple inheritance reflects poor design. How can anything *be* two things at the same time?
Organizing things in classes and inheriting them represents a way of finite categorization.
- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.
A few good real-time garbage collectors have been written for Java. They guarantee not to interrupt interpretation for long periods
- The finalize method of dervied classes must explicitly call the finalize method of the base class. Why in the hell did they do this?
This is a misunderstanding from the C++ world. There are no destructor-concept in Java. You, as the programmer, don't need full control over when an object goes away. Just how it should behave. .close() and set the reference to null.
When you don't need your database connection anymore. Just call
I wrote my first "Hello World" Java application a few days ago. 10-line console application; straight out of Thinking Java.
It took about 5 seconds to compile, and 2.5 seconds to execute. It felt really slow to me (as I am used to Perl).
Config: AMD K3-2 300Mhz, Linux 2.2, Sun JDK 1.3
domc
Macintosh? Nonono. Apple did their own Java runtime environment (MRJ, the MacOS Runtime for Java). The only platforms that Sun actually supported in the past (and the only ones they'll continue to put serious energy into and not swipe, er, borrow from unpaid, free developers) are Windows and Solaris.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
But, your need for polymorphism, etc and way for an object to print itself is already built into Java.
Um, no. you're getting hung up on this one example and I'm trying to talk about the advantages of various object systems independent of particular classes. All you're saying is that you can get a string that describes an object; nothing fancy. I'm talking about actually adding a method to the string class that takes care of pushing it to stdout (let's not get into using other output streams, as that's a simple change to take an argument, of course). But, again, don't get hung up on the one example, instead think about the general advantage of simply extending classes by adding methods, without any need to do unnecessary subclassing (especially when it is not allowed).
Since apparently you nor the person trying to extend the String class know Java, a little hint about the above code..e.nextElement() returns an Object. ;)
Feel free to think I know nothing about Java, but here's a little hint for you: A collection should be able to tell its objects to perform a method without you having to enumerate through them all. Instead of drooling over Java, take a look at the utility of a broader selection of OO languages. You might not be so happy with how you've been spending your time.
What???!! Are you out of your mind? How can you say that a language that doesn't have explicit pointers or pass-by-reference, makes you use a class instead of a struct, and generally does nothing C++ can't do, while leaving out a hell of a lot that it can do is better than anything but INTERCAL? Java really is C++--.
... it's great. Java is ESPECIALLY useful on the server-side. You need to update your knowledge base here, I think.
Actually, everything in Java is pass-by-reference, really. You don't really need pointers (or think of it as 'everything is a reference', which while not completely true, is true enough for this discussion give you can easily wrap the atomic types like 'int' in a class).
And I prefer to think of Java as "C++ with C (and all the compromises and bastardizations associated with it) surgically removed. No printf(), no global functions without being associated with a class (i.e. forcing more pure OOP), etc.
I still don't know why they chose the 'final' keyword instead of 'const' -- since final seems to mean 'const' and it makes it just that much more difficult for a person to tranform from a C++ programmer to a java programmer... that's the one syntax/keyword I can NOT get used to. Yet.
Let me ask you one question. Why? As in why the hell would you ever use Java server side rather than Perl, or even better, PHP. Both Perl and PHP run perfectly fine on Linux. And as for being open, Perl is under the GPL, how much more open can you be?
Ever hear of Enterprise Java Beans? Running under an app server? This, in combination with the incredible class library, makes Java the best thing since sliced bread. Scalable, threaded, reusable, clear, concise, and powerful code that runs on many platforms (Solaris, NT, AIX, etc., etc)
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
> You're kidding- Java doesn't have operator
> overloading? I never programmed much in Java
> (ran through a tutorial or two), but I suppose I
> assumed it did. Ouch.
I always think that those advocating Java are really unfair. They say that operators are complicated concepts and so they shouldn't be in the language, but then they are developing it themselves. They say that templates are too complicated concept to support and so they shouldn't be in the language. But they are actively developing the generic keyword.
The words of Stroustrup might have some truth: every language extends to the complexity that the reality requires. Soon nobody can claim that Java is a simpler language than C++.
Yes, I do use Java: in fact, I teach Java. But I'm really tired of hearing completely unfair comments to its ancesters.
Why, then, should Java apps be expected to be massivley memory efficient when running in independent VMs?
The problem with many standalone desktop Java applications is that they are written with the assumption that they will be run independently of any other software aside from the VM and core Java libraries.
A perl IDE is kinda a condtradiction in itself. If you don't have the balls to write Perl (or any other language for that matter) in a text editor, how good of a coder are you, anyway?
Sheesh, the spoiled brats of the IT industry always want thier job done for them.
Speaking of crybabies...
What could possibly hurt the security of the American people more than giving our own government the ability to hide its
Because it is the best possible algorithm when the input contains 3 elements, and only 1 comparison off the best algorithm when the inpu contains 4. That cannot be said to, say, quick sort or merge sort.
By the same token, it might be cheaper in the long run to train your developers in on a better language, to enable them to develop software for even faster. You'd still have to upgrade your harware, but you'd most likely save money over both C++ and Java. I am, of course, talking about Smalltalk...
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I went into my first year of University knowing that I'd be taught Java. Already having a strong knowledge of C and C++, I agreed I should keep an open mind about it. Then the lecturers came in, zealots, preaching that OOP is the ONLY way you should program, and that it is applicable anywhere. The part that really pissed me off, was in a tutorial, they said we were to design the software to run on a coke machine. I questioned whether Java was suitable, and that a functional language would do a much quicker job. After 5 minutes of being yelled at by the tutor, I decided to concede and went about designing the most obfuscated coke machine I could, I created so many tiny insignificate objects. Guess who got top marks for their design? That's right. Me. Perhaps the problems with Java aren't the language, or Sun, or IBM, but the teachers of it. Cheers, leroy.
Yes, MI is lame for modeling. There just aren't that many "car-planes" in the real world, nor does the human brain resolve such unions easily. Since modeling is all about making the complex simple and understandable, MI is a poor tool for that purpose.
Nevertheless, when it comes to implmentation, MI is quite useful, and it's too bad that Java doesn't allow it. For example, see the cool stuff that the folks at Code Farms are doing:
MI can be especially handy in conjunction with generic programming, another thing that Java doesn't do well.
Easy, automatic testing for Perl.
- No multiple inheritance.
... memory allocations are WAY faster under Java, similar to stack allocations... so it evens out somewhat in heavily multithreaded applications).
.net platform) is lightening fast, using lots of optimizations so that a garbage collection event rarely lasts more than a couple of miliseconds. Anyway, I think this is a solvable problem.
Well, you have interfaces and aggrigation. Together you end up with all the same abilities (though admittedly with a bit more work), while avoiding a lot of the pitfalls and ambiguities. I really don't mind this (so far).
- Memory management.
Well, you can implement object pool patterns to drastically cut down on the amount of garbage collection, but you're right, this bothers me to for any time-critical problems or problems that require really predictable response. However, it's not nearly as big a problem as you might think given that there are simple ways around it (and think about how badly the heap is serialized on some systems using C++
Interestingly, Microsoft is claiming that the garbage collector they use for C# (and all other CLI langauges for their
The finalize stuff just always reminded me of an utter hack, and I can't stand any of it. You pretty much can't rely on it ever getting called, so you're forced to ensure your class users call 'close' methods and to really do everything there. Avoid using finalize whenever possible, I say. I'm still not convinced that the trade-off between destructors and garbage collection is really worth it, but I'm willing to keep an open mind on this and see how it turns out as I get more and more into Java.
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
well said. C's my 2nd favourite language. i used Objective-C for about 6 years and came across all the problems with its object model that i can see all too clearly in Java.
if you're interested in new languages, check out Limbo. IMHO it has all the simplicity and power that you're after, and its well designed semantics mean that programs are generally easy to debug and easy to maintain. the APIs are almost without exception very well designed and "as simple as possible without being too simple"...
it's a concurrent language and has a threading model that isn't based on archaic 1970s technology unlike Ja^H^Hsome other languages.
plus programs will run without change (unconditionally) on linux, bsd, plan 9, windows and on several native platforms (e.g. the Ipaq)
if you have access to a Windows system with internet explorer, there's plugin that allows you to play around with some demos (source code included), or you can download a version for another platform (only that one's 14MB, ouch).
it's a beautiful language, and that can't be said of many...
Apart from your java code being incorrect in the first place. You should know that you can't extend java.lang.String because it is marked as final.
It's not a stupid need, but rather a fundamental principle of OO design and implementation. It isn't just about this one little example, but how object libraries set an example of proper use. Why wasn't the String object set up to print in the first place? Why weren't all objects set up to print/describe themselves in a polymorphic manner? I won't even address the fact that you had to subclass the object to add the method, causing all sorts of inheritance/typing issues. Afterall, you still do have a string printing itself, you have a method hanging off a subclass that provides the ability to print a member of its superclass; an OO design that any competent developer should laugh at.
On the other hand, much of the bad rap Java gets on the client is partially, as you state, due to bad Java programming. Java GUI programming is entirely unlike GUI programming in any other language. It is in fact much, much more powerful. When you program Java like would program VisualBasic or PowerBuilder, however, you end up with a very slow GUI that does not behave as any normal user would expect. The reason is that a Java GUI demands to be multi-threaded. Any heavy processing or I/O should never occur as part of the handling of a GUI event. Then you need to remember to show the effects of your background processing only in the Java GUI thread. Any time you see a GUI failing to repaint itself, it is because the programmer has stupidly refused to spin something off in another thread. Any time you see it redrawing itself wrong, it is because the programmer updates the UI directly from a separate thread. Any any time you see a GUI freeze for moments at a time, it is because the programmer is trying to update the UI too many times rather than bundling up UI updates in one call.
Finally, the other bit is due to the Java IDE's. They are all horrible for GUI development and encourage bad UI programming. All of them.
Before reading this thread, I'd agree. But now I completely reject this concept.
Suppose somebody writes a library, and the library requires you to supply it an object, and will call it back when needed. Then the library is suddenly forced to know what exception that YOUR method will throw (but of course it doesn't)---or to say that it "throws Exception", or to force you to throw only unchecked exceptions.
Really, horrible design. I can imagine that this has to be done everywhere. Then why talk about checkable exceptions at all?
OTOH, writing efficient code right away saves enormous amount of time, especially when testing batch processes (I do a lot of it when writing SQL and PL/SQL code).
Putting some hints in the program took a couple of days (including the research), but execution time had shrunk from 3 hours to 20 minutes. It was sure worth it.
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
If you plan on using a lot of strings, roll your own 8-bit string containers and write a
separate handler class for it to minimize overhead for methods in the string container class.
Why on earth should I have to do this. I don't recall having to "roll my own" strings in C or C++.
Ok, show me one that does image manipulation without requiring a frame buffer device or virtual frame buffer daemon.
Actually, I think you'd want to throw a RuntimeException if you don't want to declare it in the throws, rather than an error, as that's supposed to be a fatal condition.
The author of the article was right about not hearing much about Java from the Linux developers, and that support isn't embedded. Personally I don't think it *should* be embedded. The beauty of the *nix systems is their modularity, not their inbreeding and tendrils of interdependence, ala WinXX.
Working for commercial shops, I can tell you from personal experience there is nothing more painful than trying to select a "common denominator" version of OS, JVM, Webserver, EJB server, and database servers, not to mention third-party products and TP monitors. If it weren't possible to modularize the support, it would be *impossible* to deploy production systems.
As a simple example, current EJB, JSP, and Servlets require JDK 1.2+. The web reporting tools we use only run with JDK 1.1.7+ (not 1.2.) If I were trying to deploy a production environment on NT systems, I'd have no choice but to use two boxes, because you can only have one system JVM. With *nix, I am not cursed by that restriction -- each tool just sets the PATH, LD_LIBRARY_PATH, and CLASSPATH to the versions it needs to run properly.
Our production systems aren't running Linux, but many developer boxes are. You won't see my cohorts out on the net raging about how great Java and Linux are together -- we're too busy working on serving our clients needs to bother arguing with the GPL fanatics.
I do not fail; I succeed at finding out what does not work.
For the record,
"Fair use" is a copyright conmcept, not a trademark concept.
As usual, Cmdr Taco displays his "amazing grasp" of intellectual property law.
import cmdr.taco.need.to.learn.how.to.import.from.*
packages
This is completely, utterly wrong. The following code compiles and works correctly:
#include <string>
#include <strstream>
string operator+(int i,string s) {
ostrstream convert;
convert << i << ends;
string i2 = convert.str();
delete [] convert.str();
return (i2+s);
}
string operator+(string s,int i) {
ostrstream convert;
convert << i << ends;
string i2 = convert.str();
delete [] convert.str();
return (s+i2);
}
int main(int argc, char** argv) {
string hello = "hello";
cout << "\"hello\"+1 " <<(hello+1) <<endl;
cout << "1+\"hello\" = " << (1+hello)<<endl;
}
The problem comes when you try to define operator+ for your custom CString class. If you try to define a binary operator for a class when the class isn't the first argument, you should get an error, since you're asking the compiler to call a member function on an integer. However, if you define the operator+ as a non-member function, you can put the arguments in any order you wish.
BTW, if you're using gcc-3, you'd use stringstream instead of strstream for the conversion. This would also keep you from having to explicitly delete[] the char* from the call to ostrstream::str().
Thank you sir, I think you just about summed up what I have to say about Java in the _nicest_ way possible ;-)
What could possibly hurt the security of the American people more than giving our own government the ability to hide its
Why is that a bad thing? Either don't throw exceptions from your callbacks, or use library methods that can handle the exception thrown. Anything less wouldn't be safe.
This might, in an indirect way, be the reason Java has been slow to catch on on Linux. Linux has it's own traditional support for web aps in CGI, Perl, and C. These work just fine on the Linux box on the developer's desk, and on the Linux box in the server room.
However, most of corporate America's big servers run a commercial Unix, while most of their developer desktops still belong to Bill. The the real "write once, run anywhere" is therefore "write and compile here, deploy there." And since server side programming doesn't use AWT or Swing, this really does work.
The moderation say much about the OTHER articles in slashdot these days
Care to back your statements up without resorting to AC?
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
But maybe this is the greatest problem: Java is not only for Linux. Maybe this is the problem with the ortodox Linux people: you can actually use Linux to develop an application, that will run elsewhere as well. Oh my! You may use Linux for development, and then you may use other platforms for deployment. Those that are maybe more scalable. Or simply: those, that are run by the company you work for. Or your clients.
And the other itch: it's not GPL. Those devils! But what is the problem with running non-GPL applications on Linux. Anyone has any problem with running Oracle on Linux, for example? Should they GPL it just because it runs on Linux as well?
And why is that, that Linux people just ignore the news that Sun is actually making an official JDK port for Linux? I see all rants and raves about how bad Sun treats Java on Linux. Well, it didn't support it less then other ports in the early days, and now they even have an official one. See: this is the third officially supported platform, and Linux people should be happy about it.
But maybe I am evil myself, as I see and use other platforms than Linux (and no, not M$).
It's just too damn hard to write obfuscated code!!
;)
You forgot to mention Borland's JBuilder, which is also an excellant IDE. Cafe is nice, too, if you prefer multi-window IDEs over MDI IDEs.
The great grandfather of IDEs works pretty well, too. (Emacs!)
I do not fail; I succeed at finding out what does not work.
Nope. It was late, and upon waking with a clear mind it was a really, really bad example. I was wrong on that count.
I stand by my case with Math.random(), however.
Java lovers keep saying that multiple inheritance is too complicated to implement. But just look at their library and see how the lack of multiple inheritance make the input output system a complete piece of crap.
:(
People keep on saying that interface is sufficient. Definitely. After all, you can always have a class and use aggregration, and pass everything to it manually. But then, if that is to be done everytime, why not make it into the language?
The C++ multiple inheritance really got its own share of problem. Namely, the only one who can decide that a base class is virtual actually don't really know whether it should be done that way. I'd be grateful if Java actually try to tackle that problem. They didn't. They just remove multiple inheritance altogether.
Now that Java has the super keyword, I think that's completely unfixable now.
+4 for this nonsense ??? :-(
Why should Sun care about Linux???
They don't owe you and don't make money from Linux. Their Windows version was pretty much a reference implementation (with significant portion like JIT compiler written by Symantec) to avoid relying on M$ that was just dreaming about screwing Java up. Solaris version (that was always behind) WAS NOT produced by Javasoft; it was a SunSoft implementation on top of the same reference implementation that every OEM was getting from JavaSoft thus being behind Windows version.
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
You did leave that AC loophole for a purpose - didn't ya? Stick to perl - sellout.
Java the IDE is pathetic except for IBM's VisualAge for Java which is almost as good as Smalltalk's IDE (VisualWorks, VisualAge for Smalltalk, Dolphin or even the late, lamented VisualWorksSmalltalk.)
Ever try Kawa? I've heard it's a decent Java IDE...
I personally love the VC++ IDE for C++ development, but that's just me. If J++ had actually taken off, I think it would have rocked to be able to use the MSDev IDE for all the languages I use or would ever want to use. Unfortunately, it's dead. Long live C#??
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
> If the same type appears as an ancestor more
> than once, should all or some of its data
> components be duplicated, or shared? If any are
> duplicated, how are they referenced
> unambiguously?
In pure OO terms, they need to be shared, and having them duplicated is just a performance consideration. But Java in general throw away performance consideration anyway, so it should be an easy choice---were the developers really want MI to be in.
> If the same-named (including same
> parameter/result profile) operation is inherited
> along two paths, how is the ambiguity resolved?
> Can you override each with different code? How
> do you refer to them later?
Why bother? If we have MI, most likely the code is called only from the code below, i.e. from the base class. And if it is called from the above, i.e. from the users of the class, you can easily specify what should happen by overriding the method in the subclass itself.
> I would think so that you could override it if
> you wanted.
Crazy. Should constructors not automatically chained "so that you can override it if you want"?!
- People who doesn't know Java!=Applet. Applet is a good way for Java to gain visibility and spread the word of "cross-platform". It's also the most trusted form of mobile code, so that's good too. But Java has moved on to real apps. And it has been successful (look at Sun stock!).
- people who writes low level system code (OS, database). True, Java's performance is not there yet. But who is to say it will not some day? And how many OS do we need anyway?
- people who hasn't written more than 100 line of Java code and is already criticizing it because it's not what they use to. They don't see the usefulness of having an "easy to program" and open language. They are blind.
- language purist. Sure, Java is not the perfect, let's improve it.
- people who has an "edge" over others because they have done so much "C/C++". This is roughly equivalent to the "old boys club" In Java, which is just as powerful but has a much lower programmer entry barrier, these people lose their advantage (because they know how to deallocate memory while most of the population don't). Any Joe Average can program Java! They think... And that is where they completely miss the big picture. Programming languages will be easier and easier to use, a larger and larger population will be computer and programming literate, therefore easier/more natural languages will allow more people to express what they want out of the machine faster.
mini mouse, have a fun weekendThat is the trend, it's irreversible. Adopt it or you will be obselete.
Well, yes, but you'll still need the C libraries for it; that'll take many cycles. I guess you could statically link it, but it'd be nice if gcc had a smarter linker. (300k???)
P.S. printf() is slow; use puts() or write() instead.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Oh, you have it all wrong!
;-)
With your logic, Sun has to develop Java for the NetBSD on StrongARM or other obscure platform. They behave fair (IMHO) by giving the reference implementation to any organization/body/vendor willing to port it. It is not their problem that the Open Source community can't do it. THEY DON'T OWE ANYONE!
As for your second argument, I can't understand it at all. What license fees do they get from Java Development Kit they give away for free, especially if it is for the operating system they don't sell and hardware they don't sell? OTOH, without decent Java on Linux they SELL some workstations (and they make the cheapest non-x86 workstations, IIRC - don't know about Alpha ones). I would guess IBM would make a JDK for Linux just to irritate Sun!
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
I should really dig out the old test question that I had to rewrite to use setters and getters, (although it was unspecified, and more complicated...) but I can tell you that I had an assignment where I implemented everything that was specified by the assignment, and used protected variables, and lost ten points for not using setter/getter methods of any sort.
Basically, if I can implement the spec for a program and have it run perfectly, and lose points for A(n unspecified, quiche-eating, useless, philosophical) CODING DIFFERENCE, well... then the instructor has some explaining to do.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Well, how about having a single function call with a descriptive name that performs a simple task like this?
How about open()? Or fopen()?
If you must, then file_open().
But Java avoids this entirely. They don't even have a macro^H^H^H^H^Hmethod that expands out to this, for when people want to do this simple task.
Why make it any harder than it has to be?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
What about "Python invaders"?
#!/usr/local/bin/python
import sys
import humor
if reader == "language zealot":
sys.exit(1)
else think_about_it:
try: Alien starships start on the top left side of the screen, then they start moving downwards and to the left with orderly tab movements!
except: that would be too easy to solve (too easy to understand, dammit!), so it would be better to run an Obfuscated-Perl invaders game...
"""docstring: This is not real Python code, just a simulation"""
No sig for the moment.
That's awesome!
Do you have the source available anywhere?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Uh, hello? C doesn't have strings. C has char arrays. Here, you can do the same in Java:
char[] myString = new char[40];
This is my point. If you say C strings don't take up as much space, I say: neither does C-like-char-array-strings in Java. Now calculate a hash-code for your C-string. What? Not so convenient anymore? For this reason, if you want convenience and the power of the unicode 16-bit string objects in Java, but the speed ans size of 8-bit char arrays in C, I suggest you roll your own string handler class that works much like strstr, strcpy etc. does in C, except it would be in Java. I bet 10000 people have already done this. I was merely saying that if you need speed and size, you can always do that. There's nothing inheritly big and memory hogging in the Java language itself. It's how you typically use it.
A little comment to my example above: I used char's, which are in fact what String objects are made of; 16-bit unicode chars. For C-like 8 bit chars, you would use "byte"'s...
I agree, slamming good sofware engineering practices on top of a inherently flawed language makes no sense. Which is why there are no IDEs for perl. People coding perl think they're uber hackers and consequently think they don't need an IDE. People coding IDEs, are good software engineers or at least understand some of the concepts of SE and generally don't use perl for the same reason.
I gather you are one of the new generation of legacy code generators. The previous generation used (and continues to use!) cobol. I repeat perl is for the swine!
Jilles
whoa,
Ruby looks cool, thanks for the link.
He who knows not, and knows he knows not is a wise man
printf"Java rules " . 2 ** 800 . "K\n";
perl -e 'fork||print for split//,"hahahaha"'
The java.lang.System class encapsulates the environment in which the application is being run. One property of that environment is an output stream called "standard output". This property becomes the class variable 'out', of type java.io.PrintStream.
You could add levels of indirection, and have a System.getCurrentSystem().getStandardOut(), but that'd change nothing but the amount you'd have to type.
Like all PrintStream objects, out has several overloaded println() methods that allow you to output data to the stream. PrintStream is just another subclass of java.io.OutputStream, which means you if you have a method with a signature public void printToStream(OutputStream out), then you could call printToStream(System.out) in exactly the same way you could call printToStream(new FileOutputStream(myFile))
Could you explain to me what part of this isn't OO?
Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.
Something is wrong in this article, I love Linux and I love Java, and that is absolutely true, I can assure you.
Then, "why linux lovers don't like Java" doesn't make any sense.
Really, it is not good to speak for such a large group as if all of us were the same.
Linux is attracting more and more people, some of us end up loving Linux but my reasons for loving Linux are different than yours. Even though we are together with Linux, we don't agree in many other things.
For good or bad, Linux is no more for a handful of computer enthusiasts, Linux users are now larger and diverse, and even you that were here from the begining should accept the facts, don't speak for the community at large, it doesn't make any sense.
hmmm, s/f//
perl -e 'fork||print for split//,"hahahaha"'
I think the gripe with long class/method names is as much about reading speed/clarity as writing speed.
perl -e 'fork||print for split//,"hahahaha"'
Yep, c/c++ is flexible, but the syntax is obscure to say the least. All the principles c/c++ advocate with nasty syntax can be used in Java in much the same way, but this time it's readable, clear and simple. And as opposed to what you might think, the learning curve is very very flat. Second year computer science students (who know allready one Wirthian OOP language, namely Oberon-2) can pick up the basics in 4,5 weeks, whereas they need at least one semester and a half to write c++ code in a decent way. I bet you don't believe this, but I'll come back to it in a minute..
:). First of all, template classes are dreadfull to code. If you look at the way the iostream hierarchy is set up, it's hard to read from the code how it works. Second, some compilers don't fully support them as they should. They require code to be included in the header, or they convert inline code to be static code alltogether. Thirdly, and this is a minor thing, the name "template" is quite awkwardly chosen. Ok fine, you'll say, but we need the concept of template classes, otherwise, how can we construct generic object behaviour. Well, Java solves this by treating everything as an Object (implicitly due to inheritance), and by allowing upcasting and downcasting of references to any kind of class-type, as long as inheritance permits it. This makes it possible to pass on various different kinds of objects of various extended class-types to a procedure, while the procedure parmeter list contains a base class-type reference. E.g. if I have a class Vector in Java which holds references to instances of the mother class-type of which any class is automatically derived, namely Object, I can assign to that kind of reference any other reference type that points to any kind of class instance, as long as it's derived from Object (which they all automatically are).. so you see, if you play it smart, you don't need template classes at all. Inheritance and the automatic Object hierarchy in Java do it for you. This is just one example of how the Java language has been build ingeniously, to accomodate all sorts of programming situations. C++, on the other hand, has has to drag in a great bunch of weird syntax to deal with this problem, and quite frankly it looks horrible. STL is ofcourse a very nice concept, but once you understand how Java goes about it and accomplisches the same thing, you'll start thinking differently about it. The only thing Java lacks, is operators and operator overloading. Well.. thankgod really.
.so's or libs that contain what's in header xxxx.h. It's much the same thing, but the JDK offers much much more than what you'll find in the c++ libs. Sure, programming can seem to be not nearly as fun as you don't jave to re-invent everything from scratch, but that's only an impression. The reality is that you now get time to do real funky stuff with your code without having to go over every byte in your program and think whether it's correct or not. That's why universities are so fond of it. Our physics department has completely migrated to Java, because you can build and extend software easy and quickly, and it behaves as expected. Sure, c++ is build towards the same code-reuse principles, but you'll find that Java's restrictions towards memory usage, timing, naming conventions etc.. can be quite beneficial to your productivity, especially in larger projects.
.NET.. but as the article said.. the linux community consists for 90% out of people that spend their time hacking c/c++ and perl scripts. MS and SUN have been fighting a bitter war over the 2 languages, but that doesn't mean linux users should be anti-Java a priori.
:).. Ok, it might seem this way, but it's certainly not my intention to push you or anyone else towards Java, you should taste it for yourself and draw your own conclusions, but it's really a wonderfull language, and when someone takes a stand against it with poor arguments, I want to show them the other side of the road, so it get's a fair chance. That said, I whish you a lot of fun with c++, too :)
You mentioned special purpouse hacks in Java, and you go on saying that C++ has templates which Java lacks. Ok, I'll explain why that looks rather ironic
Ok, back to what I was saying earlier. I think you're confusing the Java language with the Java API. The former is the syntactic and the semantic contruction of valid Java sentences, and that takes 10, maybe 20 hours of teaching (to people who understand the concept of OOP). The latter is indeed the huge number of sub-api's that together form the JDK and that indeed is a huge download. But all they contain are pre-made classes with functionality that you can use without even thinking about how you'd implement that stuff yourself. Once you know the Java language, you can use any API instantly. You only need to explore them and search for something you need. C++ offers you the quite limitted standard stuff and comes with
Yes, I remember when it was about programming, not money. But you'd definitely have to pay me to write in Java. I might still try to find a use for it, though, despite its designers and an API. I'll let you know if I find a good place where it shines. But apparently you've made up your mind already.
Hahaha.. yah.. money.. to be honest, I love coding, so I like to code in c++ more than in Java, because of the challenge c++ offers me time and time again. Sort of a fight against yourself, to keep concentrated and make as little mistakes as possible while on the job. I was very sceptical to Java at first, too, but I decided I should try it out for myself before taking a stand, and appart from performance, the language really shines on various points, you'll find them in any introductory course book. The performance factor is steadily decreasing as computers get faster anyway, then there's jit compilation which introduces a whole new set of possible optimalisation issues, and finally, contrary to what many people think, Java CAN be realtime(this being just one set of examples).
Sp yes, I've certainly made up my mind, and I hope the linux community will look towards Java as another reason why people may want to use linux. SUN is bringing out JDK's for Linux for a reason, IBM's effortless backing of Linux and Java are remarkable, Corel, Imprise and Borland are all on the same frequency regarding Linux and Java development, even MS is aknowledging SUN's distributed network paradigm (embodied by Java) as the way of the future, and created c# and
Wow, it seems I was kinda ranting here
Best regards,
Ignace.
With great power comes great electricity bills.
In what environment would you run an app
without loading (and sharing) the C lib?
Those 300k is probably already loaded and shared among *all* processes
Yours Thomas
Thomas S. Iversen
Advocacy over langauges usually result in nothing. Just have a look at some of the advocacy groups on usenet, what a waste of time, don't these people have better things to do. People have strong beliefs and aren't swayed easily. Java like every language has it's pluses and minues, pick the right one for the job. But for crying out loud, don't go out spreading FUD about something you know nothing about. I personally like Java and have been programming in it full time for the last 3 years, but I certainly haven't programmed in every language out there so I'm not qualified to say Java is the best or the worst, so why do people who have programmed one little applet (crapplet!) think that they know everything about Java!
This can be an opportunity for open-source. Why wait for Sun to release the JDK for your favorite platform? Try writing your own implementation and open-source it. And you don't have to write everything from scratch. IBM has made Jikes open, and it is a very good compiler. Of course, you have to also provide the set of library classes. But that's not impossible. Just look at what Blackdown has done. Too bad right now it's only for Linux. I want to see the latest JDK (or clones) released for more platforms (such as the BSD variants).
If you actually think that a compiler will/can make code efficient and fast, then you have a lot to learn.
Proper design is the essential aspect of making software efficient. Clean fast algorithms will always increase a programs speed and efficiency, optimized code will not. Sometime try making a 3d game without using some kind of bsp/portal/other system to get rid of unseen polys. You can optimize the drawing code all you want, but performance will still suck!
Matt Newell
Aww, foo, learn RPN and get with the program already. Get an HP calculator and you'll be whipped into shape in no time.
"Hot lesbian witches! It's fucking genius!"
--
Java 3D uses Open GL, Is fast after the initial loading, and can also be run in a browser after an initial setup. I've been experimenting with 3D applets that blow the lid off of any VRML or Flash environment in use today--and they're portable.
No offence, but when writing software for use in a business, correct functionality is immensely unbelieveably completely more important than performance.
If something takes three days to run, so be it. Hell, half the time, splash some cash and get juicier hardware, it'll run in half a day. However, if it runs in three hours first time out, but puts a 4 when it's meant to be putting a 7, it's useless. It's just taken three hours to corrupt and ruin your data. That's not a good thing.
So get it working, get the right answers. Then spend a couple of days profiling it and hitting those 3-4 blocks of four lines of code that between them take up 90% of the execution time. And optimise them.
Writing business software you don't have the time or luxury of tackling both functionality and performance. So hit the important one first, and the other one later.
~Cederic
ps: yeah, I know, you have to have a decent architecture and a decent high level design. So, go learn some design patterns and other essential elements of software engineering. Get your stuff reviewed, early, often. etc.
The bloat he was referring to has NOTHING to do with the size of the runtime download[...]He was referring to the memory overhead that java puts on programs.
/. uses--is supposed to be faster and less "bloated" runtime-wise than Java? I don't think so, Java will kick Perl's ass speed-wise and its garbage collection won't memory-leak all over the place with circular references. VMs are getting really badass, benchmarks are showing JIT compiled code to be faster than native mode code now! With all the continued research into garabge collection the overhead of garabge collection is reaching a trivial level. Not there yet, but give it time.
Oh God, and Perl--which
You can write a big project in java in fractions of the time it would take you in C, much less assembler, but I guarantee you that when it did get finished in assembler it would blow your java code out of the water in terms of speed. But your code would blow the assembler out of the water in terms of maintainability.
There are several fundamental ideas in performance tuning programs, one of them you should learn: Optimize algorithms over low-level optimization. You get better performance gains by optimizing algorithms in a high-level language than you do hand-optimizing lower level code. Plus, compilers/VMs are getting much, much better at low-level optimization to the point of making it difficult for a human to out-optimized by hand.
A clean, high-level design can easily out perform low-level designs with the same amount of effort. C++ 'string's perform better than C 'char *'s.
Ryan Earl
Student of Computer Science
University of Texas
heck yes, lots of command line apps. Then again, they're all kicked off using WinNT 'at' or unix cron or Control-M or equivalent. And although they are definitely command line apps they rarely do much printing to screen, cos they're designed to run unattended and print to files. Plus output is almost always redirected via logging APIs allowing run-time choice of where messages appear, no need for compilation, etc. And hey, what do you know, they were quick to write, easy to test and they work.
~Cederic
It reminds me of Transmeta's you can emulate any cpu as long as it is x86. Eventually that will change (for both, hopefully) until then, I will still use c and c++ (and I have written Java), because it is more portible. Sun's it will run on any platform (implying hardware and software) just doesn't hold up.
On your point of ease to use: Why, for most things, is something other than BASIC used? BASIC is the most similar to the English language that I have seen, and compared to that, Java doesn't have a chance.
IF Java worked as Sun says it should, I would likely use it. It doesn't. I don't.
--
sometimes doing a bit more work is worth it for the other benefits it provides (we're talking about a system that uses a VM here!). if you want to avoid runaway memory usage (and in the process improve cache performance and necessity for swap/paging) then ref counting is the way to go.
Inferno uses this technique (actually it uses a generational GC as well to catch the more unusual circular references) and we can happily run a system doing useful stuff (shell, GUI apps, etc) in 512K of RAM.
as any real-time afficionado will tell you, predictability is often more important than raw performance - and that's what ref counting gives you. most OS paging algorithms are designed around the concept of a "working set" of memory that a process needs to be able to compute with. conventional GC often works to foil this approach.
cheers,
rog.
First pass through: Make a product that does something. Anything. It doesn't matter if it's correct or if it's optimized. Marketing promised that it would be released before the next trade show. Manager promises that you'll get a chance to rewrite subsystems and optimize later.
Second pass through: Make the product stop blowing up when used in a way that none of the developers, designers, or test engineers ever thought of doing, but 30% of the users routinely do. (not that you'd ever let a designer or developer near an actual user during design or development, because only sales and marketing types are presentable enough to meet the client.) This involves revising about 1/3 of the basic architecture of the program. Manager says that because this is critical to the company's reputation, there is no time to make any other changes, no matter how needed they are.
Third pass: add the core features that belonged in the first release but which were left out for marketing driven bells & whistles. Do so without changing much of the underlying structure of the program. Some of the hacks put in in pass 2 are fragile and will break if you mess around with other parts of the program. Manager is strangely silent about future improvements or optimizations.
Fourth pass: fix the bugs from pass three. Manager quits, or gets promoted to big executive office where you never see him again. He's replaced by a clone with even more disgusting personal habits.
Step five: Developers get disgusted and quit. New developers spend so much time reading the cruft in the code that they don't have time to optimize anything.
So if you don't optimize right away, during the first pass, it never gets done.
To email, do the obvious.
A number of the negative statements about Java have been attributed to the JVM. I agree that the JVMs out there are generally poor for embedded apps, but is that really the core problem? Is embedded JVM too slow or is Java itself inherently inappropriate?
It's easy to forget how Sun's picoJava cores got canned. According to Sun starting in 1996 the answer to poor embedded JVMs was to announce a silicon chip that executed Java directly. picoJava I was a JVM-like execution engine, executing bytecodes in silicon. That was too limiting though, so Sun announced picoJava II, introducing about 50 new opcodes so it could be used for C and C++! Sun even hired MetaWare to write a C compiler for their Java chip!
Sun's microJava 701, based on the picoJava II core, was supposed to be a standard product produced and shipped in commercial quantities. However, Sun cancelled those plans in 1999. The microJava 701 was produced in small sample lots, but ultimately its death was hastened by poor demand and lack of commercial acceptance.
The same can be said of Java-on-silicon generally. With a few notable exceptions, several high-powered semiconductor manufacturers have failed to bring Java ICs to market despite initally signing on with Sun. Fujitsu, Siemens, IBM, Sun, NEC, and Rockwell/Collins fill out the list of no-shows to the Java-chip game.
Yes there are a few chips out there like Ajile Systems (former Rockwell/Collins technology), and Patriot Scientific, but if Sun and all these other big boys can make Java-on-silicon fly, what does that say about Java in the embedded space?
One man's opinion.
Anybody want a peanut?
excuse me, did you take the wrong medicine this morning?
I've had exposure to various server-side java applications for several years now - and it's the worst crap I've seen in my life. java is:
- slow
- resource hungry
- platform independent
let's see, on a server you are looking for:
- speed
- optimal resource usage
- a stable hardware/software platform to run on
yeah, fits perfectly.
should I mention that I've seen at least two java-server-side project with budgets in the millions fail horribly? no surprise everyone with real IT knowledge was telling them beforehand.
java on servers. get real.
Assorted stuff I do sometimes: Lemuria.org
Just a proof-of-concept implementation, IIRC.
I was thinking in terms of JDK1.2's orb.
Is that C++? Because in Java, you can implement as many interfaces you like: You have multiple inheritance of type, which is the useful one. Multiple inheritance of implementation means a class tries to behave like two different classes instead of itself, which is yucky in a Clive Barker kind of way.
I also said I didn't have enough energy to type that much. Do you believe that as well? Ya see, there's this thing, it's called irony... I have other reasons to dislike Java, but why not tell you the most asinine?
Nonexistent.
Nonexistent.
'I am not the lord of cherry pies.'
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
If a perl program can compile AND execute in a fraction of the time--why would I want to use java anywhere that I could use perl instead?
If it was that simple, then there would be no need for "workarounds" such as mod_perl to lessen the overhead of the start program/compile to bytecode/execute process.
Java back-end apps are fast as hell because of that. They do not need to be compiled time and time again, and on a server you should not have many memory constraints, so the JIT can work its guts out to optimize the code the VM is executing. The result is that you have code that yes, takes more time to load (VM startup, initialization of classes, etc, etc), but exactly because of that can be optimized over time.
I've seen benchmarks (Ace's Hardware if I am not mistaken) that show Java can even beat C/C++ in speed on number crunching algorithms. The notion that Java is slow is highly overrated.
--
Marcelo Vanzin
Marcelo Vanzin
I am fully aware that not all of the following issues are issues with the language itself - BUT - other languages *do not have* these issues.
;)] and comparable with what *MacOS* uses.
.class files to MRJ. All those classes are in a separate folder. But even those classes only take up 1.2 megs of HD space. There is another folder called "cache" which appears to contain some other resources including ".rpg" files, but even that only takes up 3.9 megs.
- Garbage collection. This is a *bad* thing. It encourages people to write bad code and not clean up after themselves. It means they don't learn what's really going on, which is going to kill them if they ever have to write in anything lower level. But more importantly, how does the VM know that I *want* to free something? Just because nothing cast as a pointer points to that struct anymore, doesn't mean I don't have its address stored (possibly in an obfuscated way) in a string somewhere or something like that - I might want to get at it again. Gc means that the implementation is doing something I did *not* explicitly ask for.
- VMs. Everyone's saying "XXX is the fault of your specific implementation / your browser / etc." - but where are the VMs that *don't have these problems*? I know that Sun can hardly be faulted if say Netscape's *original* implementation of Java wasn't *perfect*. But I'm running *4.5* on a Mac and *half the applets I run across* crash the browser *on their first run*. Maybe it's just the developer's faults - but I thought Java was supposed to be higher level and make it easier to write correct code?
- Which brings me to the next point: there seems to be this culture of "whatever works" surrounding Java programmers. At my university computer science courses are offered in an advanced engineering stream (which I am taking), in computer engineering and in computer science proper. My program teaches C/C++ exclusively, and half the marks on each assignment basically are for coding style. The computer engineers are taught Java exclusively, and get their marks based entirely (from what I've heard anyway) on the results of automatic testing. It doesn't even matter if there are 10 input cases on the autotest, and the program would run the system out of memory on the 11th. Admittedly I don't know much about what the comp sci students do.
- Bloated runtime environments and very messy app design. I have tried monitoring WebRPG for Mac's memory usage over time. It requests 3.9 megs of RAM as the base allocation. The *very next time MacOS updates memory usage statistics*, this has jumped to 7.5 megs. By the time memory usage appears to have stabilized (after around 10 minutes of usage perhaps) it is using over 18 megs of RAM. That is more than NetScape [before it starts Java
How big is the app itself, you ask? 8*k*. The main code block takes up about a quarter of that, the rest being GUI resources like icons etc. AFAICT it's basically just a class loader, which feeds the
Let me toss in my personal bias here. I generally hack in C and Perl. I use Perl for the high-level stuff, no sense mucking around with pseudo-high-level stuff.
I don't personally like C++ because:
(a) It went just a bit too far for my tastes. I do actually like operator overloading, but what the fsck is multiple inheritance good for? I haven't even found many good reasons to use inheritance at all yet. Most things work very nicely in the form Class Foo {... Bar* baz;}.
(b) I have worked out how to implement virtually all of the things I like about C++ using C and am working on my personal library, so it's useless for me.
And (c) C++ is *impossible on the order of escaping the event horizon of a black hole* to debug using vanilla command-line compilers (such as g++) under *ix, whereas doing the equivalent for C (with gcc) is merely *difficult the first few times you try it*. I got used to debugging C that way, but there's *just no way* I can fix up my C++ code when the compiler spits out "Confused by earlier errors, bailing out" - as the FIRST AND ONLY error. And heaven help you if you ever accidentally try to insert a Foo into an STL vector (when you meant to insert a Foo* and haven't defined insertion of Foos). Hope you like really long expressions with lots of angle brackets in them.
I have had to use assembly this term in university and I agree that it can be a real chore to get it right, but I personally find C *easier* to deal with than many higher level languages. It has its faults, and it certainly can't easily be made to do what Perl does, but I definitely find it to be the right tool for the job much of the time (especially if you put in the effort to do proper top-down code design).
Zahlman Q. Namlhaz, esq. {:> "Zahl Incorporated - the Last Word in Everything(TM)"
Amen to that.
Java, like any language, is a tool. Use it where it fits (and nearly any UI app work I do is in Java these days - and all my work's on linux or other unix platforms). No, I wouldn't write a network driver in it, no I couldn't write a kernel in it - there are other tools for those jobs.
But then, I've had a hard time explaining to some managers what Java does - they hear about it, but for too many people java is still "applets and something else like that, right?". *sigh* apparently that mentality thrives here, too...
Forget about portable and think about Java as a better C++ .
Java as a language has gotten threading and memory management a LOT better than C++. I've had to write major multithreaded systems and components in C++ and it's been a major league pain in the butt. Those memory corruption bugs (including array indexing bugs), leaks, and so on just DO NOT HAPPEN IN Java.
The answer of "why Java on the server" is because the developer productivity can easily be more than doubled, particularly when you account for the lingering costs of hard-to-find bugs that Java rules out at the language level.
See? Easy to understand.
And yes, Java on clients needs a LOT of work. Netscape did more to kill it than Microsoft, curiously enough.
The ONE thing I thought was promising when I first heard of Java was the running on different platforms idea. Sounded good. Unfortunately it just didn't make it.
java lets developers use their os of choice. our team has 2 linux and one nt user, and the servlets/jsp app runs on solaris and win2k as well.
Huh? Ever heard of the "private" keyword? Only accessible within the class.
I use it everyday. it runs at least as well as it runs on windows.
I realize all of that about the jvm starting up, and that the performance will level out with a bigger program. But, I simply cannot recall ever running a java program that didn't feel dog-slow. My first experience running Java was HotJava 1.0, and nothing much has really changed since then.
If a perl program can compile AND execute in a fraction of the time--why would I want to use java anywhere that I could use perl instead?
Maybe I might consider running Java if it ran on half as many platforms as Perl does!
domc
Bravo, well said. I code in Java exclusively on Linux (using just nedit and IBM JDK 1.3). While I recognise that there is a difference in culture between Sun & the Linux crowd doesn't mean I would reject Java. I think Linux is great and Java is great, I certainly don't use Linux simply because of it's philosophical underpinnings.
OK, so exactly why isn't Slashdot spending a bit more time talking about GCJ? It's not like it's hard to find, the GCJ site is linked right off the GCC page.
Don't tell me all these slashdotters are so bereft of independent thought that they're following Sun's marketing party line without even prodding it to see if maybe there isn't a better way to use Java. (I can tell it's true!)
Current status: it compiles from Java source or classfiles into native code, using the same codegen the rest of GCC uses. It supports CNI, which basically lets you access native code at C++ method invocation speeds. Looking good, and some production apps are using it. When you create an app with GCJ, it can look like any other native executable ... and it starts and runs faster than anything I've seen out of Hotspot!
I'd not try anything older than the GCJ 2.96 found in RedHat 7 (or maybe Debian). And you'd need to be cautious about using "Java 2" APIs; they were, after all, part of Sun's strategy to quickly bloat Java so it couldn't be "open". But I'd really encourage folk interested in Java and Linux to start investing in GCJ ... if anything is in a position to reconnect these two communities, it's GCJ ...
Hello . . . I was just responding with your gross overstatement (assuming you are the original AC):
Perl while a fine language and very powerful, is completely unreadable, unmaintainable and un-reusable
In a inverse situation I write Perl and C professionally and not Java but I don't go around making statements like you have above about environments or languages that I may not fully understand. My only comment is that to Frenchman French is perfectly readable while english looks like a grabled mess.
Were I work I currently maintain a Perl app with 14k lines of Perl that monitors the health and safety of an underwater vehicle. It is a "real" application; it is a "complex" application and joy to maintain in comparison to an other package I maintain that is written in C and is horrible designed and coded.
Remember you share the same shame (say that a few dozen times) that Taco does for posting something inflammatory and unfairly baised. But then again the original intent was probably to generate 900+ posts.
IMHO what exceptions that a method may throw is part of the API to that method, along with the return type and its parameters. Exceptions do have a real use as far as I'm concerned, take for example the JDBC API (java.sql.*), most of the methods there are defined as being able to throw a number of exceptions, meaning that something has gone wrong... I'd rather right exception handling blocks than checking every single return value anyday.
Damn straight I want to address the actual devices I plonked down all that money for.
There a 3 forms of incorrectness which you are failing to discern: failure to match the spec (bugs), failure to match the business requirements (bad spec), and poor performance (which this thread is about). These are 3 totally different things and that you could even possibly confuse them is indicative of, well, I don't want to get personal. But in no way should you think that doing one of those 3 correct is an excuse for failure on the others (eg, "the program doesn't do what you need, but there aren't any bugs!"). It's also worth noting that bad performance, in many cases, can kill a project as well as the other two failure modes - not everything has as many spare cycles as AS/400 report generation or web serving on E10k's...
I think you need more experience.
Have a nice weekend!
Yes, it is hell slow to run GUI application in java on linux box. But Hey! U can't actually complain about it. I found that there is not much slower to run Sun's forte for java in java under Win9x than Emacs under Linux.
That, in itself, is both an interesting feature and a major, major nightmare for build and configuration management (something I'm paid to do.)
Compared to what, resolving dependancies on header files?
In Java this is easy. Has this file been touched since the class file was written. No? Then leave it alone. Does this file have a dependancy? Yes? Is it compiled? No? Compile that first. javac works this way, and it rocks.
Now, there is a big problem with some optimizations, though, like final static variables of primative types, which are always inlined in the object code. But there is no reason that it can't be recognized by the compiler, they just don't because it requires a reverse-dependancy check, which isn't exactly fast unless the dependancies are pre-computed, or requires every file to be parsed, regarless of its timestamp, which defeats the whole purpose.
Of course, none of this works if you use makefiles and treat javac like a C compiler, but that's why you should be using something like Ant.
--
Bush's assertion: there ought to be limits to freedom
The jikes compiler is another java compiler written in C++ and is open source. Go to theJikes Project page for more information, and to download the compiler. It's 10 times faster than javac... or at least it was the last time I checked.
Idol Star Astronomer
That's a syntax issue, not a functional one; you can always use string1.equals(string2), and get a result equivalent to the intention of the C-style boolean operator. Remember, Java object variables are just references, not values! Trying to directly compare them would be like trying to compare two pointers in C, and then being shocked if they weren't equal, even if the data structures they pointed to were of the same type and had the same contents.
Thats sad, considering it took me less than 3 hours to damn near write a complete spell checker minus a decent word matching algorithm :-D
Jeremy
There is no reason, Insertion sort runs quicker, and with less than say 10 inputs Insertion Sort(Or Shellsort) are quite effecient and easy to write
:-D
These can even handle a moderate number of inputs
Use quicksort when you have a shi*load of inputs
Quicksort is good, but it can be tricky to implement really good to help avoid worst case, and getting the partioning write etc can be kind of tricky
If worst case is simply unacceptable I have used a combination of Heapsort/Mergesort (hard to explain) to make sure that worst case is never hit (like in quicksort) when worst case is just unacceptable but quick sorting is needed. Were this to be a really critical realtime system(maybe a nuclear power plant) speed and such would be a consideration as WELL as it working properly. Hehe anyhow enough about this, I have done a bit of sorting(written a bit of a Java Email client for shits and grins)
Jeremy
Unless its trivial my ass. How much of the Servlet spec don't you understand? How much of the Bean spec don't you understand? If you use any of the vendor-specific stuff you're a moron.
I have written an encapsulation library for CGI, ISAPI, and NSAPI in C++. It was one of the most beautiful things I've ever written. But after using servlets for a year I've never looked back.
--
Bush's assertion: there ought to be limits to freedom
Every time you mention Java, too many people automatically think you're talking about Java embedded in your web browser. Web applets to do horrible graphics slowly, etc.
Java can be used as a programming language with a portable GUI to build GUI apps that work on all platforms. This is it's huge strength. Other strengths are GC, type safety, RTTI.
It's weakness is speed. This problem is mitigated somewhat by improved compiler technology. (The same mantra said of Common Lisp a decade ago.) But the real reason that speed is not such an issue for most GUI front ends, is that computers are getting faster and cheaper everyday. So java's major weakness becomes less of a problem with each passing day.
Then there are all the petty bickerings. I never seem to see people criticize the productivity of Java, or the semantics of Java. Just picky things like the syntax, or lack of their pet syntax sugar issue.
I'll see your senator, and I'll raise you two judges.
Why do so many employers want to see Java on your resume then?
/writing/) the back end of the web site in addition to doing the main web page. Java may suck as extras to a web page (the prevailing sentiment on Slashdot is that it does, but the larger jury is still out on that issue), but it rocks at the back end. Server-side Java is a whole different kettle of fish than client-side.
As a web developer, you may be responsible for interacting (or possibly
--
There's a very good reason... what happens if you change the underlying architecture of the object you're dealing with, but a bazillion lines of code use your get and set methods? Well, easy, just change the methods to do the right thing and voila! all the code that uses your object still works. If this code just accessed your variables directly, you're screwed. Hell, in Java, even if your internal representation changes from floats to doubles (perhaps to increase the accuracy of calculations within the class), if you access the variables directly, ALL the code has to be changed to cast the variables. If you have get and set methods, it's a trivial change. It's called abstraction... you develop an interface which is abstracted away from the implementation. Trust me, it's a very good thing.
You're thinking of Java applets. Not too many people use applets anymore. Java is mostly used on the server side, so you'd never know that it's there, i.e. it's used to generate pages dynamically. Java is, in fact, behind many large web sites these days. It's where it's really shone as a technology. Don't write Java off because of applets.
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
Java the language is adequate.
Java' VM is very immature (the could take a page or five from the Smalltalk people who've been improving theirs since 1980,) and it shows.
Java the suite of libraries is in the same state as the VM and again could learn from the folks who've been at it a lot longer.
Java the IDE is pathetic except for IBM's VisualAge for Java which is almost as good as Smalltalk's IDE (VisualWorks, VisualAge for Smalltalk, Dolphin or even the late, lamented VisualWorksSmalltalk.)
Basically C++, C#, Java and Smalltalk (even Perl, CLOS and php,) as languages are roughly equivalent and its possible to write translators between them.
The IDEs are what make the difference and if you want a look at the best, check out Squeak to see just what you can get for free.
Don't let the syntax defeat you. Its actually the correct one for an object-oriented expression. If you can understand RPN calculators, you have the mental equipment to grok Smalltalk.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Moderators? Hellooooo Flamebait... this gets a 2?!
I just thought I'd correct some of your misconceptions about Java. Are you absolutely sure none of the pages use java? Most java usage now is on the server side using Beans or JSPs. The JSP pages generate the HTML code your browser reads. While there might not be any applets on any sites you visit, java might be generating the content that you are reading.
Now to counter your java bashing:
I have never seen a cleaner network/socket interface than I have seen in java. I know C,C++ and perl. Java's interface for networks is incredible. There's no way you could implement something that uses any networked functionality in less code than you'd use in java. It's very abstracted, and clean.
Java is not a 'buzzword' any more than linux is. I work at a large web company, and I only code in java...under linux. The java API (with a few exceptions) is truly excellent.
I'm no die hard sun supporter either. Java does have serious problems. Because of the VM architecture, another layer of possible bugs can creep in to your applications. I had an instance a while back where a buggy VM was causing serious problems in one of my applications. Thank heavens I was using linux where a quick network sniff (ethereal is golden) determined the problem was indeed with the VM. Then I called sun, and they refused to admit they had a problem. However, because of the extremely clean network implementation, I was able to re-code some low level modules in about three days.
To sum it up, java has its problems, but I really think you're missing the point here.
"This is not a company that appears to be bothered by ethical boundaries."
Attorney General Mike Hatch on Microsoft
Ooops. I meant 0-10% slower than comperable C code.
sigs are a waste of space
Jeez - someone needs to get down off their soapbox.
Yes Java is more wordy than some languages, personally I like that. I like the fact that it looks more like english than C. It makes it more readable. But if you don't agree then fine don't write stuff in Java.
As for your comments on the IDE, you seem a little confused. If you didn't like VisualAge (I assume thats what you used as you mentioned IBM) then use something else. JBuilder is great, Cafe is supposed to be good, emacs is fine, hell use vi if you like. I actually did a fair amount of my early java coding with nothing more than vi and jdk. You then go on to rant about JavaBeans and the API without really explaining why you don't like them. The two are entirely unrelated - the API is simply a set of default classes. Again, if you don't like them don't use them, but in my experiences there is some great stuff in there (like the Collection classes for one example). JavaBeans is a standard which your classes may _choose_ to comply with, which means they can be freely dropped into any other JavaBeans aware application. Yes you lose a little flexibility if you use beans, but the power you gain is significant. Being able to code up, for instance, an extension to your preferred IDE and have it seamlessly appear in the menu/toolbars is great. Surely that kind of thing is just what open source is supposed to be about??
You mention data-hiding. You don't need to have get and set methods for every field you idiot - just the ones you want to be accessable!! Of course you can have true private members and just have no accessors - totally legal. If you want it to implement serialisable/beans then there are a couple of issues but it's no big deal.
Naming conventions...nothing that important. The convention is that methods look like "thisIsAMethod" and classes look like "ThisIsAClass". But it will still compile if you call it "this_is_a_class" so don't worry.
C++ is a messy, dangerous part-OO, part-declarative travesty built on top of C, which is a generally decent language if you really need to hit the metal. For writing large scale business oriented apps I'd recommend Java in almost all cases.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
The Java language is more cumbersome than necessary for the type of programming usually involved in web apps. Luckily, you don't have to use the Java language to use the JRE and Java objects, thanks to GNU Kawa.
My maze generator on brlewis.com would have been a Project with Java/JSP, but was a quick hack with Kawa/BRL.
Sun DID develop a JDK for Linux.
JDK 1.3 SE has been out for at least a month now for Linux.
It completely whips the Blackdown 1.2.2 JDK in compilation and runtime speed.
-- I ain't broke, but I'm badly bent.
He who hates Java likes to program close to the bare metal.
People who like Java seem to prefer to program at a much higher abstract level. GC, RTTI, no pointers, type safety, etc. (Don't read this to mean that all people who like high level programming automatically like java -- I know someone will.)
I'll see your senator, and I'll raise you two judges.
Well, you're right that if designed correctly, they can provide that benefit, but first it would have to be *taught* correctly, which is a separate problem.
However, since I generally do not wish to provide get/set methods for everything, my argument is that if you want to extend my class, then you can inherit it, and provide accessor methods for all of my *protected* variables.
...which, by the way, have to be in a separate *package*, and therefore a separate DIRECTORY just because I don't want anything else in the same *package* messing with it because it's supposed to be PROTECTED, and therefore only have CLASS SCOPE and not *package* scope!!! (my point being that Java itself makes it almost impossible for people to write good code in Java; in any case, it certainly isn't intuitive, and it isn't taught properly yet, either...)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Seriously, Java-heads, this is a fine, high-quality rant. You should be able to derive much wisdom from it. Remember, your critics are among your most valuable assets.
(JAPH, Pim)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I knew someone was going to force me to give this long and generally cryptic description...
Where I work, we use Rational Clearcase for version control (etc.) Unlike conventional builds, the only explicit dependancies that must be listed in the Makefile (which is, itself, under version control) are critical elements outside clearcase. Clearcase audits builds to construct configuration records enumerating what was done to create an object (called a derived object.) That includes every clearcase file referenced, the commands executed ("build script"), and environment variables referenced. Clearcase evaluates that information to see if it needs to rebuild it (or "wink-in" a copy someone has built -- use their copy instead of compiling it yourself.) That works perfectly with any sane langauge.
HOWEVER, with java, that's a nightmare. Allow me to demonstrate the complexity of the problem which you you seem to have ignored. When you run javac, it will recursively compile everything it needs. It will not verify the up-to-dateness of class files. If foo.java requires elements from bar, it's only going to look for bar.class. If it exists, it uses it - period. It will not look for a source file or try to rebuild it. If bar.class isn't available, then javac will build it in the process of building foo.class.
In the realm of clearcase, this creates a very serious problem. Let's say you have two java source files: foo.java, and bar.java. In the Makefile, they are entered such that they will be built in that order. If foo requires elements of bar, then the first time javac is invoked, you'll end up with foo.class and bar.class and configuration records showing the coresponding java source files were referenced. Then the build system will see bar.class exists and evaluate it's CR. It's build script won't match and thus gets rebuilt. If you run clearmake again -- having changed nothing, foo.class will get recompiled because bar.class is now different.
The problem is that java source is compiled from java object code. The result is an impossible nightmare for build and configuration management. No one can list every damned dependancy for everything in the Makefile. You cannot carefully order things in the Makefile to control the compile sequence (so bar is always evaluated before foo, etc.) Even if you did manage to build the dependancies into the Makefile and maintain them everytime a line of code changes (never gonna happen), you'll still end up with overlaped, circular dependancies; foo depends on bar who depends on baz who, in turn, depends on foo (I trust you can see the mess; one of them will always be out-of-date.) Suddenly you have to put special rules and targets in the Makefile to deal with clusters of source files.
You are correct in stating javac is not a compiler in the normal meaning. However, without 3rd party products, that's all one has to compile java source into java bytecode. So, there are very few options... You can go the complex route and wire everything into the Makefile and watch the source and compilations closely for the rest of eternity (read: pray.) You can take the shutgun approach and rebuild everything when any source file changes -- part of the build already does this, but I don't like it. Or find a 3rd party tool to hide part of the complexity.
Right now (if I could get the developers to make up their mind and stick with one JDK and one IDE) I'm building everything with JBuilder's bmj tool. It's not perfection, but it's at least consistant (mostly.) Even with bmj, I still have problems with overlapped dependancies -- one package depends on another or projects building on each other. Right now, the source tree for this development is rather small, but it's growing and will continue to grow -- there's 1.4G of C++ source, how much java source are we going to have in a few years? (I don't want to think about it.)
I agree, it is so blatently bias that I was actually quite annoyed when I read it. I'm sure there are millions of reasons why some Linux users hate Java, but I'd narrow it down to the fact that there is no reliable professional support of the JDK under Linux.
The JVM is a very good design, and Sun does not require you to use their API's to run programs. In fact I believe there is an OSS initiative to write a non-Sun API for Java that is more efficient than Sun's. So you can't really say that its too controlled by Sun, because there's nothing stopping you from creating your own API.
The aim for Java is to be platform independent, and it generally succeeds at this. Performance is something that unfortunately Sun's API is not always aiming for since they have limited resources. However, there are many tricks you can use to speed them up, as well as compiling Java code to an executable binary.
I think this article is just unnecessary. Complaining about the legal restrictions is one reason for hating Sun. Complaining about its performance is just the blind leading the blind.
"doing a linear search or a bubble sort is sometimes acceptable"
Doing a bubble sort is never acceptable. No matter what data set you have, there is always a better sort algorithm than bubble sort. Not only that but the algorithm is of O(n^2) so scales catastrophically. Knowing your basic algorithms is far more important than your ability to push Java or C++.
Worrying about performance later is not best practice. It is unprofessional. Performance is always part of the equation, along with maintainability amongst other things. There is no point wasting your time on a first pass on a product to get the functionality right if the software does not get the job done in the time available. If I write a search script that takes 30 seconds to return results I may as well not have written it in the first place.
Other factors may override performance but it will never stop being a contributing factor. Java is a popular server-side programming language because programmers are expensive and thin on the ground. Java is easier to maintain and less prone to bugs (the most common C/C++ one being memory leaks which Java almost eliminates). It may not perform as well as C/C++ but thrown enough hardware it performs well enough.
If I calculate the performance of a Java implementation and it fails on the performance needed by the spec given, then I will have to either implement in a higher performance language (and interface back to the Java backend if necessary) or report that the project is not possible under the conditions given.
Sorry, but relying on a second pass and profiling will lead you to doomed projects. If you stick to using the right algorithms then profiling will only allow you to shave off a limited amount of time. If this does not give you the necessary performance gain then you will need to totally re-architect your solution.
Phillip.
Property for sale in Nice, France
That's what protected is *supposed* to mean. That's what it means in C++, but not what it means in Java.
:)
In Java, anything in the same package ALSO has access to your protected variables. Therefore, I think whoever designed that into the Java spec also had too much to drink.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Java has found its best niche on the server side. Every big-time server implementation I am aware of uses Java, if not for the full app, at least for the middleware. The reason is simple: compared to anything else on the server-side, Java is faster to develop, already has probably every binding and interface you can think of, and it's pretty damn fast compared to the other solutions.
.NET, Python is happy to work on both (there is a Python interpreter written in Java and Active State announced one that will compile to .NET's VM).
Personally, for non-enterprise level stuff, I am partial to Python: as clean in syntax as Java, even faster to develop, cross-platform, totally free (as in BSD free) and if you absolutely need to, you can compile it to Java bytecode and stick it in your enterprise solution as well.
And in the coming VM war between Java and
Am I the only one who remembers the 'data-hiding' portion of OOP, where you don't have public getFoo and setFoo methods for everything?
Ummm, setFoo() and getFoo() IS data-hiding. It gives you a hook so that you can validate every access to this.foo. Hell, there may not even be a this.foo, it may be computed on the fly, but you'll never know.
I'd rather work in Java than C++ (, let's see, is that a bit shift or a print statement...)
Just junk food for thought...
"What I think is that whilst the language itself isn't really going anywhere fast, the idea behind it will live on."
What do you mean that it is not going anywhere fast? It is rapidly gaining market share in the enterprise markets (Servlets, JSP's, EJB's, and Application Servers). In some markets, Java programming skills are in more demand than C++ and Visual Basic. In mobile devices, most of the major vendors are providing Java support.
"Personally, writing things like foo.insertanobjectattheendofthislist(object) doesn't really appeal to my sense of elegence, but some people obviously need reminding exactly what each method does. "
How does the language force you to choose method names like this? If you want to name methods with short, non-descriptive names that thwart the efforts of subsequent maintainers, the language places no restrictions on you.
"I expect C# to go places Java never will. It's a better language design IMHO, and it'll be a genuine standard, not a stick for Sun to beat their competitors with."
An important question to ask is, what parts will be standardized, and will enough be standardized such that you can easily write applications that can be moved from Windows to Linux to Solaris with out significant (or even any) porting. Given MS's past behavior, I am very skeptical. I think that C# is a thinly veiled version of Java that MS can control, and that it is likely that *they* will use it as a stick to beat their competitors with.
The problem with Java is that by sticking with C and C++ concepts in order to cater to the bulk of the programming community, it basically took on the same clunkiness of the syntax and semantics of those languages. Don't get me wrong, I am a C lover to the max (C++ is okay i suppose), but if Java really wanted to be immortal it would have readily supported variatic functions, closures, macros, and a uniformity of syntax similar to a language like, say, LISP. I believe in object oriented programming, but it is important to note that this is one of many styles of program writing, and is not necessarily suited to all applications. By including the above features, Java could have been a bit more flexible for the developer, though less user friendly perhaps. After all, control is what makes programming fun, and most Linux users like to have control. That's why they like linux. Java takes away some control, both by being more high level than C, and by enforcing one style of programming.
At Sussex university in the UK (where I is at :), java is the main language they use for the computer science and AI courses, so I pretty much got used to it.
OTOH, possibly because of the kind of things I write, I find that I'll either code in Java or Perl, I tend not to use C or C++ unless it's modifying someone elses stuff.
-- "[The] NSA can eat shit and die until they stop listening to my phone calls" - TastyWheat
- Linux
- NetBSD
- Win*
- PalmOS
- ...
With Java I was able to write myself a bus schedule App that runs from the command line, has a GUI version, and then I made a Java condiut to my Visor, with a waba app to check my schedule on my Visor.All this without needing to know anything other than Java. Say what you want to say, but for me its easy, fast development, with apps that don't run much slower except for JVM startup (but seeing as how Netscape 6's startup time is 15 seconds, the JVM startup time appears negligable too =)
Plus
You can't argue with Java unless you just ignorant. You don't have to like to program with it, but you have to respect it.
dave
Thats not my point. My point is that each language serves its purpose. Java's is portability and relatively decent performance.
At some point, you decide to change that double field to something else; say a float or some sort of fixed point representation. If it was a public variable, everywhere in your code that said objname.setFoo(x) would have to be changed to objname.setFoo(FixedPoint.fromDouble(x)), wheras if you kept the variable private all you'd have to do is change two methods, easily located within the same .java file as the declaration of the variable itself. For instance, void setFoo(double newValue) { this.foo = FixedPoint.fromDouble(newValue); }
Object Pascal integrates "many many modern and new programming paradigms and patterns". It also "pushes code reusability to its limits" -- moreso than Java, as Object Pascal's component framework is central to its object model, whereas Beans are a Java afterthought. And Object Pascal is easier to use than Java. Pascal is easier to read (closer to English than the C-inspired character jungle of Java), easier to implement (it neither packs nor requires a purely OO framework), parse (compile times blow Java out of the water), and design (separation of interface and implementation, property system for a far more flexible accessor method system).
Sun and Microsoft can play and fight all they want. Borland has (and, I think, will) always have the upper hand with the superior application, server, and database development tool with their flagship product, Delphi.
Check this out. FFTs in java!
I think there is a connection, though kalifa didn't state it: functional programming. ML-based languages are functional, and Python has some very useful functional-ish constructs, especially in 2.0.
Both make it natural to pass around strings, lists, other structured data, and function references around, but in Java you're limited to simple types and objects.
Want a method to call you back to do some calculation? In Java, you can't tell it your own method or lambda function, you have to make a new object which implements the interface the external method expects to be able to call. Major PITA. Want an (int, string, boolean) tuple? Have fun creating a whole new class to describe it, or surrounding a Vector with ugly (Cast)s.
(unrelated rant) And is it just me, or are Java exceptions completely useless? I thought the whole idea of exceptions was to bubble error conditions up to the nearest level of execution that knows how to handle them, but Java requires you to include what possible exceptions can be thrown in the method interface, so it's impractical to not handle exceptions as soon as they occur. It's no better than checking the return code from a function call in C. Actually it's worse since you don't even have the option of *not* checking it; if you don't catch (...), it won't compile, even for exceptions that will never ever happen.
--
This comment was brought to you by And Clover.
uhm..yes..they do work.. java's language structure is identical to c's, albeit java was designed to be oop in the first place. Though I know the public static final int blahblah can be kind of annoying, it *is* a good idea in terms of making your variables truly final. C++ was an add-on to C with OOP and contains some funny vaugeness in many ways. Java was built with OOP in mind. As for naming your methods in specific ways, thats just to make it easier on programmers. You dont *have* to. I suppose the only people bitching about this would be the types who name their variables cryptically so they make sense to nobody but themselves.
-
If you read How to write Unmaintainable code, you will see that the preprocessor is the ultimate code-obfuscation tool from hell. Is never a good idea to redefine language keywords if you expect someone else to understand your code.
You're right; 'public static final' is much more complicated. In fact, 'final' itself is a much more complicated keyword than const. Could they at least have provided a 'const' keyword, since it had a simple, clear meaning, and I use it all the time? No...
;)
Hey, want to be really evil? I'm sure you can randomly edit someone's java file to screw it up... Heck, leave a comment open somewhere. Randomly editing source is bad no matter what language you do it in. Heck, randomly delete a line from a BASIC program. Or for that matter, take a random byte out of the middle of your OS kernel; you didn't need that byte! So don't tell me that my examples are bad, now...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
*shrug* If Linux were to 'embrace Java' to the point that a significant percentage of the applications were written in it, I'd probably think of changing operating systems. I tend to change the source for many of the programs I use, and if they were programmed in Java, I couldn't do that. (C++ is bad enough; I can't even follow Java without getting sick of it.) I think there are quite a few more people in the same situation; if we always pander to what's percieved as the important market (which invariably isn't the people who already use it), we'll end up alienating people.
So the article says that Linux users don't like Java. (I think a more appropriate way of putting it is that Linux users aren't quite as infactuated with it as their counterparts elsewhere, but stuff like that isn't interesting enough to make it onto Slashdot.) I don't see any problem here. Why should we try to learn to like something that we dislike? We should make Linux benefit us, and if becoming an 'enterprise OS' doesn't help us in that cause, why should we bother?
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
You could add macros to Java, some people have done it.
However, macros are evil in many ways and they really don't bring anything useful. I always laugh when I see people who complain because they have to type too much...
Your example is very good :
#define const public static final
This way, people will use "const" to mean "public static final". That's really great.
Oh... just one thing... "const" and "public static final" **don't fuck*ng mean the same thing**.
When to really be evil? Delete one #endif somewhere in your friend's code... you know... in his 2000 files C++ project... Then, just watch the error messages coming!
it takes to.long.to.get.to.my.method(half, of, the, time);
Huh? And how is this any different from if you have a pointer to a struct with a pointer to a struct with a pointer to a struct in C? If you feel like it, you can have everything declared global and even write code outside of methods. Yes, you actually can do that in Java even though most people don't know it:
public class TryMe {
static {
System.out.println("i am not in a method");
}
public static void main(String[] args) {
System.out.println("i am in main()");
}
}
And of course in a properly designed app you don't HAVE to type long stuff like that because the complexity is hidden in the objects. All that point shows, Taco, is that you can't code object oriented languages properly. Read up on your design patterns...
and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders".
What does that have to do with Java? That has to do with *SUN*.
(oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use).
And again.. SUN - not Java.
Other then that, my only problem with Java is that the VM in Netscape is crap.
And now Netscape instead of Java.. This is actually a reason many people think Java is inheritly unstable and slow tho so it's a little sad. The company I work for has several large scale sites running Java in business critical functions and have uptimes of months and months. No crashes, no speed issues, no Netscape VM's.
Oh, and their licensing.
J2SE is free for anyone to use. It's source code is downloadable so you can see how everything works. Granted J2EE has a pretty lame licensing scheme, as do J2ME but most "Linux people" don't know what J2EE *IS* and that most of it can be downloaded separately without the lame licenses.
And the fact that its bloated.
Yes, that really is a problem isn't it? A Java 2 SE runtime download is about 5 MB.. That's terrible! Takes 30 seconds on a decent network connection.. and who has hard drive space for that anyway?
And the fact that I don't have enough time to type in all the reasons it irritated me *grin*
I think you don't have any good reasons really. If those were your two cents, I'd be asking for change...
i agree that in some occasion (despite all the theorical arguments against it), multiple inheritance can be useful. in some case, i can use that little trick: you can declare an interface that has an innerclass which implements the functionality.
/etc. it would be so nice in xml. in fact i agree with a lot of stuff that miguel said in his unix suck paper. unfortunately, a lot of people reacted strongly to this. i would not be surprised if someday, there will be some kind of a fork between people that want a traditional unix (including some elitists that want their system as cryptic as possible) and those that want to cut off a lot of unix legacy for more modern design.
from what i heard about mem mangagement, hotspot is much better, and you can tweak the jvm for it.
about the finalize method, i guess it's because it's not a special method like the c++ destructor. it may be a problem, but honestly, since there's the gc in java, i rarely have to override the finalize method, compare to c++ where most of the time, you have to code a destructor mostly for deleting your pointer.
rant mode:
i've done a lot of java coding in the past years, servlet, jsp, xml, etc.. and it made me realize, despite how much i love linux, how much it is "old". the kernel is ok for me, it has all the feature i want from a kernel, but look at the mess in
i have a pet project of doing a java shell: a minimal linux installation (kernel, modules, network service) with the init process spawning a jvm. i also started a JNI interface to ncurses, and building an api similar (but with much less feature) to awt to build text based java application : ). i'm sure there are a lot of similar projects, if someone has pointer to nice java developper msg board/newsgroup, please reply me.
"The really avant garde are already poring over Microsoft's C#, which Microsoft fancies is a sort of super-Java blending the best of C++ and Java, and keeping their fingers crossed that it won't be a Windows-only creature."
Well, they better do more than cross their fingers - maybe praying to some kind of golden calf and sacrificing some kind of farm animal would be a better idea.
C# is SO ingrained with COM+ and this .NET thing (whatever that is) that
Microsoft would need to port their whole company over to Linux in order for
it to work.
C# just isn't a competetor to Java as one of the main selling points of Java
continues to be it's cross compatibility (IMHO)
> You can define a stream that equals System.out, so that you only have to type something like o.println()
But is is still longer than printf. This is the result of one of the main reasons I don't like java: almost purely object oriented. There's no way to have simple non-object functions like printf (I hate c++ cout operator abuse too). Short and easy functions for essentials are essential for coding to be fun; having to do everything the long way makes code "heavy" (not in the memory usage sense necessarily, although that applies to java). Oh, gtk is equally awfull with java with horrondeously long function and macro names.
Praise the good old days with direct frame buffer access instead of bloated and difficult APIs and no hype standards.
Why would Sun object to the use of their java logo but *not* object to the use of the Sun logo?
-- Don't Tase me, bro!
Is it me, or is Java worse than the B&D-style languages that have come before it?
It's just you.
He who hates B&D languages is a masochist and loves to have bugs in his programs and spend endless time tracking down silly bugs that the compiler could have caught for him.
People who hate B&D languages seem to me lazy, and would rather defer having to think about the correctness of their program in favor of instant gratification, even though they can introduce logical errors and pointer problems.
Often this goes hand-in-hand with a dislike for GC. But not necessarily, as some B&D languages can be used to program close to the bare metal.
I'll see your senator, and I'll raise you two judges.
Jamie Zawinski (the Netscape Grokker) has put up a "java sucks." website at http://www.jwz.org/doc/java.html
If you watch TV news, you know less about the world than if you just drank gin straight from the bottle.
Jamie Zawinski has an excellent commentary on the good and bad points of Java.
It can be found at:
http://www.jwz.org/doc/java.html
Except for the handful of things outlined by Zawinski, Java is great. You can even get good performance (though not even close to C-like) with native compilers.
Check out gcj (The gcc native Java compiler) at http://sources.redhat.com/java.
Also, be sure to check out my Java CueCat driver at http://www.popbeads.org/Software
If you watch TV news, you know less about the world than if you just drank gin straight from the bottle.
I think it's funny that Unix users complain about typing long commands to get something accomplished.
/home/alg/porn -name *facial*.jpg -print
find
ALG
Java isn't perfect, but it is 100% more secure than C/C++. If you don't know this, you don't know anything.
Java has, at least, a built-in security model. It is extremely safe. A method will fail if the complete stack trace isn't trusted. I have no idea what you are talking about... but it is very difficult to have untrusted code do trusted things... A single untrusted class will make everything untrusted.
You can't get much better than this!
Which is one of the reasons I love Java. Except where performance is critical - then it's C. C++ need not apply.
--
Clear, Dark Skies
When you surf the web, you cannot always tell how the pages are generated. Using a good application server you can map specific URLs to JSPs or serlvets to do the work. Thus pages with .html or .cgi or .pl or .anything may actually be generated using Java. Just because you don't have gay spinning graphics on your web page does not mean that Java is not doing some hard work for you. Besides this the application server will cache the servlet and make it invocation faster the next time it is called and allowing for scalability. Just try doing that with a perl cgi script (you have to add mod-perl to apache if you want to know).
Solaristrum: One who has spent way too long staring at the Sun
I'd just like to thank everyone that followed up on my post. I honestly had no idea how much Java was used as a server-side language and I am quite surprised. I still feel that it is bloated, but I can see the reasons for using it.
:)
Deamons OUT!
-Frijoles-
The article was mostly pretty fair. I thought it did a decent (not excellent) job of covering some of the reasons why Java and Linux doen't always fit together very well.
Of course, I think a lot more people would have been willing to read the entire article if it didn't start out with this flamebait:
What is gained by by adding "at least in theory ?" I realize that may simply be an attempt to acknowledge that while Linux is freely available it is possible that some people will pay for it. But it reads more like an allegation that Linux is free in theory but in practices isn't. This especially reads like an allegation when one considers the libre qualities of the Linux source code. How in the world is the source code only theoretically free?
have a day,
-l
This summary heading wasn't *Why Linux Lovers Hate Java*, it was *Why CmdrTaco Hates Java*
Yes, the JDK is buggier than the volkswagen beetle I drive, in either Sun or IBM form.
Ok, so it's Taco's site, he can editorialize. but I wish his opinions weren't billed as News.
Besides, Java does pretty darn okay for portability.
If you don't like it that much, go code in COBOL. (in modern COBOL, you can do almost everything you want, and that which you can't, you call in libraries.)
A host is a host from coast to coast, but no one uses a host that's close
...Java is a MUCH better langage than C++
This is a little like saying that going to prison for 10 years is MUCH better that going to prison for life. Its true, but not very satisfying. The real advantage in java lies not in the language itself (which has issues... character count not being the least) but in its massive library.
Third, Java on the server is the best thing since sliced bread.
Compared to what ? Ok, I know, but its the java library which is so valuable here, not the language. Any language with such a massive library so oriented to network programming would have this advantage (Python anyone ?)
just my $0.02
-- Rich
Free your mind and your Ass will follow -- George Clinton
Seriously, you should be defining your interface independent of the implementation language. That would allow a browser-based "least common denominator" view and still allow you to work up a special "bells and whistles" client app when you discover that Java is cutting you off at the knees (and, for any moderately complex task, you will find that).
I havent exactly found Java to be too slow either. But the only reason that is so is because I've only written GUI's in Java. Which is, in my opinion, the best thing about Java. Its GUI toolkit is quite decent, and its portable (the best part).
I have not experienced Java's slowness as ever being a serious problem. If I'm doing number crunching, I use JNI. If I'm doing network stuff, then the interpreter is always faster than the networks ability
So....you dont bother to use Java when the going gets tough? :)
RedShodan --------- Never underestimate the bandwidth of a station wagon full of tapes.
I don't quite understand why the article claims that Java isn't liked in 'the community' because it's not 'free' - the Free Software Foundation itself realises that there are free implementations of Java, and that the language itself is very practical -- why not look at their GNU and Java page and their Free Java software page.
Does my bum look big in this?
If your "professional in the industry" is a fool it doesn't make java a bad language.
Slashdot: Proof that a million monkeys at a million typewriters can create a masterpiece
Yes they do. Every day.
(it's also a great way to speed up the execution of your Java programs! The compiler's generated output is quite fast for C-style comments.)
I'll see your senator, and I'll raise you two judges.
You have the misconception that scripting is not acceptible on the enterprise server. This is not true. Robust and performant application can be written in Python (or Perl, Lisp, etc), if the problem is suitable. The advantages of scripting need not be forsaken!
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Maybe you missed that 'public' keyword. It's easy to do; Java has a lot of keywords. This is how I was *taught* to "hide" data in Java. It isn't hidden at all. I agree that if done properly and sparsely, accessor methods can be useful. But this is at best difficult to do in Java, and people aren't even encouraged to do it correctly.
And yes, operator overloading in C++ can be infinitely abused; that's because it's powerful. You can build very intuitive interfaces with it, but you don't have to. Similarly, the fact that Java doesn't have an actual 'goto' command means that when you actually need it, it isn't there. As much as people hate it, 'goto' still has some valid uses, when you want to implement proper tail-recursion, for example...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
The very existence of System.out.println demonstrates that java isn't purely OO. An even clearer example is Math.random(). This 'hierarchy' is a kludgey hack (and IMO, a very good one) over an OO namespace to fit in global functions.
That's where I've always thought Java was slow- with GUIs. Not a little "Hello World" or currency converter app, but in actual applications, Java is slow as molasses, IMHO. Java is pretty fast for straight numbers, but it seems to drop the ball for real world apps. Which is not surprising- Java wasn't meant to scale so high.
There are a lot of other options (that aren't so slow) for cross-platform apps, including GUIs. Some are more cross-platform than others.
Speaking of GUI api, have you ever heard of OpenStep, er, rather YellowBox, I mean Cocoa?
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
then maybe Java is too hard for you.
Java has excellent OOP. "get and set" methods are an excellent scheme which allows Beans to talk to each other even though they never met at compile-time. This is dynamic binding at his best!!!!!! You bind with code you didn't have will compiling... code you never even knew existed!
I wouldn't stand for writing 100 lines to do something trivial either... That's why I don't code in assembly. That said, WHY woud you be doing something trivial in Java? A Higher Power being unnecessarily stiff?
I also recently did the interviewing rounds when I graduated, everyone liked to see Java on the resume, everyone is trying it, it gets used in places that a web surfer dones't usually see (I generally hate Java Applets). I wouldn't diss Java without first seeing what it does well (mostly library support for everything under the Sun (haha I made a pun)). I wrote a simple tiered web proxy server and spider bot using Java, it took about two weeks to write. I'd be lost trying that in C or any other langauge that I currently know (C/C++/php/pascal). Anyways, if it doesn't do what you want well then find another solution.
And what you really need to do is talk to the programmers at the places you interview at. Your resume (like a college degree) is just a door opener.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
Many Java GUI's are slow indeed, but I wonder whether the fault is Java or it's programmers.
Most C++ programmers, for instance, use C++ because they value performance. They are obsessed with efficiency and finding optimal solutions.
Many Java programmers don't seem to value performance, and they're lazy (one of the reasons for using Java, no memory management to worry about), just interested in getting something done quickly (and dirty).
This lazyness also makes them use stupid algorithms and methods, which IMO is the main reason that many Java programs are slow.
The project I'm working on at the moment is a nice example. Our main "architect" is a very typical lazy programmer. He keeps saying "we'll worry about performance later". Of course, later there is no time, and later there is too many dependencies to do any optimizations at all.
The application is full of linear searches, even bubble sort! With a little more effert they would have been hash lookups and quicksort. All kinds of data are fetched each time over again, instead of using some cache to prevent this. Threads used in stupid ways (like synchronizing very large parts instead of giving some thought to what the minimum safe area is that must be synchronized).
The performance of this (GUI) app is awful. First function than optimizations is the message, but I'm sure those will never come. The (internal) users may get disgusted and turn away from our app, and Java will be blamed for having such bad performance.
As you might guess, I am actually a C++ programmer (obsessed with efficiency and performance) but I value Java too. Just a pity there are so many programmers giving Java a bad name.
Well, number crunching isn't going to be slower under nearly any language - math can be abstracted very closely to what the machine uses, no matter
how high you go up. A single "a = 1 + 1" line is only four or five assembly instructions. Pretty much every programming language will use those four or
five instructions in the same order, so you won't necessarily notice a big speed difference. This gets different once you get to more complex things,
though, like string manipluation, database access, you name it. At that point, the use of the right language is essential for performance/efficiency.
My point was that if you're doing hardcore calculations, you would not want to use Java because you want to take advantage of every benefit the CPU offers.
You also would not want to use just any language. True a= 1+1 has a finite number of instructions, however usually there is a lot of memory manipulation and special instructions that go into number crunching, in which case you'd want as low level control as possible.
I really can't render an opinion as to the browser, other than my wife reboots into linux to browse the web because she says IE is way to slow at loading her hotmail. Looks about the same speed to me, but I havent timed them.
---
> Libraries. Java has a library for everything under the sun.
Duh. Sun owns java.
//rdj. completely useless as usual.
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
Java was a great idea let down by a flawed implementation and a flawed corporate strategy IMHO. What I think is that whilst the language itself isn't really going anywhere fast, the idea behind it will live on.
Java is used by almost every major player in every major industry in the U.S. and beyond. Personal Java runs on the myriad embedded systems with their own JVM and even American Express credit cards. Java servlets and JSP run myriad websites from mail.com to First Union . Enterprise Java Beans and it's associate web server platforms has spawned a cottage industry of server platform developers that include IBM, Bea, Allaire and more. Java ships with a free fully functional CORBA orb which allows for rapid development of robust, multi-tiered distributed applications.
Simply because all the C hackers and Perl users on Slashdot aren't using Java does not mean that it isn't going anywhere fast. I haven't seen a new Linux app coded in Lisp or Smalltalk in a while, this doesn't mean they are dead.
And it seems as though Microsoft have learned the lesson from this that Sun didn't, so I expect C# to go places Java never will.
C# will be a Microsoft only language which already puts it behind Java in places it can go. Standardization of the syntax of the language is useless if all the underlying DCOM/COM+/.NET infrastructure exists only on Windows.
On the other hand, I recently wrote a testing tool for a multibillion dollar corporation that sells SCM software to several Fortune five hundred companies, over the summer and noticed that Java is almost Write Once Run Anywhere as originally promised by Sun. The company I worked for supports six different platforms and is considering supporting Linux as a seventh. Their languages of choice for building tools for cross-platform development were Perl and Java. The chances of them switching all that to C# and losing over 50 per cent of their customers? ZERO
Of course the actual apps were written in Motif/MFC depending on the platform
Grabel's Law
Allright then. You are with a company that has a web page that gets hit two million times a day. Each hit requires a rather small program to be run.
:) Go ahead, try saying to your boss, "Yeah, can we spend another 200k to double our server capacity so that I can use the programming language I'm most comfortable with, and so that I don't need to get my hands dirty?"
What will you do, write the program in a relatively inefficient language, or one that will let you keep your job?
Thought so.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I originally wasn't going to write a response to this, thinking that the whole premise was ludicrous. There doesn't have to be linux support for Java, you just write java and it runs on any platform. There is a large amount of Open Source support for Java, from the Giant Java Tree, to the Java, Jakarta, and XML Apache projects. There is even an Open Source application server called Enhyra that supports pretty much everything you would expect from an enterprise class J2EE server. And if you don't like open source, then BEA's WebLogic server runs fine on Linux.
So why is there an impression that the Linux community doesn't support Java? One thing I will say is that if you are a Java supporter, you probably aren't a strong Linux supporter. That is because Java is platform independent. A Java developer doesn't care what platform they are on. Before people respond to this with the typical FUD that Java isn't cross, platform, bear in mind that all of the open source projects above run on all the platforms I've ever used them on, without any recompilation. Xerces worked on Win2K and linux. Tomcat worked on Win2K, linux, and Solaris. I don't know about weblogic, since I haven't tries moving the binaries over (I just used the rpm on linux, install on Win2K). Development in Java is development in Java. If you do it right (meaning don't setLayout(null)), it'll work. If you're server side, you have no worries.
That being said, Blackdown supports JDK1.3, the latest release of the JDK on any other platform. It seems that the majority of the OS developers I know from the projects I listed use linux as their development machine. And let's face it, Java is giving linux a lot of credibility in the server side market because it's sinking in that spending 20,000 on a single Sparc if better spent on a cluster of linux machines running (insert appserver du jour here).
Finally, you can go ahead and say that it isn't making any headway on the desktop. Well, that's true, but it isn't making headway on any platform's desktop. Linux is no exception.
You can try to say that it isn't making headway in the embedded market, but with the KVM for larger embedded devices (>40K RAM), and real-time specification fromt the community development, you'd be wrong.
I'm surprised that JDJ would print such tripe. I'm not surprised that Slashdot twisted it even farther and threw in a bunch of FUD.
-no broken link
I stick with my statement...
Multiple Inheritance is a bad idea. I can't think of a single case where it's actually needed. The whole "amphibious vehicle" scenario is crap... it's not a boat and a car, it's a boat sometimes and a car other times.
Operator overloading is not necessary. It's syntactic sugar that causes problems. Method calls are better.
Templates are the 7th circle of hell, and to my knowledge, still are not implemented correctly.
-nate
For example, if I wanted to code a Java applet that *didn't* depend upon a Web browser running, and was able to minimize itself down to the task bar (or even hide itself if necessary) while running in the background, which Java API can I use? Furthermore, if we do strive for browser independence, how can we download the huge JVM necessary (unless we used Microsoft's JVM) across a 56k modem without the user getting annoyed at the time taken.
Note that I've read through SWING, but it seems too abstracted to handle these requirements, which would seem to apply to Linux WMs like KDE/Gnome as well. The DesktopManager public interface has an iconify.Frame method, but it doesn't seem to go far enough for closer MS Windows integration.
Getting back on-topic -- I love Linux, but feel SWING needs to expose more methods from KDE/Gnome.
--
Paul Gillingwater
Paul Gillingwater
MBA, CISSP, CISM
Just how low can you get...
So, the only thing you see when you evaluate a language is how many characters you must type to print to the console???
What is wrong with you???
Did you ever get beyond "Hello world"?
- Both the language and most of the development and runtime tools are a huge pain in the ass compared to Perl, PHP, C, and C++.
- It's still proprietary, and Java developers are very much at the mercy of Sun.
- The one useful thing it promises to do -- being a cross-platform development tool -- it fails miserably at. It is easier to write apps for Win/Unix/Mac using Tcl/Tk and ANSI C than with Java. Sure, I have to compile the C parts separately for different platforms, but so what? Typing "make <platform>" three or four times still uses fewer keystrokes than the average Java method call.
Mind you, I take a dim view of narrowminded language advocacy in general, so if Java works for you, then by all means use it. It just doesn't do anything for me.--
Proud member of the Weirdo-American community.
So THAT's why it looks like a coffee with a turd in it!
I will agree with you completely if you can explain to me why our "professional in the industry" insists on teaching like this because "that's how it's done in the industry". That frightens me more than anything else. You would indeed get points taken off for writing intelligent code, and not having setters and getters for everything, blindly and preferably auto-generated, and entirely public...
Yes, I know how OOP should work, but that's apparently not the recommended approach according to Java, or at least IBM.
And no, I'm not confused; I explicitly mentioned the different parts of "Java" (it's all nebulously called "Java", and that's a trademark anyhow, but I did specify...) that I was blaming.
And when I tried to make methods protected with JavaBeans, (to protect my data; at least the 'set' method on our NINE identical variables, mind you) it all stopped working, but that might be due to my lack of understanding, and not Visual Age. (does JavaBeans allow a protected method? Please tell me it does...)
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Well, I ain't got time to get the college fire department out on this--the fraternity guys are sleeping off last night's kegger, so I won't round 'em up for another one so we can piss on this, but how about a haiku to calm everyone down?
Java hates Linux?
Oh--what is it that you say?
Linux hates Java?
Either way, I'd say people are taking this argument far, far too seriously for a Friday morning. With all the FUD, you'd think we were talking Redmond...
--
-- Geof F. Morris
This is slightly offtopic, but there are lots of Java misconceptions by people who either haven't worked with it, or who have played with it for a day or two without really understanding what it's all about. I see a few mentioned here in user comments:
Common Java misconceptions...and too many other misconceptions to mention.
Using the Sun logo when showing a Sun story doesn't leave any ambiguity (heck, it says SUN all over it), but the swirly cup used on a generic (non-Sun specific) Java discussion waters down their trademark... kind of the whole Kleenex/Band-Aid sort of thing (though I still don't usually think of Sun when I hear 'Java', like I don't think of Kimberly Clark when I hear Kleenex - just any old tissue substance).
--
"It's tough to be bilingual when you get hit in the head."
Hehehe ;) Good point, I will say C++. But hell, when they came out with that name it wasn't "cool" to use punctuation in a name - they honestly liked it, I suppose.
Microsoft chooses everything *VERY* carefully, including names. They chose C# not for some ancient myth that inspires their programmers. No, they chose it because it'll buzzword and they'll get some press out of it.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
The Blackdown 1.3 JDK should be fine on RH7, as well as IBMs JDK, which seems much faster in the few tests I've done. And, the Blackdown JDK anyways has a -target flag, which sounds like it would compile for say, JDK 1.1.
Thanks, actually, that makes me feel a lot better.
;)
I'm not sold on Java yet, but it's nice to have some confirmation that she actually is a fool!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
I dont mean any disrespect, but Taco really shouldn't flame the forum with all his little petty, biased opinions. He knows that how his opinion would affect the forum and he didn't hesitate to use his power. For the user of java, I found it amazing that everyone, I repeat, everyone who dislike java is the sysadmin people, the inexperienced, the poor one who either can't program code longer than 100 lines in a language other than perl or can't afford the expensive java development package used mainly in enterprise environment. You know how much money a good java developer is gonna make in wall street? probably double your pay. Anyway, this java flame war is pointless. As what I see, the true software architect uses java because it can easily construst large softwares, other than spending all your time debugging in the mud and myth of C++/C.(the horror of malloc and pointers!)
90% of java's usage, in the real world, is for server side work. Servlets, JSP, server side apps that use CORBA, RMI, UDP or other protocols to do a variety backend specific chores. Not to mention app servers like Weblogics (100% java) or ecommerce packages like Blue Martini (100% java) there are others, those come to mind because I've used them. All server side, the nice thing about these packages is that most of them allow you to use either Solaris, NT or Linux , or all three for servers and as long as there's a 1.2 JVM they don't care. Well BM right now is supposedly working on a Linux port.
So Long and Thanks for all the Fish.
Second, Java is a MUCH better langage than C++. What???!! Are you out of your mind? How can you say that a language that doesn't have explicit pointers or pass-by-reference, makes you use a class instead of a struct, and generally does nothing C++ can't do, while leaving out a hell of a lot that it can do is better than anything but INTERCAL? Java really is C++--.
Third, Java on the server is the best thing since sliced bread. Let me ask you one question. Why? As in why the hell would you ever use Java server side rather than Perl, or even better, PHP. Both Perl and PHP run perfectly fine on Linux. And as for being open, Perl is under the GPL, how much more open can you be?
In conclusion, Java was designed for doing things like applets, and it does it fairly well. It most certainly could be better, but I really don't see anything else that outpreforms it in that area. Java should NEVER be used server-side. There is absolutely no point in using a language designed run on multiple platforms when it will only be used on one platform.
Boo hoo hoo! I keep hearing everyone complain about how bad Java sucks, but I'm afraid you just can't convince me of that. You have to use the right JVM of course - last time I tried the Sun JDK is was horribly slow and bloated. I've switched to the IBM's JDK 1.3 and it works GREAT. The JIT compiler really does a job on number crunching or straight-up data structure manipulation. Just for kicks, I tried implementing a B-Tree algorithm in Java and got near-native performance while manipulating trees with >1e6 strings. I'll agree that Swing feels a little poky, but really, it's not much more so than X.
And don't get me started about the language. I'll admit, I came from a procedural world, and haven't used any of the languages that OO purists always yammer about. Maybe I don't know what I'm missing. But I think Java, overall, is an elegant language and Java code is the easiest to maintain of any I've seen. Of course, the two biggest changes Java needs now are the elimination of primitive types (or transparent casting to and from corresponding object types), and templated collections. Both these could be implemented in the compiler with no change to the JVM or bytecode.
HashMap<Integer> map = new HashMap<Integer>
// Prints "3"
// Before, you needed
// map.put("ONE", new Integer(x));
// System.out.println(((Integer)map.get("ONE")).intVa lue() + 2);
int x = 1;
map.put("ONE", x);
System.out.println(map.get("ONE") + 2);
Also, you can't disparage the huge number of "libraries" that come with Java. You have collection classes, a very flexible widget set, network comm libraries from simple (Socket) to complex (HttpURLConnection), a database connectivity library, yadda, yadda, yadda. Yes, these are all available for free for C/C++ too, but they're a big part of the value of Java.
Stupid disclaimer: No, I don't work for Sun. But I do like Java on Linux and I can finally do Java development on my favorite platform without having to go get a snack every time I compile a source file.
Well, number crunching isn't going to be slower under nearly any language - math can be abstracted very closely to what the machine uses, no
matter how high you go up. A single "a = 1 + 1" line is only four or five assembly instructions. Pretty much every programming language will use
those four or five instructions in the same order, so you won't necessarily notice a big speed difference.
Well, that's actually not true at all. First, a = 1+1 would be 2 instructions in any RISC ISA, 1 instruction if the compiler allocated 'a' to a register. But that's beside the point...
For many years, and still to this day, a Fortran compiler is the only thing to consider if you need high-speed number crunching. It will provide a noticeably speed difference over C or Java.
The reason is not a = 1+1, but more complicated mathematical expressions in loops done over large data sets. Fortran is very good at recognizing many common constructs and optimizing the heck out of them (including automatically generating multi-threaded versions of the algorithm).
You could get the same effect by doing lots of work hand-tuning your algorithm, but Fortran has it built into the compiler. I did see an article once where someone spent a lot of time making C++ templates to compete with Fortran (even doing nifty things like changing implementation at instantiation time based on the size of the data set), and it worked pretty well. Haven't seen it in wide use, though.
The enemies of Democracy are
Hmm...
What has always confused me is that the Linux community that is supposed to be all-accepting is one of the most fickle 'organizations' on the planet. Wouldn't it be more logical for an 'Open Source community', whose whole purpose is to gain efficiencies in labor and knowledge sharing to evaluate each new technology based on it's merits so that the next generation of OSS can be that much better instead of disregarding it's contributions to the state of the art?
The Apache Group has embraced Java as a viable solution, producing many QUALITY Open Source applications, Tomcat, Ant, Velocity, Jasper, et al.
All you guys have proved is that (with exception to the embedded community - they have viable concerns) that you are all very close-minded. Java is an excellent technology. Evaluation of a technology based upon the perspective of the company that produced it is RIDICULOUS for any true engineer. Is it the Holy Grail? - NO, but neither is Linux nor any of the libraries or tools developed by Linux advocates. Sorry for bursting your bubble guys...
Why in forums like this are technologies ONLY torn down? Why not be objective and list it's virtues as well as failures so that the community can REALLY LEARN from what Java (and any other technology) represents as a solution, so that the next innovation can be that much better?
Thats it.
I don't think Microsoft needed any encouragement to fork a language that was a significant threat to their OS market share. Java has been a good introduction to the concepts of OO for me, as I find the syntax to be less obscure than C++, coming as I do from the world of mainframe COBOL. Think of Java as training wheels for the more powerful but easy to screw up, C++
If a language isn't sufficiently efficient, you'll be wasting a *lot* of hardware just to serve up a web site.
One thing that never fails on slashdot is that everyone is preoccupied with hardware efficiency rather than human efficiency.
The same basic principal holds true when discussing GUI's, on slashdot.
I want the computer to make me productive. How many megabytes and megahertz it requires be damned!
Not that hardware efficiency doesn't matter -- but it should not be considered to the exclusion of all else -- or even considered as the primary factor. Hardware is getting cheaper everyday. People are getting more expensive everyday.
I'll see your senator, and I'll raise you two judges.
You know how annoying it is to type that out every time?
Maybe you should try to use an editor that helps your life... you know, you aren't stuck to notepad to write Java code.
I use jEdit, and whenever I type "sout(" on a Java file it expands the line to read "System.out.println();", and positions the caret inside the brackets. Cannot get easier than that.
--
Marcelo Vanzin
Marcelo Vanzin
hmm.. this simply doesnt work: Class System.out.println not found in import... so do _you_ learned the language ?
But I agree that Java also makes a wonderful environment for developing on the server-side.
Try Sputnik7, it's an incredible site built using JSPs.
Sorry, but fsck Perl.
I am a Java developer professionally and I LOVE Linux.All the major application server vendors support linux, and with all the great OSS J2EE implementation ( Tomcat, JOnAS, JBOSS, PoolMan) that work great on linux system, it has real potential to become the dominate Java server platform.
The Linux community to date has disappointed me with their lack of acceptance for Java. Many things I use on my desktop for development (TogetherJ), system administration ( MindTerm ), and system services ( JAMES ) are java based, and work great, and fullfill the write once run anywhere promise everyone wanted.
Its not "lazy" to worry about performance later. Its best practice. The first pass at a product should get the functionality right, get the bugs out, and keep the design clean. The second pass - possibly before the initial release - should involve testing for the acceptability of performance, profiling to locate the problems, and changes to the design to remove these.
In my experience Java tends to attract people who want their code to reflect what its intended to do, whereas C++ tends to attract people who like to write obscure code for "performance reasons" because it makes them feel clever. The pleasant thing about Java is that issues with the language do not get in the way of expressing what you want to do.
Now, as to your example, doing a linear search or a bubble sort is sometimes acceptable. Linear search, for instance, is OK if the data set is small, the operation rare and the data structure you've got does not support something better because it was optimised for some other case. Similarly, recalling "get" methods rather than caching the result is not usually a real performance problem: the VM optimises the fetch away to nothing.
However, what you report is disturbing. I don't consider overuse of linear search, refetching of already fetched data, and so on, to be performance problems. They're sheer carelessness, and they mess up the structure and expressiveness of the code. They reflect a lack of thought in the design. As you say, laziness. I must say, however, that I've seen this kind of thing in C and C++ much more than in Java, as their lack of class libraries tempts people to do things in stupid ways to avoid having to write the code needed to do it properly.
Sun gets out the most important versions (whatever that means) first. Windows has been released way earlier than their own Solaris versions. Linux is a bit behind, but not much. Blackdown makes sure Linux does not only mean Linux x86 while IBM has very good Linux tools of its own to offer.
I'm not so sure about Kaffe's progress. The website doesn't get updated often, but doesn't have to mean something. Anyone?
Yes, but how does it compare to Blackdowns 1.3 JDK? Remember, Sun's "Linux port", at least the first round of it anyways, was re-releasing Blackdowns work, including their README file.
You can get 10 java engineers for every 1 C++ engineer
Unfortunately, you can also get 100 VB monkeys for every java engineer. This also supports my personal belief that C++ is 1000 times better than VB, with Java somewhere in between.
I'll bet 90% of the posts here are by people who have no real experience of enterprise java.
I think there's too may fools on this site now who haven't a clue what they're talking about...
I assume you mean "server-side" -- PHP typically runs in your web server. I've just spent a few weeks working on PHP extensions, and I can safely say that PHP is one of the worst designed packages I've ever used. For example, you have to use C, it's completely unfriendly to C++ (some of their include files go as far as using C++ reserved words as identifiers!) There is literally NO documentation for the mysterious Zend interface functions inside C -- you have to go to the (uncommented) code. There is a dementedly obsessive usage of macros. The make system requires the use of absolute paths! (though you can work around it). Java is perfectly acceptable for server-side activities and has the advantage of being a nice formal system...
The really sad part about the resistance to Java is that the excellent work of the Blackdown Project, Kaffe and projects like Java Gnome seem understaffed, yet Linux is one of the best platforms for running Java. Linux as a platform beats out most other platforms (like Solaris and NT), as seen in the latest Volano Report. And Java as a language keeps getting faster vs. C all the time. If Sun would finally realize Java is bigger than they are, Java would finally get the recognition it deserves.
And in closing, Java on Linux is dope.
F.O. Dobbs
Portal-Potty Founder and Mr. Brown drinker.
Commander, you and most posters to this sound suspiciously like shortsigthter hacker whiners.
Java and EJB are truly ushering in the era of component based software development, and everyone here seems to be so focused on low-level code wanking that you're all blind to it!
As cycles and memory become free, the only thing that will matter for a vast majority of the application development space is scalability, stability, designability (OO), maintainability, and runnability (hardware independent, dynamic runtime, componentization).
And from a purely linguistic standpoint, Java is quite elegant. I too came from a C background, accustomed to system programming. In terms of elegance, Java is to C/C++ what Katheryn Zeta Jones is to Rosie O'Donnel.
I'm shocked that this community, usually quite forward thinking, is so myopic in the area of the beautiful Java language and platform.
Come on folks, look up from your wanking.
I prefer Java over many other things, and in addition to many other things.
That said, one thing that I think is painfully slow on Java is the GUI.
I think Swing is the most advanced GUI toolkit I've ever seen. But it is not noted for being fast. (I've never heard it winning any speed contests -- except maybe for produtivity.) Of course, computers are getting faster and cheaper, so this becomes a less important factor every day.
I'll see your senator, and I'll raise you two judges.
Java is built around scaleability. RMI for example, is very easy to implement for ANY app. I work on a Java server that will potentially route phonecalls completely replacing a PBX. It will be done using _ONE_ PC. If we need more, then its VERY easy to plug in another box for the job. This is because of Java's scalability.
Yes this can be done in C++. Yes it can probably process a few more calls per second. However the debugging would be 5x harder and the entire design would have to be around scalability from the ground up.
a small example
...
...
public class Person {
private int Age;
private boolean senior;
public void setAge(int foo) {
Age=foo;
if (foo > 65) {
senior = true;
}else {
senior = false;
}
}
obviously this is a very contrived example, but you can easily see the problem in making the class vars public. it was very trival in this instance, and in the programs you have written it prolly didn't matter - but it is good to learn propper OOP principles and apply them all the time.
---
/bin/fortune | slashdotsig.sh
For number crunching, you usually want to use ASM for the native processor. If you're talking about unzipping files and such, I just stick to Java. Keep in mind though that a lot of Sun's API is in native libraries. This is the reason why its not slow.
Funny how you say that the GUI isn't slow, because thats where the vast majority of complaints come from! I've not experienced it either, and I also believe Java's Swing setup is the most advanced design for a GUI API that exists right now.
Everything you mention (Perl, ASP, SQL, *.*) is based on procedural programming. Java is a step above this and relies on OOP. OOP is more difficult and require more planning and sometimes, yes, it does involve writing a lot more code for trivial projects (it can be the other way around for non trivial projects).
When the project you are working on will have 200,000 lines, you might find your Perl scripts are killing you. Meanwhile the Java programmer will come to work everyday smiling.
Java is designed to handle complexity.
The truth is, Java scales better as a language.
I don't see why java and linux are neccessarily mutually exclusive. Yes there are zealots on both sides. I have been using linux since 94 and I have been developing exclusively in Java for 4.5 years. I came from the standard Unix C/C++ background before that and also have done some perl. The main reason I have stayed with developing in java is that I am 2 to 3 times more productive writing java code than C/C++ code with the end result being cleaner, tighter and more bug-free. Yes java has performance issues, but if you write slow code in any language it will come back to bite you. Most of java's performance gotcha are well understood and can be coded for. I like the performance of both the Sun JVM 1.3 and the IBM JVM and it just depends on whether I am doing client or server side stuff as to which one I recommend. Most of the people who post the standard Java sucks posts have: a) probably not used it since 1.0 b) wrote a couple of applets using multi layered layouts instead of grid bag c) fought the browser wars d) haven't converted to server side java. To me well written servlets or jsp is far easier to maintain then most perl cgi I've seen. Perl can simply produce some of the most god awful spaghetti code in the hands of the unexperienced and/or book programmer. This can be a nightmare to fix. Anyway, off my soapbox now.
Write a class and put it in a utils.*; package that lets you print like this
utils.Printer p = new Printer();
p.rint("print this");
Oh, that's not short enough? k...
p.p("Print this");
Oh, that's not short enough? Make the damn thing static so you don't have to instantiate the class.
Put it in java.lang, if you don't want to import it.
Be creative with that 133t "hello world" app.
TK
Text I/O is a bitch in Java. That's unarguable, to me. I have to look it up every time I need to read from the console. But Java wasn't really meant to be reading from the console. If I want an easy way to read text input, play pattycake with it and then send it to stdout, I'd be using Perl, or C or C++ for more complex apps. What Java has going for it is (when coded with code OOP style) a very well-thought out and fairly consistant object oriented structure that is pretty quick to develop in, thanks to good error checking at the compiler level and fun stuff like garbage collection. It also has a well-defined framework for writing cross-platform GUI's. That doesn't make it well suited to every task. But C, C++, Perl, Lisp, or Motorolla 68K assembler aren't suited to every task either.
Where it fits a specific need or makes it easier to solve a problem, I love Java. Otherwise, chuck it and use what's appropriate. Geeze, and I hope you can force that manager/admin person to look up what OOP means some time. . . ."
"That's how it's done in the industry" == "All the other lemmings are doing it. .
"Sweet creeping zombie Jesus!"
--
Find free books.
that's because you are constantly calling cmdrtaco.cannot.spell.worth.shit();
to != too;
Interesting. Since we were encouraged to use Visual Age for Java, and it explicitly bugs us about capitalization conventions, (as well as the fact that all of our project have to follow the same fascist style guidelines) I figured this sort of thing would be promoted to a compiler error, or at least a warning.
Also, while I'm at it, I'd like to say that the implementation of 'stdin' is completely hideous in Java. Did they actually expect anyone to use this?
I mean, try to write this in Java...
10 PRINT "What is your name?"
20 INPUT NAME$
30 PRINT "Hello, ";NAME$
...and then explain to me how 'friendly' it is.
For all its faults, that's one task I'd gladly do even in C++...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
IBM's implementation of Java on the AS/400 (sorry, iSeries) does this. It's a shame nobody ever mentions the iSeries when discussing Java -- it has to be by far the best implementation of the language yet.
I've got the idea that many sites do in fact use Java, but they don't use applets. The only Java they use is in the backend, eg. servlets.
Part of the problem with Java is the crappy implementations.
Why program something if you know that your users are going to have the regular crappy netscape java vm?
My experience with java as a user have all been crappy. It seems like the implementations are not the same and that you have to install the correct one to get your programs to run. Sun could alieviate part of this problem by releasing the "official" version under GPL thus making it more of a standard.
As a user I'd prefer it if programmers just wrote in c++ and recompiled for a different operating system or cpu.
---
/bin/fortune | slashdotsig.sh
If you don't need the accessors to be public, don't make 'em public. Private or package-visible accessors are still useful, and you can always make 'em public later. The general rule is that you should only make methods public if absolutely necessary.
But if you do use public accessors, then changing internal representation isn't a big deal. In your example, if a bunch of external code that you don't want to touch uses the variable as a double, then you can leave the public accessors handling doubles. They can look like this:
FixedPoint foo = new FixedPoint();
[...]
public double getFoo() {
return doubleFromFixedPoint(this.foo);
}
public void setFoo(double foo) {
this.foo=fixedPointFromDouble(foo);
}
If necessary, you could then add special accessors for the FixedPoint representation.
This is the advantage of accessors over public instance variables; internal representation is independent (or in the jargon, decoupled) from API. But public vs private is always a designer's option.
I have to agree with whoever said that IBM was doing more with Java than Sun. Two or three of my colleagues are doing security research in Java, and they all use IBMs tools instead of Sun's.
I mean, think about it this way. If the Linux community is snubbing Java now, just when we're starting to see viable server implementations, what will Sun's response be when the Linux developers start complaining in 2007 that Linux's Java runtimes and support are woefully inadequate, while Java runs like a charm on virtually everything else? How will Linux fare in the business world if Java becomes the language du jour for most programming needs and works well on everything but Linux?
Java is showing more and more promise, and is maturing quite quickly, despite all the jokes to the contrary. Yes, there are still a lot of things Sun needs to fix (Swing, graphics, and many other desktop/UI elements are still decidedly sub-par) but Java is getting better, and won't be going away anytime soon. If nobody in the Linux world cares to use Java, what will Sun care about supporting Linux, now and in the future?
$ man reality
Obliteracy: Words with explosions
C++ is WAY MORE ineffcient than C, you should be writing all your apps in C, with inline assembler where there are bottle necks. My guess is you are not that obsessed with efficiency. BTW there is a nice HashTable class in Java, so if you use that instead of a hand written bubble sort, you should save time and speed things up. Its one of the collections classes.
So Long and Thanks for all the Fish.
I think Garbage Collection has gotten a bad rap, actually. Just because some Lisp implementations in the past have had bad garbage collection doesn't mean that all modern tools do now.
Although I love programming in C, I think that Scheme is a beautiful language too. I couldn't find that many uses for it besides writing Scheme in Scheme, but maybe that's just because I'm not used to it in the first place.
But making everything an Object (including functions) is a very cool approach, and having lists built-in to the syntax is very handy as well. I think that with a Scheme-like approach to this sort of thing, data structure building would become trivial.
Since this sort of thing was hacked on to Perl later, it makes Scheme style programming very ugly. It's possible, because I've tried it out, but not pretty. However, Java doesn't really support this well. Inner classes are not the same, and you can't really get a closure...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
P.S. Who cares about the java-language, its the lib that is sweet!
Someone you trust is one of us.
I've seen that one already, and it's pathetic. I want something similar to this, or this, or perhaps even this.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
They hate M$. It is my belief that $un will do ANYTHING to goad MS. Even if it means throwing scraps to Linux.
Why not use a C-based object-oriented language that has been evolving for over a decade with an open standard that was first drafted in 1994? Yes, I'm talking about Objective-C and OpenStep, which is the most important technology behind Apple's new Mac OS X and has open source efforts (beyond what is already available in gcc, that is) available at www.gnustep.org. It's worth a look for anyone who is interested in serious object-oriented development.
As a developer and full time M$ hater i've found that Linux and Java are an excellent combination. First Java is an excellent language to program in, it's clean and aids in the production of good quality code in a short time frame. Ever wonder why the windows platform is sooo buggy, take a look at your typical M$ programmers C++ code sometime. The fact the Java is cross platform has allowed me to use Linux as my developement platform of choice even though the other people around me use windows. In the last year or so Linux has been promoted to a first tier platform in the Java world, now instead of waiting months for the latest version of the JDK, we have the choice of three good ones (Blackdown, IBM, and Sun's).
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
I spent a long time writing code in Turbo Pascal 7, and some of it was object oriented. Basically, it took me a while to figure out how it worked, and I liked it, but it still had some problems.
However, I'm fairly convinced that those problems stem more from hacking an object-oriented model on top of a procedural programming language than anything else; I'll find out if I ever re-implement that code on top of C++.
(I had a pretty cool screensaver that I wrote in a week in Pascal to test out and learn the OOP stuff; however, I had some memory leaks because it wasn't easy to identify which type I was deallocating... I'm pretty sure I could fix that now, though.)
Borland codes some pretty impressive stuff, but no one notices. I'd kill for a better linker, for gcc...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Then do something about it and stop complaining. What do I mean?
.. );
PrintStream out = System.out;
now you only type
out.println(
For those who have forgotten, C++'s "cout" and "cin" are merely iostream shortcuts to stdout. As far as the complaint about "System.out.println()" is concerned, has anyone compared the code necessary to do multithreaded programming, sockets or UI code? Call it slow for use as an applet. Call it constrictive because it doesn't have a template metaphor. Do NOT call it overly verbose because it doesn't have cout.
Which would you rather have: a 2,000-line program in Java or a 20,000-line program in C/C++ so that you can use printf() or cout? I'll take the former thank you.
- I don't need to go outside, my CRT tan'll do me just fine.
Ug. Delphi pretty. Delphi fleet of foot. Delphi compile fast. Delphi make fast code. Me like Delphi, so you must like Delphi. Me hate Java, you must hate Java.
meh.
I haven't really looked at Object Pascal or Delphi yet, but I've heard many good comments about both. I've programmed in Turbo Pascal in my earlier days, and I help students with beron-2, so I know how Pascal code reads. Still I prefer c++ or Java for coding, just because they somehow feel different.. I guess it's just a matter of taste.. oh well...
I wasn't saying that Java is THE only good language out there either, it just has some nice advantages over c++ programming. But that doesn't render c++ obsolete either. Delphi's user base is large and profound, and I'm sure it's a very decent language. Java has been playing the game totally differently, making browsers a possible platform to run applications right from the web, which ofcourse contributed to the hype that SUN created when it launched Java. They have different interest groups. Delphi benefitted also from the fact that it could take Pascal coders along for the ride, and there's nothing wrong with that. Java tries to take on and convert c++ coders.
Anyway, I think you should allways use the right tools for the right job, and search for new possibilities wherever you can. I don't really think there will be a THE language in the future. There's allways something new around the corner, ready to stirr up things again.. and wether it's Borland or SUN or MS or Mr John Doe's 10 Cents Enterprise, I don't care one bit.. Borland's JBuilder is one of the nicest applications I've seen in a long logn time.. too bad it's still so slow.. I hope they will fix that soon.
With great power comes great electricity bills.
Swing is actually decent. Considering the whole cross-platform ideology of Java, swing does a bloody fantastic job. GTK would go against all this.
Redundancy? C'mon, it's ONLY 3 LETTERS. Adding things like that actually help understandability IMHO
No good browser JVM's: No shit. "There's a bad c++ compiler, so c++ sucks?"
I agree with the rest.
Better to stay silent, and let people think you're an idiot than to open your mouth and remove all doubt
When I work on a program, I tend to think of the procedure that it follows. Somehow wrapping up abstract procedures into a bundle called an 'object' doesn't make much sense to me. Sure, I can write programs in C++ or Java that follow my conventions, but in that case, I might as well use a different language. And it still doesn't help me when I'm jumping from object to object in someone's program, trying to figure out what each is trying to do to each other.
Anyway, that's my chief gripe with the two. (My other major problem is with things like data hiding, which is, in my very humble opinion, complete crap. If I want something hidden, I'll bury it. I really don't need a compiler that tries to protect me from myself.) Maybe the language is decent enough, but as I have yet to see a Java or C++ program that was easy to read, I'm not too inclined to bother with it. C, on the other hand, as long as the confusing parts are commented, reads like a book. It's much more enjoyable to read and use.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
WRONG!!! It is often much faster than C. Runtime optimizations tend to be far more EFFICIENT than compile time optimizations. What, did your project to port Quake to Java dissappoint you? For what it is used for, Java is fast. C is for sado-masochists who have no sense of style. They are the toliet cleaners of the programming world.
I have to agree with your remarks about PHP vs. Java.
I spent some time learning PHP and then trying to code a fairly complex system in it -- actually a framework for building a complex system. One bit of common wisdom concerning PHP seems to be "don't overuse OOP".
In fact PHP's pass by value semantics can cause intractable problems when trying to create objects within the constructors of objects that are themselves constructed from the constructors of other objects, etc. At various points you end up not referring to the same object you thought you were -- because of copy by value semantics. And the particular problem I'm thinking of is not (AFAIK) solvable by any amount of expressly stating that you want references (&).
I would still use PHP for many types of things.
But I'd use Java for a really complex application, like an accounting system, maybe. There are other things as well. You can make each session be a thread in Java. Even serializable. This has a dramatic impact on the way you can write your code if the session on the server side can be a thread. The thread can be deeply in some subroutine call that emits the web page and waits for the result to be submitted. Meanwhile while waiting for the result, the server might serialize your thread and swap it out. But when the user finally responds, you then continue execution where you left off, in some deep subroutine somewhere, will your stack and all local variables intact. Not that this is the only way you can approach web programming in Java, but it illustrates some of the flexibility.
I'll see your senator, and I'll raise you two judges.
I actually don't like Perl too (well, it can be very useful for the very specific tasks for which it was initially intended, but that's it), and I'm not surprised that you now favour Java. But Python and OCaml are a very different matter.
we have Perl. Now, what we need is for someone to figure out a way to write "Perl Invaders".
Carefree highway, let me slip away on you.
Personally, writing things like foo.insertanobjectattheendofthislist(object) doesn't really appeal to my sense of elegence
I've heard this argument throughout this thread, and, while some other arguments are valid, this one is absurd. Java doesn't force you to name your methods in any way or fashion. While the convention among Java developers is to name methods so that it is easy to see what action they perform, you can easily write "a.b(c)" if you really wanted to.
Yes Java has preformance problem for its VM approach. It's a trade-off for portability, Oracle has seen importance in portability and started to migrate its product to Java - e.g. installer and embedded language in Java.
However, I wonder why people always compare its performace with C++. C is faster than C++, ASM is even faster....if your needs is performance just go for alternatives, why bother comparing unrelated issue?
Java can create real reusable code called beans. It's quite difficult to distribute reusable C++ classes. With beans you can actually create blackbox/resellable objects and distribute them.
I don't want to spam you with the advantages of beans. Go to IBM Alphaworks, download a bean(e.g. LEDclock), follow the readme to create an app with beans in VisualAge for Java. You don't need to write a line of code to get things done with beans!!
Don't believe me, try it.
Hep Cmdr, with all due respect, are we talking about the same thing ?
I am a Java coder and I code under Linux using IBM's excellent JDK1.3.
This is fast so why do you say it is bloated, slow or whatever else ?
Do we speak about James Gosling's language above Linus Torvald's OS ?
Is it forbidden to call myself one of the Linux Lovers if I don't jilt Java ?
Come on : I think you really desserves -1 karma for either trolling or flaming innocent Slashdot users.
You may mod me down but I *do* feel hurt by what I just read.
--
Trolling using another account since 2005.
Queston: Why didn't /. fight the Cease and Desist letter from Sun? If you're so sure you would have won, then why not fight? If /. is going to lecture and preach about the evils of companies and their licensing, then shouldn't it be practiced as well? I realize its a question of money and time, but doesn't it make sense that a site so bent on advocacy should take up the banner when given the opportunity?
mr.nobody
--Don't you wanna go where nobody knows your name?
is it for this that Netscape died?
was it for you? was it me?
did i use too much VB?
is that a hint of accusation in your eyes?
what have we done Sun what have we done
what have we done to Java
should we shout should we scream
"what happened to the cross platform dream?"
oh Sun, Sun what have we done?
A little Pink Floyd for ya
Capt. Ron
crazy dynamite monkey
Only requires a small program to run?? I've worked on several ecommerce type web sites. All of them have required rather large complex programs, usually some combination of talking to a database, mainframe and some other system like SAP or people soft. I've done it in C++ and Java. Actually Java is more effecient because once your running something like Netscape Enterprise, OAS or even Weblogics, the servlets usually are threads. So there is only one process with multiple threads.
Yes you can do this with C++, but you end having to write alot of stuff yourself, so now you've spent time re-inventing the wheel, thats inefficent as well. Hey if all you are doing is static web sites then a little perl and javascript is all you need.
So Long and Thanks for all the Fish.
Other then that, my only problem with Java is that the VM in Netscape is crap
Thats not Java's fault. Its Netscape's. Also, you can REPLACE the VM in Netscape with whatever you want. You can even run applets with Swing components in them with the proper setup.
As for Java being slow, there is a JIT (Just In Time) compiler for it, as well as numerous native code compilers for Java.
I have not experienced Java's slowness as ever being a serious problem. If I'm doing number crunching, I use JNI. If I'm doing network stuff, then the interpreter is always faster than the networks ability.
Didn't you know already? C++ itself was a hoax. Sun just had a little more humour and made Java even worse, running it on a virtual machine, adding garbage collecting, and designing the miserable Javascript language.
____________________
Ni!
I suspect many hackers (and that certainly covers a lot of Linux users) don't like Java because it is often a little too 'friendly'. There is sooo much stuff going on that you don't control (eg garbage collection) and it is really hard to tweak. This really goes against everything that 'C' programming is all about. Oh yeah, it is really, really slow. And big.
Moderate this article (-1, Flamebait).
-no broken link
No different than using get() and set() methods on private data in C++... and an equally bad design decision in most cases.
The purpose of a class' methods are to provide an interface that does something useful. If the interface can do nothing more useful than return a float, then it is a poorly designed interface. Why? Because the abstraction provided by get() and set() is paper thin, and if it _isn't_ just returning a field, then it is also misleading.
A bazillion lines of code that use get and set is poorly written code, not a demonstration of the power of abstraction.
For example, you have a linked list class. Do you provide gethead(), sethead(), gettail(), settail()? Or just insert()? Which is more useful, and provides a better abstraction? Do you provide get_number_of_entries(), or an iteratior?
Abstraction is only a good thing when the abstraction is meaningful.
The enemies of Democracy are
The pithy little editorial quips tagged at the end of the summaries are often entertaining or insightful. But, as is increasingly the case, these geek-cum-"journalists" often overstep their boundaries (on tired topics no less) and bore us with their opinions there. It's time for /. to decide if it ever wants to be taken seriously as a news source.
Every time someone makes the statement "hardware is getting cheaper / faster" everyday I see red. Yes it is getting cheaper and faster. But apparently not fast enough to keep up with the lazy coders who make such statements. Because it is people who make such statements that dont care too much about making the best of existing resources and have the Microsoft-like attitude of "who cares about the end-user - using technology x makes my life easier"?
There is no such thing as luck. Luck is nothing but an absence of bad luck.
I didn't claim that Python's whitespace-based indentation was rediculous at all. What I said was that people who won't use Python simply because of they don't like the idea of whitespace indentation are being rediculous, and missing out on using a great language.
I like Python, it's one of my favourite languages...
Is it me, or is Java worse than the B&D-style languages that have come before it? I think it actually has more annoying keywords that always must be strung together than any other language I've ever seen. And I can't fix that, because it has no macro system!
// considered harmful in Java
#define const public static final
Then I had to use a useless GUI-building tool that generated horrific code... In all fairness, I shouldn't blame the "Java Language" for that, so I'll blame the "Java API" and "JavaBeans" and IBM for that one. But still, the generated code was really ugly, and the suggested design methodology is horrible.
Am I the only one who remembers the 'data-hiding' portion of OOP, where you don't have public getFoo and setFoo methods for everything?
And what's with the fascist standards with regards to var^H^H^Hfield and func^H^H^H^Hmethod naming conventions? Really, WHAT IS THE DEAL?
For a language that is theoretically based on C++ and then C-style syntax, Sun has managed to break every single decent convention we ever had, and introduce several new, painful ones. And they aren't finished redesigning it, either, so why try to target a language that's slow, bloated, and constantly in flux in the first place? Managers are just dying to sign up!
So, I blame Sun for trying to embrace-and-extend C++ of all horrible things, and I blame Microsoft for trying to follow their lead. Whatever the "next-generation" programming language is, it'll be far uglier and slower than attempting to hack it all on top of C again...
But heck, maybe it'll increase the demand for programmers again, right?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Speaking as someone who "would rather write programs that write programs than write programs", I have to take a stand in the "form as function is EVIL!" camp. If I'm emitting code from my program to the compiler, noone's ever going to see it, so why the hell should I care how it looks?
Disclaimer: I have used TUTOR (where not only do you have to indent, but each indentation level is denoted as [PERIOD][TAB]), so that probably explains my reaction.
Just junk food for thought...
Well, most of the programmers out there are writing in c/c++ and java and I think that's why comparisons between those languages are important. Even if there is a super-dooper language foo, if no one uses it, it's mostly an academic discussion (and trust me, you don't want to argue about semantics and shit - I just finished a problem set about it and it hurts your brain).
On a side note, its kind of annoying that the discussion has turned into Java sucks/blows nuts or is da bomb. Look, Java is good for large subset of programs and it sucks for some applications. What the discussion should be is why is the JVM support in Linux crap (although much much better than BSD). It seems that most free JVMs in linux is far more unstable than free JVM in windows. It is true that blackdown.org is doing a decent job porting but performance-wise, I'd always use IBM jvm in windows rather than blackdown JVM in linux. (comercial JVM is another story though - for a crude benchmark look at http://www.volano.com/report.html)
On another side-note, the article mentioned is more specifically geared towards embedded-jvm and linux. READ THE ARTICLE BEFORE COMMENTING PLEASE. And it is true that for embedded stuff, Java is a not a good choice right now for various reasons. For embedded stuff you want strict memory management and more lower level controls which Java doesn't support. I disagree with the article saying that linux's main strength is in embedded stuff though, I always thought linux's main strength lied in server-side stuff.
As of the latest (and even not so latest) jvms from sun and blackdown it's stable, fast enough for just about anything, is free (beer) and has apis for *everything*. The industry support behind the platform is huge (bigger than for linux, for instance) and it's gaining momentum.
Programmer productivity is heaps more than with C++, and don't just believe the average pimple-dotter that it isn't - actually line up a good java team and a good C++ team and see who churns out more production quality flexible code quicker. I guarentee it won't be the C++ team. And don't tell me about python. I use python (JPython acutally) for *scripting* and *rad* because *that's what it's for*.
And if you want the latest on linux, add
deb http://www.mirror.ac.uk/sites/ftp.blackdown.org/ja va-linux/debian woody non-free
to /etc/apt/sources.list (if you're an 3l337 debian user).
You can even have it read your poxy GTK+ and KDE themes with skinlf. That's right! your java app can have a p0rn skin so you don't get lonely at night!
Yes, there are more 'interesting' languages out there. Hey, I prefer plan9, but I run linux because you just can't get any software for plan9. Same with java. Solid, supported ecommerce libraries for ML? yeah.
Sun doesn't think it should be free yet, and yes they have arsehole lawers. We'll see how that changes in future. In the meantime don't trash what you obviously don't understand.
Grrr.
I personally dislike Java 'cause I happen to know and use Python and Objective Caml. Enough said.
From 1.4, sun will have simultaneous releases, which *should* be pretty similar across all platforms
Better to stay silent, and let people think you're an idiot than to open your mouth and remove all doubt
I don't think anybody is complaining about lack of support from Sun, just stating it as one reason Java on Linux hasn't taken off. I personally don't really care if Java is supported "well" on Linux, as long as the odd Java app I need to run works.
The Oracle 8i installation, for example, is in Java. It runs like crap, but it runs. Since I don't run the install all that often it's good enough for me.
As for being hypocritical, I hate Netscape as much as I hate Java, but I use Netscape because I need it. I don't need Java. It offers no compelling advantages for me, since I con't really need to write software that runs under Windows. My stuff (written in C and Perl) runs seamlessly on any Linux/Unix. It's fast. I've got all the libs I need.
What does Java offer me? Well, I give up performance and most of the APIs that I like in order to gain cross-platform support that I don't need. Not likely.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
One thing I miss in C++ are Java interface. They are extremely simple and from a developper's point of view, extremely lightweight.
For many complex designs, they are far superior to multiple inheritance. Sure, you can find trivial cases where multiple inheritance would fare better, but for complex systems, interfaces are far better.
Java was a great idea let down by a flawed implementation and a flawed corporate strategy IMHO. What I think is that whilst the language itself isn't really going anywhere fast, the idea behind it will live on.
Probably the biggest problem for the targets that Java was aimed at is the fact that performace wise, most Java sucks compared to a good native code implementation. Sure there has been a lot of progress in improving execution speed, but on the whole, Java is still just as slow and fat as Vladinator's wife. This limits the scope of what applications can be written in it.
As for the language itself, well, it's fairly well written, and probably a matter of taste as to whether or not you like it. Personally, writing things like foo.insertanobjectattheendofthislist(object) doesn't really appeal to my sense of elegence, but some people obviously need reminding exactly what each method does.
And Sun really aren't doing anybody any favours with their constant battling over the ownership and direction of Java. They've managed to piss people off enough so that some people won't touch Java as a matter of principle, which is even more rediculous than the issue of say whitespace in Python. And it seems as though Microsoft have learned the lesson from this that Sun didn't, so I expect C# to go places Java never will. It's a better language design IMHO, and it'll be a genuine standard, not a stick for Sun to beat their competitors with.
Actually, MS (or at least Bill Himself) did sue over the Bill-of-the-Borg T-shirt for using his likeness without permission. That's why the original manufacturer isn't making them anymore. Another manufacturer picked it up after the supreme court ruling that parody is fair use. It's kind of sad isn't it.
"Java(TM)", "Javalag(TM)", "Javacrash(TM)", "JavaGPF(TM)", and "Javasegfault(TM)" are trademarks of Sun Microsystems, Inc., LLC, CRAP, etc.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
A good friend of mine works for a company here in Austin called ibooks.com (their concept is pretty cool btw, so I don't feel too bad about the blatant plug ;-) ). Their entire backend is Java, from what I've heard. They're running everything on big AIX boxes from IBM (well, could they come from any other place? ;-)).
The ``site engine'' has evoked some interest in other companies that would like to use it for things besides selling books (e.g. Dell and tech documents, so says the grapevine). If their code had been written in really AIX-specific C or C++, it would take far longer to port to say, WinNT/2K running on a horde of Dell x86 machines, than Java will. Now, I'm sure that some stuff will have to be tweaked for the slightly different environment, but if I had to guess it would be a 2 week process instead of a 2 month one.
So that's one reason why portability is always good: you don't know where your code may end up having to run.
--
News for Geeks in Austin, TX
You can always put in your own garbage collection calls yourself, which would solve the automation problem so you wouldn't feel at the mercy of the VM.
This Wiki Feeds You TV and Anime - vidwiki.org
People who work digging ditches all day tend not to see that there's a world outside of the ditch.
Most IDE's suck.
But the best IDE's were the ones based on the Smalltalk or LISP idea of programming -- an interactive environment with many different views of your source code, with dependency analysis tools, and immediate feedback when attempting to write code (whether in a scrapbook/immediate window or as part of a class or form.)
Most of the add-ons to emacs are tools that provide features of the above nature.. The oo-browser, speedbar, the macros in JDE, a couple of dependency analyzers, etc. But even these tend not to be integrated so well as IBM VAJava or Cincom Smalltalk, or even IBM VAC++..
Stu
-Stu
I'm gonna have to disagree with that bit, but then of course, why else would I reply if I agreed with it all? :)
Yup, you could use interfaces to do multiple inheritance, but in that respect, most classes should have an interface counterpart. The InputStream and OutputStream classes should have been interfaces, but it seems Sun didn't realise providing a simple interface and providing a useful base class was the way forward, and just clumped them together (though they seem to learnt that lesson with the Collection/AbstractCollection classes).
Why can't I define a data store which can be written to and read from in an stream based manner by implementing a couple of interfaces?
Even if they were interfaces, we couldn't take advantage of using the predefined methods in the base stream classes anyway, so this isn't even much of a solution anyway.
the vaguely interesting wombchimp.
Chances are if you do any kind of online securities trading at a major brokerage (Schwab, ETrade, TD Waterhouse, DLJDirect, etc.), then your order is being touched by Java somewhere.
If you're using a VISA card, then chances are your transaction is being touched by Java somewhere.
If you buy anything at the Home Depot or any NIKE product, chances are, your transaction will be touched by Java.
If you work as a trader at any major brokerage, chances are that you're dealing with a Java system somewhere.
Java is producing results almost everywhere, and usually on the server. I think you really need to wipe the tint off your goggles.
Speaking of which, let's talk Smalltalk:
- Every major car manufacturer depends on it (Honda, Toyota, Ford, GM, Chrysler) for either backoffice systems or realtime production monitoring systems
- Several utilties (Florida P&L, Tokyo Electric, etc.) require it to monitor their powergrid and perform billing.
- Several nuclear facilities use it.
- The DoD uses it for their AEGIS military simulation system.
- Sprint's ION service is completely Smalltalk
- Several transportation/shipping companies depend on Smalltalk for their routing and logistics (little companies like FedEx and OOCL)
(Of course, C++ is running a lot of things too, no questions).
-Stu
--
A mind is a terrible thing to taste.
"A mind is a terrible thing to taste."
yerricide is extremely wrong, as this article about SuSE and TurboLinux bundling Java and this article about Mandrake Linux with Java and several other distribution agreements as listed here on Sun's Java on Linux page.
class c{} //nine characters
is trivial.
TK
I'm a C++ coder, but I also love Java. I can whip out a GUI-type Java app in a fraction of the time it takes me using, say, Visual C++ (I have to admit that I haven't done any apps under GUIs other than Java and Windows. Maybe others are just as easy.) One advantage Java has is that someone has written an API for virtually anything that you can think of, so throwing together an app is mostly coding some stuff in the interstices.
Oh my, you must be right - let's see, a String, List, and other structured data are all... OBJECTS! Imagine that. And function references can get quite ugly, although as mentioned in another reply, try using java.lang.reflect.Method - which is, you guessed it, an OBJECT! I guess passing objects around is really limiting. Except, of course, Java is object orientated.
Oh my, you're right! There's absolutely no way for a class to implement the interface itself. That would mean something like...
public class MainWindow extends Frame implements KeyListener, MouseListener, MouseMotionListener, WindowListener
There's no way to implement the interface in your main object at all. Can't be.
As for passing tuples, yeah, that can be a pain. Try using an Object[] array unless you really have a variable number of return results. And not surprisingly, creating a new class is actually the right solution. Although I really see no difficulty in just making a new .java file for the new class, or, depending on circumstance, using a public inner class. I suppose typing
public class Tuple {
public int number;
public String text;
public boolean bool;
}
Is really difficult. And creating a new file - my what a hardship. Of course, you could also add those lines inside the class that returns it - it would be an inner class. But given your apparent knowledge of Java, you already know that, right?
Um, OK, yeah. There's a useless and incorrect rant. Java exceptions are insanely useful, far more useful than error codes. And you can bubble them up - I have a method that reads in a file and interprets the data. One of the exceptions it throws is IOException. Should an IO error occur, I don't have to check it in the method itself. The load method completely ignores the possibility of an I/O error, since the error would prevent it from successfully loading anyway. Since it doesn't update any class data until after it's finished with I/O, it's safe to handle it that way. As soon as it has succesfully loaded data, it does some post-processing and then updates internal data structures. Should there be any error, it throws an exception.
Next question: Why would you ever want to ignore an exception? Doing that strikes me as bad programming. I suppose you ignore return codes in C programs too. If the method claims it can throw the exception, there's probably a reason for it! And if you "know" the exception will never be thrown, then just
try {
// Do Whatever
// do nothing, it'll never be thrown
} catch (UselessException ue) {
}
Maybe the requirement to list exceptions that your method throws is just to help make sure that when you use the method elsewhere, you know what it'll throw? I know, that would be something like being forced to document error codes that your function returns. A real hardship.
(Also, if you want an exception that you can safely not catch, make it extend RuntimeException - RuntimeExceptions don't need to be caught. However, if they make it all the way to the top-level (ie, no function ever catches it) they will halt the program. Often, this is a good thing - usually continued running would be bad anyway. And if not, then, well, you should have caught the exception!)
You are in a maze of twisty little relative jumps, all alike.
...the surprising thing is that more people aren't "jilitng java". I happen to think Java is a wonderful and useful language...to teach to new programmers as a fresh language. It's not particularly useful for anything else. It is, admittedly, a joy to program in--assuming you're not being graded on results, but on the quality of your code (ie, you're not doing it "for real").
:-) All those icky applets that didn't silly graphic effects (waves and so on) seem to have died out (yes!). Most useful stuff is client side anyhow, and PHP works nicely for that. What *IS* the point of Java?
:-)
To be honest, what *IS* Java's "killer app"? It's main claim to fame is that it runs everywhere--but since it's slow enough few people want to run it ANYWHERE, that's of dubious use.
I mean, is it just me, or is this language about as useful as, let's say...Smalltalk? And I don't mean to offend any Smalltalk fans by that!
Final is a much cleaner keyword than const. It is much more powerful too.
No, you can't screw up a big project by editing a single file in Java because you don't have macros!
What will happen is that compile will fail on this one file... period. Even if you use the comment trick... Other files you try to compile will clearly point at the bogus class... and you'll never have any problems...
Macros are evil for large projects... It is enough that a remote library somewhere redefine a MACRO for you and you are in MACRO hell...
In fact, you could screw a big project by doing a small redefine somewhere and it could take months for the engineers to find your hack. Macros are just evil.
Try working on larger projects... you'll see.
I've stopped taking client side Java seriously
years ago.
Its at the server end where Java really shines. I've tried many application development environments, but you just can't beat Java for
fast, scaleable and easily maintainable
web apps.
There may be hope for the client side yet, but
last I looked Swing was still too slow for
comfortable use on the Linux port of Sun's JDK.
You are an idiot. Go write some obfusicated code with your crap language of choice and waste everyone's time. Else, open your mind and learn Java
I had no idea Sun was such a butt. (*sound of opions forming*)
-Derek
Piss off, it's early in the morning, and you knew what I meant. Stupid nitpickers.
---
Play Six Pack Man. I
This is only in relation to your 'unrelatred' rant about exceptions. I think Java's exceptions are far and away the most amazingly useful language construct for dealing with errors in any major language. In fact, in my oppinion, Java's exceptions are one of Java's best features. From your commment, I don't think that you quite understand them.
If I may interpret your comment, you seem to be under the impression that a call to a method that can throw an exception must be surrounded by a try, with a catch clause of an appropriate exception type. This is because Java makes methods declare the types of exceptions they will throw. However, all that Java enforces is that you state what you want to do with the exception. You can state that you want a given exception type to 'bubble-up' by placing it after the method declaration if you don't want to catch it.
So, if you have a method that does some IO, rather that use your own `try' block, you can put the phrase 'throws IOException' after the method name in the class definition. This makes any uncaught IOException be thrown up to the next level of execution.
Furthermore, if you want your exceptions to behave more like C++ exceptions, you can make them RuntimeExceptions. These do not have to be declared in the class definition, and they are not caught by default.
Assuming (and it's a big assumption) that you understand from my comment how to use Java's exceptions, maybe you have some issue with my statement that Java's error handling constructs are better that any other mainstream language. Lets compare:
Please keep in mind that a lot of this is just my own opinion, just like your comment was. However, I make sure I understand a language feature before I decry it. I don't think Java is a perfect language (it needs templates for one) but I do think you should know what you are talking about.
Yes, I'm still a junky. Are you still a bitch?
Java's just annoying to program in, if you ask me. I mean, the same command that's writeln in PASCAL, and printf in C and cout in C++ is 'System.out.println' in Java. I mean, damn. You know how annoying it is to type that out every time? I just don't have that much energy. (Must... type... 2000-character command...) G'ah. I need some sleep.
Nonexistent.
Nonexistent.
'I am not the lord of cherry pies.'
Beside they both have the word 'Java'....Java has nothing do with Javascript. May be you meant JSP?
The first time I heard people misunderstood this I did laugh, but after thousands times of it.....
Moreover, til now people still think Java is solely for web presentation. Some even compare it with some web goodies like Flash saying how they are better than Java in web....while not realize that many of them are built in java applets.
Java has already shifted its importance from client side to server side; servlet, EJB, etc.
Actually, I've seen one case where it was useful. Well, okay, maybe not needed. The problem could potentially have been solved with Java's interfaces if at least one of the things you wanted to "inherit" from were provided in the form of an interface.
Imagine a OOP GUI framework in C++. Now imagine a class that inherits from both the Window and the output stream. It does everything in the GUI framework that a Window does, because it's a Window. It is truly also an output stream, so you can say...
But maybe this is the single multiple inheritance exception that prooves the rule that you don't need it?
I'll see your senator, and I'll raise you two judges.
I've tried JVM for palm and trust me, it's not that fun. I think for any small-device programs - at least for now - you want to use c/c++ using the libraries the manufacturer provides. That being said, WinCE blows nuts (at least for programming)
It's Sun/Javasoft that jilted the Linux community, not the other way around. Linux releases of Sun's Java hava lagged way behind Solaris/Windows releases. NetBSD has it even worse -- they still can only run Java 1.1.
The GNU project is stepping up its recognition of free Java-based software now that free tools like Kaffe have matured more, so I don't think the free software issue is as big as the article makes it. I can't speak for the embedded issues.
---- Sigs are bad for your health ----
Give a hand, not a hand-out.
Java on Linux for websites kicks ass, but for anything else there are better tools. A little Apache with JServ and a Postgres database can't be beat. I wouldn't trust my website on a Windows box, would you? For anything else, there's perl or C or any other misc lang you want to use--java is just too much work in this case.
You hit the nail on the head. Java is not for everything, but I bet most of the folks who don't like java haven't done any major server side work esp. with J2EE. I agree with many RE: Python and other languages - they all have thier place, and I don't think java will "take over" - it doesn't have to. It's not the best thing since sliced bread but J2EE really does work for server side apps.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
The very first reason that they give for Linux users disliking Java is that it doesn't have a GPL (or similar) license. I would have to disagree with that.
1) Sun is doing a decent job of releasing new versions of Java. So, we can't say that it is stagnating (at least at this point. This could always change in the future)
2) Sun DOES allow source code to be released. We might not be able to hack it and rerelease it as something else, but the source code is available. This is sufficient for 99.9% of us. Let's get real here. What percentage of Linux people actually hack the source for C++ and release their own versions? Wanting to look at the C++ source code? sure.. I've done that many times myself. There's a big difference between looking for something in particular (which Sun is allowing for java by releasing the java source) and actually needing to modify the source.
I think that the problem that Linux users have with Java is that java was slow getting to the table for linux. It took a long time to get a decent version of Java for linux (years longer than it took on sun/windows) and it just hasn't been fully adopted yet.
Comments?
http://www.WinWithRealEstate.com/
I'll assume you are being sarcastic but in case you are not, are you on crack??? Java is a much better language than C++ hands down. Pointers and structs are not good things. They can be useful if you are writing games or device drivers but in the real world of programming, Java has a far cleaner model. There's less that can go wrong. By the way, everything is passed by reference in Java (barring primitive types).
As for applets, that's Java's weakness. Any competent programmer knows that you do not write applets. If anyone comes in for a job with the word applet on their resume gets shown the door. You obviously haven't done any Java server-side programming. It's incredible solid and fast.
Yes fast! I'm sick of people on Slashdot bitching about how slow Java is. It's often benchmarked as being faster that C++ due to the runtime optimizations it is capable of. It gets the slow reputation because of people like you who have never used it for anything but applets.
Oh, and as for the multiple platform issue. I don't see it as really important feature, but it is useful. Like it or not, the best development tools can be found for Windows. Most people develop on Windows for this reason. Normal people don't like vi. Then they deploy on a Unix platform for stability. It is a tremendous time saver. I get the impression that you don't earn your living as a programmer (or at least not yet). Time to market is one of the most important development consideration and, next to Smalltalk, Java is one of the best RAD languages out there (when you factor in the stability from not having to deal with pointers and such).
Sorry, i couldn't resist...
---
Play Six Pack Man. I
Im sorry, you say peeps ; I stop reading. Call me a language bigot. I tend to like words that I can find in a dictionary, not ones made up on television.
Every tool has a use, and so does the Java environment. In fact, I think Java is one of the most flexible and useful languages/environments. It is a blessing on the server side where the bottleneck isn't really CPU, but simply handling the vast complexity of really large systems running on different hardware, across a network, doing all sorts of tasks, but having to coordinate with each other. Java is great for the server side: CORBA, RMI, servlets, JSP, JNDI, LDAP, messaging, JDBC database access, on and on. Rich APIs and standards compliance are provided for all of these. We can develop on our NT boxes, test on NT servers and low-end Unix boxes, then move over to the heaving duty Unix boxes, with zero code change. But Java is also pretty good, and getting better, on the client side, with a rich cross-platform widget and component toolkit, and better virtual machines. It allows us to create one client for our services, and deploy them accross PCs, Macs, and Unixes. Sure there's work to be done on making Java transparent on the client side...but we are already seeing a move toward dynamic translation/execution, with the Crusoe chip and other's like it, with IBM's DAISY, etc. I think we will see more integrated support for dynamic translation/execution in operating systems (e.g., Windows and OS X already do this to some extent with their legacy APIs and libraries) I think Java on the client is going to get even better.
As for the Java license, I think Sun just wants to keep control over their baby while it's still in the crucible. Java is still a very young language, and there are already several initiatives to make slightly different flavors out of it. For a proprietary company, Sun sure provides a hell of a lot for free: open specs, source code, tons of documentation, tons of free high quality libraries, packages, VMs, etc. Even though I consider myself more in the RMS than ESR camp, I'd have to say that I'm pretty satisfied with the management of Java. Even though it's not open source, it is so open that if Sun disappeared tomorrow, nothing would stop people from reimplementing and reusing the Java environment from the open specs, and source that is already written out there.
It's 10 PM. Do you know if you're un-American?
Which is a decent idea, but if you don't have ReflectPermission set in the JVM, you can't do it.
Considering the reflective classes are essentially a form of language extension, you would've thought Sun would've created a Permission object that would allow prevent access to private fields and methods (therefore being useful, and still OO)....
And while I'm whinging, anyone want to tell me what the point of CloneNotSupportedException is? Because I think the clone method is one badly defined method, and one of the problems with Java is if you're going to define a bunch of classes which are going to be used by everyone who uses the language, you should code the classes properly. a not so interesting wombchimp.
I don't agree that all Linuxers hate Java! I love Linux, I like Java, I use Java for lots of my needs (both GUI and server programming).
First of all the Linux community is a collection of people of all sorts and different interests. You can't say the Linux community likes this and dislikes that! Even some not so popular languages have large number of linux supporters
Socond Java is a very good language. I don't have time for pointing its features here but I think most of you are aware of them.
I don't say C/C++/Perl/Lisp are bad choises! In dact there better in most of the cases but Java is *very* good somethimes.
Anm
Ok. I actually read the article, and it's about as deep as a puddle. It's is three short web pages of text whining that linux people don't like them because it's not free, and it's Sun.
First, 'Use' and 'Like' are not necessarily the same thing. I definately don't use many things that I don't like, but there are acceptions to the rule. I use Windows. Hell, I even BUY Windows. But to assume that I don't like something because I don't use it is a bad assumption.
As for the embedded market, 'stable' and 'changing' are two different things. To exist in an embedded market, you have to be stable. A 'changing' environment does not factor in that at all, if for no other reason, 'unattended' includes the idea of NO UPGRADES. I have heard a of lot of people that run Linux 1.0.36 as a router/fw because it it is stable, and the don't feel the need to upgrade, even though Linux has changed a lot since then...
All this article tells me is that they person doesn't understand the Linux Market, doesn't understand the difference between open source, free software, and open/free software, doesn't understand embedded/realtime environments, and can't figure out that Linux people don't have huge corporate budgets, and that cost effective is the key to non-free software in the Linux universe.
-- You can't idiot-proof anything, because they're always coming out with better idiots.
How is this the instructor's fault, doesn't he have a mouth. What prevented him from asking his instructor the question ? Or reading the course text ? This is basic stuff, and there is no way an instructor can know one of his students will not attempt to make an effort to learn.
Woe be on to them, all who rise against poor people, shall perish in a the end. Buju Banton
I find that Linux supports java really well. When I'm installing RH7 I need all the coffee I can get...
http://twitter.com/onion2k
First off... Java on the client is a dumb idea. HTML is way better.
Second, Java is a MUCH better langage than C++.
Third, Java on the server is the best thing since sliced bread. J2EE may sound like hype, but it *WORKS* -- which would you rather have? Microsoft dominating the world with C# and
so there
-nate
Right on, java is great, because for the most part its easy, simple, clear, and has everything built in so there isn't lots of confusion as to what the API's are like. I know java is slow, but in alot of cases for me, I am glad just that I can do things like sound programming, because I and not very good at getting down complicated C libraries, because, well, I'm not a very good C programmer.
This Wiki Feeds You TV and Anime - vidwiki.org
I'd like to consider myself a strong Linux supporter, and I've been working almost exclusively in Java and Perl for the last 5 years.
I'm getting ready pretty soon to release version 1.0 of my network directory management system for various platform, including Linux. It will be interesting to see how many people shy away from it solely because of it being written in Java. I am completely confident that the work we have done could not have been accomplished with 4 times the resources using any other programming environment that is available today, let alone 5 years ago when we started.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
As a longtime linux user and C/C++/Java programmer, I beg to differ. Anytime we start making generalizations about such a broad group of people (such as all linux folks), we begin to display a lack of understanding of the group itself. All of us are not using linux because of the philisophical underpinnings of open source, to some of us, it is not about religion, it's about practicality. Am I an embedded programmer? No. I'm a server-side guy myself, and nothing works better than Apache+Tomcat (as well as playing around with some sweet non-open source servlet engines as well). JSP's and servlets rock, and run great on my 2.2.x boxen. Doesn't run with the 2.4 series? Then I won't use it. Don't like java? Then don't use it. But don't tell me that it's crap, because it's not. Again, just a lowly geek's opinion, but just had to share...
You ain't learning nothing when you're talking
Paraphrasing Charles Babbage:
I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a comment.
I've been developing Java on Linux for a couple years now, using Sun Forte and Borland JBuilder. I've no probs with 2.4.test11 for the past week or so, Java performance is fine Using IBM JDK2-13. IBM seem to be pushing Linux / Java / XML because of the portable OS / portable code / portable data angle. Works for me.
What's up with that? At the least, you'd think he would know how to be persuasive, if not informed.
-- You can't idiot-proof anything, because they're always coming out with better idiots.
My main problem with Java relates to how typical Java developers use it - or at least the ones I have to deal with. I have found that most corporate Java developers have little or no experience with any other language. This is a problem because Java by its nature encourages programmers to forget about code optimization and resource management. If someone picks up Java as a first language, he doesn't even think about the overhead involved in creating and garbage collecting objects. Our developers have written heavily threaded web applications that fill heap (256 MB) in under 2 minutes, and then freeze for 15 seconds or more during collection. Then when their app crashes because they have used up all available resources, they blame the sysadmins for the problem. This gets to the second problem I have with corporate Java developers. The ones that I have dealt with have no clue how to debug their code. They don't even bother trying to find out where in their code the app is crashing before calling us and saying that the OS is configured improperly or that they are experiencing a JDK bug.
In summary - friends don't let friends hire Jave developers that have no low level programming experience!
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
Where do you use multiple inheritance? I truly havent't found a reason to use MI. I admit I don't get it. I'm really interested, no flamebait...
Someone else mentioned interfaces, but you can't reuse code with them so they're not exactly the same as MI, interfaces just let you define what has to be in a class.
My college (as can be inferred from the address above) teaches EVERY CS course in Java cause were a big public school that receives funding from SUN. It was cute like 5 years ago but now its just bull. And short of the Xterms in teh lab (we're not aloud to X in from anywhere else) you kinda have to use linux for anything important. The problem isnt linux - Javas slow as frozen piss on every platform.
The project I'm working on used to have a windows user interface (client) connecting over a network to a server providing the data for it.
For a new generation of product we want to use a "thin" browser based interface. We can generate most of the pages on the server using html and php to generate reports and static graphics but we are going to need some live data from the server presented as changing statistics and graphs with a little interactivity. The data comes from a network connection to the server.
While share many doubts about java, particularly that because we want people to be able to connect to the server from any machine with a reasonably modern browser installed we are going to have to limit ourself to the subset of java that works on most browsers. I really don't see any other solution to this other than proving java applets embedded in a web page to link to our server and draw the graphics.
What other technologies could I use?
Did anyone else think he was a bit confused saying that because embedded devices must run unchanged for years, java is unsuitable because it changes all the time. It doesn't cause your software to change unless you go and change it
Sig is taking a break!
I don't think that Java is the only factor in Linux become an enterprize solution. The OS needs some work too. Linux will need to scale to enterprize hardware packages (its getting closer). However, no one can deny, that middle-tier application servers are moving to Java. I wouldn't want an OS where everything was running in java either. However, I'd rather not implement an enterprize-level distributed-net-application in exclusively C++ (actually I'd love to, it just would take 10 times as long).
Someone you trust is one of us.
This a bullshit generalization. Just looking at the slashdot answers on the subject, it is obvious that many Linux "folks" are also Java "folks". I am surprised that the Java Developer Journal would print this crap.
I use Linux on my desktop to do Java programming all the time. At the companies I have been at, it seems like it's natural to run Java on Sun hardware and Solaris, and (IMHO) one of the best PC operating systems for interacting with Solaris is Linux.
I do however, think that Java shines on the server side (jsp's, servlets, ejb's) while leaving something to be desired on the client side (applets, etc.)
I thought Java was supposed to run on any platform , right? So how/why do people like dialpad right java code that will not run on Linux. Or is there something I don't know about how to make it run?
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Neat thing about Linux is the Blackdown JDK is a much faster compiler than the Win32 port of the Sun JDK for Solaris. I can compile in about half the time as the Windows developers (and haven't noticed any weird things yet) and it all runs faster on my box too.
The only problem with Java on Linux is the Blackdown JDK isn't as well maintained as all that. Their JDK1.1 compiler segfaults with RH7, meaning I can't compile applets on this machine (because most browsers only inherently have 1.1 support). I am an avid Linux user (been my desktop for two and a half years now) and would have to say that Java is pretty great.
In fact, Java is the only language that has a really great (IMHO) fully featured IDE for Linux. I keep waiting for KDevelop to become mature enough to use for C++ development but it may take them a while. :)
Anyhow, I think Sun should develop a JDK for Linux. After all it's one of the world's top operating systems.
"It's here, but no one wants it." - The Sugar Speaker
Another worry of the Linux community, indeed of the embedded community in general, is the stability of the Java code base. Unlike desktop computers with a few years' life span, it's not unusual to find embedded devices that are expected to run unattended for 10-15 years. Java is simply changing too fast right now to provide the comfort level that embedded developers need.
Did this bother anyone besides me? Judging from the Slashdot discussion, embedded systems are not exactly the biggest thing on Linux folks' minds. And the second quote doesn't make much sense to me. If your car or your portable game box is going to have Java inside, it's not going to break because a new version of Java comes out. Whatever version of the VM is burned into the roms is going to remain burned into the roms.
Actually, it seems to me that the reasons many applets are a disaster don't apply at all to embedded Java: browser and VM incompatibilities, slow startup times.
If there are any Slashdotters involved in this thriving embedded Linux community, could they comment?
--
Find free books.
Is that true anymore? Say you have a class with some type conversion constructors. Now insert them into a container template. Maybe it's a doubly templated container, like a map. Now throw an exception out of one of the container template's methods. Do you really know what's going on? I don't. C++ does a lot of funky shit for you now, if you haven't noticed.
And another thing- Garbage collection. When you dont have it you may have to hunt down memory leaks. But when you do have it you must hunt down memory bloat- the converse problem. Many java programs bloat up is size because uneeded large objects are left laying around referenced. This is a problem I consider equivalent to memory leaks, but much harder to detect and debug.
Are you really going to argue that unused references are worse than memory leaks? Answer: don't keep around references. Create new objects. If it's a performance problem creating new objects, cache them (and be careful not to hold them around as much). In all cases, your program works (in a possibly degraded state). With memory leaks, your program will not work--it'll bail out with a failure.
In practice, this doesn't happen. Yes, people make too many objects sometimes (creating some memory problems), but still: the program works. The logic is correct. With more memory, it'll work better. How much memory do you need to add in order to correct a C/C++ memory leak?
From the Jargon file: C is often described, with a mixture of fondness and disdain varying according to the speaker, as "a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language".
If you open your mind too wide, people will throw trash in it.
Don't kid yourself... C++ has TONS of flaws. You're harping on one little aspect of Java that frankly almost never comes up in the real world.
- Spryguy
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
I moderate this article (Score: -2, Troll). Really guys...
end communication
The TomCat README I have, of 2000/04/18, provides very nice pointers to installation, configuration, and development documentation. I certainly don't see "use the source, Luke" written anywhere in there. Even if I'd lost the README and the docs that come with the binary somehow, it's three rational clicks away from jakarta.apache.org to get to Tomcat - A Minimalistic User's Guide.
I admit I would like more documentation with TomCat but I'd like more documentation with everything. I think Jakarta's doing a reasonbly good job getting documentation out there.
I can vouch for this as well.. it *has* been declining. I hadn't really thought about it.
I while back I had to deal with Sun to buy some workstations. I was pretty excited about it.. I mean, I LOVE old sun machines, I like SUN, I like their (past) contributions to education, I really enjoyed working on a sun at University... I considered them excellent.
What I ended up with was a bunch of salespersons who were telling me that I didn't understand waht I was talking about, that I should rip out all my other servers and put in SUN hardware, they were bordering on rude, they took forever to simply get me the workstation quote I asked for, and they harassed me post-sale a lot. To boot, the workstation isn't quite what they make it out to be, and they never did get me the simple little 13w3 to vga connector that I also wanted for one of my aging systems....
Don't get me wrong, I *still* like sun equipment, but it angered me that the company would actually make me like them LESS.
Since you're the most highly rated person to pull me up for having used the word "performance" ambiguously, I'll correct myself here and ignore the others. It really should have been clear from the fact that I disagreed only with about half of what Mr Walker said, but I guess the deliberately provocative title caused a lot of people to read what they wanted to read, rather than what I meant to write. My primary purpose was not to give a lesson in project architecture but to indicate that just the same arguments can be made against C++.
There are two quite distinct kinds of activity often represented as performance enhancing. The first is simply correct architecture. When defining the computational and engineering aspects of the architecture you should, of course, make sure that you've chosen technologies, algorithms and data structures that can provide adequate performance and scalability. They're different things, incidentally, as someone else pointed out.
The second is actual optimisation. Even the best architected project will usually develop bottlenecks and other performance problems between being function complete and actually being deemed acceptable for use. This is the time when you should get the profiler out, diagnose the problem and repair it. Its with things likely to lead to these kinds of issues (for instance, the choice of a linear rather than binary search for some collection), but with no effect on interfaces between components, where I would usually advocate doing the simplest possible thing for the initial implementation and fixing it later if it proves to be a problem.
you can throw a subclass of Error and then you don't have to declare that you are expecting the error
An Error and an Exception are completely different things despite both being derived from java.lang.Throwable.
To quote from the JDK documentation:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it. A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.
I admit to not knowing much about OO since I feel it is a bit of over-hyped non-proven rubbish that is often used to cover terrible design (whoops slipped that bit of Trolling in -- it is Friday afternoon). However, isn't the fashion now to not use inheritance but to go with aggregation of small objects to pick up functionality? The extra polymorphism provided by multiple inheritance is more than covered by interfaces.
The Design patterns book mentions this in its introduction and argues that it is a much better way of reusing functionality. It won me over, but then I'm a non-believer anyway.
I'm really sorry that I brought the world to an end by not spelling comparable correctly for you. You must have been on the Internet for a whole 60 seconds before reading my post if that's the first time you hit upon someone who made a little spelling mistake.
I'm not a JSP monkey (I'd been doing Java development before JSP was even developed), and the specific case I was talking about was for a performance test at the JPL. I rewrote a Java math library that someone had converted from C. It was 20 times slower than the C code (mostly because it WAS a direct translation). I rewrote it (and yes, this required coming up with my own algorithms in some cases) and ended up with something that was almost as fast as the original C code. Said code was also significantly faster than a Java wrapper around the original C code (there's enough overhead in JNI that it doesn't necessarily provide a performance increase).
FYI, the reason all the commerical app servers have optional native layers (aside from the fact that it's part of the standard) is to allow capabilities you won't find inside the Java environment. Sometimes it's handy beause these additional capabilities signifcantly improve performance (say if you want to do shared memory for IPC). Sometimes it's handy because there'd be no other way to access these capabilities (say you want to use DirectPlay on Windows). But believe me, 99% of the code people write for their J2EE server is not native. That 99% runs plenty fast already.
sigs are a waste of space
Using a read-only language (perl? others?)
It would be write-only, I think
I can't help but think that maybe Java was sold to the wrong crowd, and expectations were really high. Maybe it's just me -- but I was under the impression in the early days that Java would be the cross platform / thin client/ browser delivered GUI builder of the future. Heck, even Corel took a spin at doing WP office in Java.
(If I went to the store looking for a wrench and got sent home with a hammer -- yes I would be pissed when I found out that it was hard to tighten bolts with my new hammer.)
Java has been proven to have an advantage on the server end, and programmers will swear that Java is the ultimate tool to use with networking...(And yet I do not see any Java based web servers with a high percentage at Netcraft.)
I have yet to see any usable "desktop apps" written in Java -- although the people I hire to build apps always say "I wish we could do this in Java"....But when you say OK do it in Java -- in turns a small project into something akin to the moon landing.
What it boils down to IMHO is that I will just sit back on the fence and see if the next Apache type "killer server app" is written in Java....Or maybe the next Quicken type "killer client app" is written in Java --- until then I will keep my opinion that Java is being used to teach the kids in school proper programming, but in the real world -- it boils down to still chunking out C and C++ when you need to get the job done.
SOG
(+1 Funny) only if I laugh out loud.
I'm sorry, but I don't get what you're saying here. Yes, in C++ the the language enforces the calls of constructors and destructors to the super class. What does that matter? (Indeed, C++ destructors are very different from Java's finalizers.) All I was saying is that Java requires that in invoke the contstructor of your super class in the base class, so it's logical you have to invoke the finalize() method.
Now, I actually do understand the underlying principles that are making this all necessary, but I presume that to for anyone that does finalize() is far from a mystery. So, I'm trying to point out that even at a surface level it makes sense.
sigs are a waste of space
There is no stable, open source java servlet platform that has any value to it whatsoever.
I/O Error G-17: Aborting Installation
Most portable is only true if you're trying to write to a very small least-common-denominator.
Try writing a portable GUI application in C.
Most concise and easy to follow someone else's code are usually mutually exclusive.
Most simple is a matter of perspective. For instance, if my problem requires GC, I have to re-invent it in C. RTTI? Type safety? What if my problem were best solved in Lisp, then I have to re-invent many Lisp primitives in C, so will it be any more efficient in the end? Having to re-invent the high level abstractions of other languages does not strike me as simple. Or using those abstractions as part of a package provided by someone else is fraught with potential errors that just don't happen when the abstractions are part of the language. Any modern large scale programming project requires lots of abstraction that is not directly expressed in C.
I'm not suggesting that C is a bad language. It is extremely good for certian uses. It is not the most productive thing to use for many other uses.
I'll see your senator, and I'll raise you two judges.
NONE of the pages that I view everyday (that'd be around a dozen) use Java. In fact, now that I think about it, none that I have viewed in the last month have used Java.
How do you know?
I think what you are saying is: none of the pages that you view everyday have Java applets on them. A fact that you're probably glad of. But some, none or all of them may be using Java code on the server. I freely confess my total ignorance of this field of endeavour (only web coding I ever did was a lame Perl/CGI thing), but every time Java is mentioned on Slashdot, I see a bunch of abnormally coherent comments praising Java in this role. So I trust that it is good for this.
THAT is probably why all the employers want to see Java on your resume.
And while I'm here - C#. What is the deal? Microsoft seem to have forgotten that their corporate goal is to get people to use Windows instead of Linux/Solaris/BSD/insert-Unix-flavour-here. They'd have a lot more luck supporting Java in their .NET platform, make it easy for people to switch, not harder, by forcing them to learn a new language and port all their code
.NET - empty air, held together by thin string
All of these posts are only telling half the story, of a quiet revolution that is happening in the computer centers of major companies adopting Java, open source philosophies in enabling business processes.
First, let me state, that Java as a language and Java as an implementation are two very different things.
The posts on Slash.dot here are referring to Java as an implementation, big slow etc, which in fact is true in _some_ instances.
But not true in others. It also isn't the only _implementation_ that is possible, so don't blame Sun for all of these implementation issues.
Java as a language reference can be implemented in both VM and native form.
That means, you don't need a jvm to run your Java program kiddies.
The OOD and OOP implementation benefits the language brings to the table, really, is an acknolwedgement that Software Engineering hasn't advanced very much in the past 30 years.
This is the FIRST language in my opinion that recognizes this fact. I know, I hire people to write ecom software. Software that cannot afford to have too many critical mistakes in it that result in lost dollars or unsafe transactions/privacy issues for the individual/companies. Software that must be designed/run in environments that usually bridges the gap between old and new, and provides direct access to a companies business systems. Also very much firsts, for customers who only requirement is that they use a web browser.
I have seen how this works. Companies who started out on small systems, such as NT boxes that have had to move to large SUN RISC environments after a year or two to meet demand.
Complete whole Ecom systems, moved without a single rewrite of 10's of thousands of lines of code on totally alien environments form where they have been built and ran. In my 15 years, I have never seen this happen before with off the shelf software. It is a true advancement, a real pay off.
A payoff Microsoft does NOT want you to have.
Our tools have become better, certainly some of our methods have improved, but the quality and maintainability of a vast majority of the software that is written is still not very good. (That is being overly complementary in my opinion.)
Java repesents I think an acknowledgement that for the first time, addresses a couple of points that for my business, dare I say software engineering economics (we build and write Ecom software for mission critical sites using ONLY java and open source platforms like Linux, to deploy them) is critical:
First Point is Code Reusability
What does Java have to offer that other languages don't? Reusability with a twist, and that twist is it pulls a API that I can count on between platforms.
Does anyone here have any idea what that means if you want to live in a world that tolerates a large number of OS platforms and you want to do business?
The holy grail in business process/technology is write once and run anywhere. It also has been the driving force behind C's portability and various gnu initiatives. It also We who write software have been seeking in the business world for 3 decades.
It isn't just a business desire either. How many here would like to play Homeworld on a linux box? How about MechWarrior 4???
For the first time I am seeing it actually work on a huge number of platforms, Sun, HP, Linux, As400's, S390's, Intel, with NO effort to port code for a single line.
It is not possible to do this with any other software development technology at such a low cost point and still allow everyone to pick what they want to run as thier OS platform of choice.
I am not sure everyone here understands what this means to organizations who want to save money and still be able to support platform OS diversity, given the kinds of posts I have seen.
-gc
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Dude, use Emacs and learn what C-x a-i-l means. It turns on abbreviations. When I was writing servlets I never typed more than three
characters to call a method -- I had autoexpansion on.
While you're at it, learn to use the speedbar and autogeneration of skeleton methods in JDE.
Too bad you can't tune any kernels in Java, or I'd probably still be working in it. (and Perl)
I use Vi all day long so, when XEmacs starts up, I have it default to Vi keybindings. There goes another one of your arguments. Oh, and use gnuclient -- start up XEmacs when you start up X and simply run client processes. It's as fast as Vi once it's loaded into memory, and you can use a real debugger (DDD, jdb, pdb, gdb) , make, compile, all that IDE shit... from your editor.
Remember that what's inside of you doesn't matter because nobody can see it.
There are a few reasons why I dislike Java on a purely technical basis:
;)
- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.
- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.
- The finalize method of dervied classes must explicitly call the finalize method of the base class. Why in the hell did they do this?
There are some good points though, which, once the above are solved would make Java superior to most other languages:
- Incremental garbage collection. True incremental collection, with no more sweep checks.
- Threads. Java threads kick ass. Period.
- Libraries. Java has a library for everything under the sun.
- Portability. I love the fact that you can take a jar file and run it opn any VM (almost). This is a real time saver.
Your mileage may vary...
The Q3 VM was NOT Java AFAIK. Carmack thought about using Java but didn't.
My new employer (starting monday) required it as they want to use it for server side stuff that you might not even realize is being used on sites.
Java is great for server side / backend development where the portability and robustness are what make it usefull. Java Servlets / JSP are pretty sweet.
Anyone that suggests/condones PHP really needs to reevaluate that language, it's a little hack done with very bad error handling routines and very little innovation. It does the same thing as Perl Routines I've used for years do of parsing pages, then uses a munged up wanna be perl/c mix to do the actual coding. ASP/PHP/JSP all serve the same goals, but I can live with JSP due to how it's a component that can work with Beans/Servlets to get some serious work done with great ease, PHP just bites, and ASP well it's ASP we have to have a basic language for all the VB script kiddies to play on the web with don't we?
oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use
You're a NEWS REPORTING SITE for fuxsake! You could have whipped them up to no end in court!!! Why did you bend over? Not even M$ sued over the Wine logo, or Bill-of-the-Borg! Geez!
most easy to follow somebody else's code
C is probably the least easy code to follow (barring assembly language). That's why god invented object-oriented languages. And as for cut and paste, ughh!!! That's the surest way to guarantee a project's failure. A little change in one place ends up causing months of debugging. Oh well, I took the bait.
Does anybody here remember CHIPS-8? Great little gaming system doing the same thing that Java is trying to do. Keep it simple.
Personally, I'm a Linux user - small time coder, and out of a whim, I downloaded the JDK, and balked at the size of it. I downloaded kafe, and gave it a try - it cored nastily, and I just said, "Fine - didn't need it, don't need it." and dusted off my trusty C compiler again.
Javascript although is handy from time to time for gloss, is not implemented the same way on different platforms. And yet, generally, c routines written on one machine to do basic processing and reasonable I/O works on my NT box at work just as well as my Linux box at home.
For prototyping, I do everything in TCL. Beyond that, I code in C, using TCL libraries for GUI et al... Java, C#, et al will never be a mainstay in my house, nor my job.
I donate all spillover Karma to the charity of my choice... Ada was still a babe despite what people may say...
Javascript has nothing to do with Java. Netscape invented Javascript and used the name to capitalize on Sun's hype about Java.
LOL!! .. I love it.. that's how I feel about Java too.. It sucks ass and never should have left the development labs. The ONE thing I thought was promising when I first heard of Java was the running on different platforms idea. Sounded good. Unfortunately it just didn't make it. Whether that's due to design or implementation, I don't know. But I do know that when I want to write a program, I do NOT reach for Java.. I reach for C/C++ .. or if I'm doing web stuff, PHP.
--
Delphis
Now for my Java bashing: I hate it. It takes 100 lines of code to do something trivial.
If its something trivial that you're trying to accomplish, then don't use Java.
Using a read-only language (perl? others?) would be excellent for a trivial program, because you don't end up with long term maintainability problems that must be considered in a huge software engineering project.
I'll see your senator, and I'll raise you two judges.
jdk1.3 for linux has been out for a while. Get it here, although I doubt anyone would actually download it.
Planning to be moderated ± 1: Bad Pun.
You're right.
What I mean is that people who like to program close to the bare metal often seem to be the most vocal Java haters.
You certianly could hate Java and like other high level languages. I stated this wrong.
I'll see your senator, and I'll raise you two judges.
How many browsers support the latest Java APIs? I think Java applications are so much more useful than applets these days, since you don't have to deal with a instable browser. Some of best apps are written in Java these days. Think of Together or ArgoUML. Both rock and give you a good performance.
Java was intended as a language to control hardware interfaces and creating web applets is not its main application. Java produces easily readable code - which can be modified after months of developer-inactivity without checking up on language skills first. On the hardware side of things we've seen java doing wonderful things in the world of embedded systems.
Taco just cut loose with a Java troll! :)
"We apologize for the inconvenience."
Like it or not, Java is fast becoming the standard language for server-side devleopment. If Linux does not support Java well, people will just pick some other O/S for their servers. Linux will then be the loser, not Java.
1) Its GPL 2) Its fast 3) It doesnt require X-Windows for AWT 4) It runs just about anywhere 5) It smells nice 6) Sun doesnt Like it http://www.kaffe.org
Maybe Java-lovers (myself included) should jump ship to the Microsoft camp?
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
A plug for Nathan Myers' book, Java Programming on Linux Mr. Myers' gave a talk to my local Java users group, and, as you can see from the web page, he's an extremely experienced Unix developer. He even knew the answer to my question about Java complaining about missing fonts in X.
Why I Hate Java
I've been trying it since the beginning, maybe every six months or so.
The hype factor is a real turn off. The benchmarks don't tell the real story. "90% as fast as C++!" then you write a simple GUI and (literally) watch buttons render themselve -- at least you can watch for 5 minutes or so til it freezes.
The idea is great, the implementations are substantially less than great.
Maybe Sun should license Ids' qvm technology?
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Real men can program FORTRAN in any other language....
> If there's one thing I miss on Linux, it's ...and if an open one is written, I'm sure
> good Codec support. I'd love to see a good,
> high-quality encoder come out of this, much
> like the LAME project did for mp3's.
>
> all the other free OS people will be very
> happy too...
the MPEG-2 compression tools at http://heroine.linuxave.net/ get REALLY REALLY good bitrates, comparable to the M$ "MPEG4" codec. Sorry I'm not going to write much, this just looked like the best way to contact you in regards to a somewhat stale comment.
-----
I never learned java - I always was waiting for it to become more stable and/or faster and more "native" - I stayed with C, C++, Perl and pretty much everything else, while my other programmer-buddies all gravitated towards java without any questions. Since then, I've become a sysadmin and I know that java is very fragmented already and will just continue to become more so. I know that this is a totally religous argument, so I won't go on an on about why one language is better than others, but most programmers, once they learn java, use it for everything no matter what the problem or task at hand and I think that's just ignorant - there's always a "best" tool for every job and java isn't it in a lot of cases.
...): java sucks.
Here's a link that I found to be particularly elightening, although a little out of date, check it out: Things that suck about JAVA (not written by me).
Here's the rant by Jamie Zawinski (author of xscreensaver, xkeycaps, among many other linux greats,
See, it's not just me!
--
Steven Webb
System Administrator II - Juneau and TECOM projects
NCAR - Research Applications Program
You might think that's because he's the creator of C++ after all, but I doubt it - Bjarne has used languages you've likely never heard of, and he understands the strengths and weaknesses of each.
Stroustrup finds much of Java advertising insulting and offensive to other programmers. I do too.
Java, as a language, has some merits. But what I'd like to see is an ISO standard that is not controlled by Sun (note that although Stroustrup participated in the ISO standardization process for C++, AT&T certainly didn't try to control the process as Sun insists on doing with Java), and I'd also like to see one able to compile Java programs to native executable code so they can run directly without a VM; this is possible with gcc but I believe it's not yet ready for production use.
I certainly won't believe that Java is even valid as a language unless multiple independently written implementations can all pass compliance test suites; most of the Java VM's out there don't count because they're just ports of Sun's VM. That's one reason I'd like to see Kaffe succeed.
Meanwhile, for an alternative to Java - writing a single set of C++ sources and compiling to native executable binaries on Mac OS, Windows, BeOS and POSIX platforms with XWindows (such as Linux) see the ZooLib cross-platform application framework.
Michael D. Crawford
GoingWare Inc
-- Could you use my software consulting serv
You preach about how big companies are stripping away are rights.
/. is owned ran by wussies. no, you are worse the that,you are cowards.
You praise when someone fights attempts by big companies to shut them down.
Then whae you have a chance to fight BS cease and desist orders what do you do? you give in. You have more money then most web site owners, you have a voice that is heard by many, this was a call to be champion for what you say you belive in, but you submit to the cease and desist order?
the lawyers may advise you, but they do not own you.
Apparently slashdot does not beleive wht they preach. obviously your just another money grubbing media company that found some coat tails to ride and when it came time to stand up, you bent over.
The Kruger Dunning explains most post on
I figured that this was obvious, but it bore mentioning.
Russell Ahrens
The main problem with java is it's insecure code methods. They aren't usually used so you might not run into them
I would like to see an example of said "insecure code methods". A method in Java is not 'secure' or 'unsecure'. If you are referring to accessor and mutator methods that are declared 'public', it is up to the programmer to ensure that proper access to private data is implemented.
If you're faulting Java for accessor methods, then you might as well fault all of OO languages (Smalltalk, C++, etc.).
Basically the sandbox approach works fine until you start to abstract it.
What do you mean by 'abstract it'? Explain yourself, please.
The sandbox is a 'safe' place to run untrusted code so it does not damage the rest of your system. If the sandbox is poorly implemented, then yes, there is a risk. This is the fault of the developer, not the Java language.
Flame me if you will but this is the reason that Amercian Express got hacked last year.
Excuse me? Care to provide a link to a story on said hacking?
The next time you post on a subject you have no knowledge of, don't throw jargon around. It only exposes your ignorance.
I say we take off and nuke the entire site from orbit. It's the only way to be sure.
- Exceptions
- Garbage collection and memory management
- Interfaces
- Object oriented
- Threads
- GUI
- Built-in networking support
- Strong typing and specified widening/casting
- extensively specified operator precedence/evaluation order
- Extensive libraries included as part of the language
- cross-platform portability
- primitive type sizes are specified and platform-independent
- primitive type conversions in expressions are specified by the language
- No messy signed/unsigned/short/long/double issues. Question: in C++ what size/signedness is the result of this: uint64*1000?
For folks that think they need multiple inheritance, they haven't understood interfaces and inner classes yet.I'm not even going to address the "issues" CmdrTaco rants about because they don't directly address the language as a tool, only his personal political attitudes.
The trouble is that Java is exactly the wrong solution for these apps. The current JVMs are fast enough now, but they all have big memory footprints. Swing especially is a pig. Because much of the Java environment is bytecode loaded at runtime, very little of the footprint can be implemented as shared libraries. Do you really want to run a Java xbiff or xclock clone when every little app you run eat 10-30MB of RAM and take an eternity to start? There is no general solution for the footprint problem, neither now nor for the immediate future. (I know about Echidna, but it is neither usable nor progressing).
I like Java. I write Java code -- including Swing -- for a living, and there are many positive things to say about it. I do not need to repeat its many advantages here. As a server, or as the sole running app in a custom environment it is fine. But I would not want to run a bunch of Java mini-apps on my desktop, at least not with its current state of implementation.
I can understand Sun's reactions in a way. It seems to me that Solaris and Linux could be veiwed as quite similar. The main differences being one is free and one is not. Sun relies on Solaris, at least to some degree, for their survival. I can see why they don't want to support Linux as much as everyone wishes they would.
It seems to me, however, that if you discard a language because you don't like it's creator you are shooting yourself in the foot. For example, if I thought Bjarne Stroustrup was an arrogant jerk (which I don't since I don't know him. This is just hypothetical) and refused to use the technology he developed, that would be nobody's loss but my own.
I don't believe Java has been reduced to just another bussword any more than C/C++ has. I can currently make a lot more money programming in Java than I can C++. If that is the result of it being a buzzword, then being a buzzword is GREAT!!!
yerricide says
Making the same mistake[?] Everything 2 users make. Now to the topic:
this article about Mandrake Linux with Java
Will I retire or break 10K?
Linux had better embrace java if it wants to be an enterprize OS. Java is the new choice for enterprize app/networks. Interoperability, consistency-maintainability, the java lib, debuging, jdbc, etc are all driving enterprize solutions to java. You can get 10 java engineers for every 1 C++ engineer. App servers are all shooting towards java as their solution. If the linux community fails to embrase servlet runners and excellent ejb servers, it will never achieve the enterprize-level middletier throne that it deserves. However, Sun will probably do everything it can to prevent this from happening.
Someone you trust is one of us.
My university has adopted Java as the de facto language for CS majors. After one semester of Java (last semester was C++), I'm ready to revolt. The fact that I have to System.out.println() my life away is annoying, but having to Integer.valueOf(stdin.readline()).intValue() everything really ticks me off. After.all.the.searching.for.methods() I wonder if students don't just get lost in Java trying to work their way around the shotty syntax. I know I've certainly felt many times like the syntax got in the way of the original problem.
I get tired of hearing about the "fight" between C, C++, and Java (and now C#), as if those are the only three programming languages in existence. Even putting aside so-called scripting languages like Perl and Python (which are more than scripting languages these days), you have dozens of good, solid options. I have no idea why the view of programming languages is so bloody narrow).
Yeah, in the same way that the qc from Quake 1 wasn't C. As far as Q3A goes, Carmack is sticking with the qvm because of their security. However, he's definitely doing C for the next DOOM project. Did I mention that Id will be developing the next doom on Windows 2000 with NVidia hardware? [watches the faces of the bible thumpers cringe]
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Linux users, perl users in particular, seem to dislike Java. Probably the stereo type Java hater uses linux with Gnome and hacks his way through life using perl. This whole 'article' breathes conservatism. The whole linux community breathes conservatism. Which is the main reason I keep uninstalling it. Every few months I am tricked into believing it has improved. Then I go ahead and install and see for myself and I see the same mess of patched together obsolete shit it has been for years (and yes, I've seen Gnome and KDE in their latest incarnations).
Java may suck for some, but luckily its success does not depend on those who think so. Java is particularly strong in the server market. In this market it is currently outcompeting the linux/perl combination (though ironically it is quite feasible to do a linux java combination, they complement each other quite nicely).
Just some things to ponder:
- Java is available on linux in several flavor (including a GPLed one).
- Java has a large base of professional IDEs and tools written in Java and consequently also available for linux (try finding commercial C/c++ IDEs for linux, or *gasp* a perl IDE).
- Programs written in Java work on any OS supporting Java (currently pretty much any OS) making java development on linux possible in organizations that don't traditionally use Java.
Quit whining and innovate.
Jilles
Well, they used it less than 1 month ago, and the topicsun.gif still exists, and still shows up if you search for sun.
-- Don't Tase me, bro!
GC is good.
Binary compatibility is good.
Javascript has nothing whatsoever to do with Java. No relation.
So what's wrong with Javascript? State reasons for your assertion that Javascript is so bad -- for the role it is most widely used in?
I'll see your senator, and I'll raise you two judges.
If you take a look at Java, it's one of the things that is being very, very aggressively adopted in business, as the portable, non-vendor locked version of the asp architecture. Server side is the domain, as is every other portable/embedded device out there.
Yup, the NS Java VM is crapola. So's the MS one since it's hopelessly outdated. Update! v1.3 is actually pretty darn good. It's still a little pokey on really intense graphics, but for most apps is doing very well now.
If you don't like Sun's implementation, IBM is a great alternative. Very stable, and fast. More choice than you get for an asp engine.
The point, however, is Linux. I use Linux often, and have at work as well as home. I advocate it when it's the right solution. I also use Win2000, and Solaris. On all those platforms, as well as my Palm Pilot, I use Java. Why? Because it is a very, very good language with a solid, portable library and no little glitches like C++ library differences. I also use C++ and C, as well as bits of Perl and such, when the job warrants.
I'd contest that if you actually looked into people doing work on Linux and getting paid for it, you'd find a lot more Java than you might have thought. That and Python would be pervasive, but that's mainly from the distribution engineers at Mandrake, Red Hat and the like.
But by all means, look for one-size-fits-all grail of a solution. I'll add Java to my toolbox and carry on without you.
The first few comments in this story sound like their written by individuals who have absolutely no clue as to how good java really is - where else can you find a consistent stable class library built from the group up to be internet aware (and don't point me towards any glorified/retro-fitted text processing scripting languages) - its easily the best server side development language in existance. Any one that wants to disagree can bring it on!!
I;m choosing not to post this anonymously because I feel I can out debate any one that wants to have a go - at the end of the day people who rubbish java are people who just haven't used it enough.
Question: how many people do you know that have ever heard of Haskell or ML?
How much time would it take Joe Average to learn Haskell or ML?
I was trying to describe what you should do, not what gets done. My personal strategy in the kind of messed up closed source product shop situation you're describing is too make sure the first implementation is minimal function and absolutely rock solid. Then you can spend those later passes adding features to a stable base, rather than pushing the much around the bag.
I was trying to be provocative. Looks like it worked, huh ? Doing maths in Java is pretty unpleasant. For such things I tend to prefer functional languages, but I can see C++ might have its place if you're doing something performance critical. Java's mathematical deficiencies bother me rarely, as I spend my time writing application and server code in domains where "int" is all you really need.
Class library wise, I'm don't like the STL much - or the new Java collections, for that matter, but Java's class libraries go way beyond what the STL provides. Whether that matters to you or not, depends on what you're doing. Lack of portable threading primitives in C++ gets to me for what I prety badly, though, especially since this is the main reason the STL is either thread safe or correct, never both, in all the implementations I've tried.
I don't believe the core problem with C++ is its power. The core problem is the incoherent language design - its been accreted over a great length of time now, with each new level of features trying to make up for the known deficiencies in the last one, and with no sign of this stopping. The different features work together pretty poorly in general: try using old-style pointers with exceptions, for instance.
I frequently find myself being forced to make a decision in writing something that I know will affect any code that tries to use mine, but which I have no good basis for making. For instance: do I return a pointer, a reference or an auto-pointer ?
Expert C++ users (amongst whom I reluctantly count myself, as many others who claim that status know the language less well than I do) generally have a subset of the language, the STL and the compilers they know how to use safely, and some idea of what likely to go wrong whent they step outside that box. Many, however, don't realise that this is what they are doing. Raising these double-bind questions about the usage of C++ tends to get blank looks from may so-called experts on the language, simply because they've never used 1/3 of the language features. Thats not a sign of a language thats too powerful - its a sign of an ADA or PL/1 like agglomeration of unrelated features, in contravention of the C spirit of "worse is better".
The same is true for C/C++ applications. And it happens in practice, for many reasons. And pretty much the same tricks avoid this problem in both cases: create your own object pools.
Java has multiple inheritance for interfaces. Not having implementation inheritance means a little more typing when you implement your design, but it doesn't affect the design itself. And if you really want to, you can automate the necessary delegation with a preprocessor. I'm glad Java left out implementation MI: it would have greatly complicated the language with little benefit to most programmers, who don't use MI even in languages where it is available. But I will admit that this must be a major nuisance to programmers who really plan out their implementations in terms of MI.
Why are there so many Java job oppurtunities that we can't find enough qualified people to fill them?
Here in the UK, Java recently overtook C++ as the No.1 skill wanted by employers. Speaks for itself, doesn't it? And that's not just for web applets - that's for serious, enterprise-scale applications spanning both servers and clients. (I know coz I work on one myself.)
Most of the arguments against Java here - speed, cross-platform support, GUI support - are years out of date. Two years ago, back on JDK1.2, I did some number-crunching tests comparing JITted Java and optimised C, and they were comparable, with Java ahead in some cases.
Oh, and as for cross-platform support, I'm developing in Java on my Psion Series 5mx...
Ceterum censeo subscriptionem esse delendam.
read this for a wonderful and well informed critique of Java (nothing to do with Linux, ofcourse)
well said. Mod that man up!
I say we take off and nuke the entire site from orbit. It's the only way to be sure.
Perl while a fine language and very powerful, is completely unreadable, unmaintainable and un-reusable. Java on the other hand is totally reuseable, maintainable, and readable, because it's not written by HACKS.
Your trolling right ?
completely unreadable - Sure any language is unreadable if you are not familar with the syntax and symbols. I try reading a stretch of Java and I find it difficult because I do not program with it day to day. Does that make it an ugly ? No I am just unfamilar with it.
Unmaintainable, Unreusable - Ever hear of CPAN. There is a fine example of maintained software and is perhaps the best practical example of software reuse in the entire industry.
Written by HACKS. Is that compliment or an insult ?
I believe Perl is more understandable and maintianable then Java because the verbosity of Java. For a given set of requirements a Perl app will contain at least 1/3 less LOC then an equivalent Java app.
There are some theoretically sound alternatives to Java on the Server side that have more profound advantages to languages like Perl than Java offers. IMHO, the leading one here(introduced to me by a friend of mine who is a network architect): Mozart-OZ. Mozart has solves dome of the basic issues of object oriented programing that annoy Smalltalk programmers that are forced by the market to move to Java. At the same time, Mozart goes far beyond the networking capability of Java. The Mozart VM is more integrated with a network later, making it possible to write distributed applications where the network is rather transparent--this solves a lot of problems like session management problems that plague Java and Perl hackers. They have some benchmarks that show Mozart kicking Java's ass. On top of this, the Mozart folks have done a rather nice job with integrating multiple programing paradigms: they nicely handle functional programming, logic programing, constraint programming in one nice neat package. The only real hole here:Integration with databases/relational programming isn't handled as seemlessly here. Take a look at it. I think that my friend was correct when we said if this isn't the future, it is going to be something much like it or better. RJB
I think the reason why Java is a snoozer on Linux is quite simple: lots of choices. Why bother with Java when you can choose from Perl, Python, C, C++, Fortran, Pascal, Forth, Lisp, Emacs Lisp, Guile, Haskell, TCL, Rexx, Snobol, Modula 2, Awk, C shell, Korn shell, bash, and so on. Why bother with the hassles of working with Java with so many other toys in the toybox? I strongly suspect Linux is the defacto standard platform to experiment with languages on. I doubt any other platform today has as many programming languages available on it for free.
I think the biggest feature that's missing is sensible and logical language design. Two languages that take java to the cleaners in this respect are Sather and Beta. I'll bet the person who hatched java has never even heard of those -- although they've both been around a lot longer than the Sun changeling.
I guess I'm lucky. I get to choose what language I use.
No, your children are not the special ones. Nor are your pets.
I just thought I'd correct some of your misconceptions about Java. Are you absolutely sure none of the pages use java? Most java usage now is on the server side using Beans or JSPs. The JSP pages generate the HTML code your browser reads. While there might not be any applets on any sites you visit, java might be generating the content that you are reading.
Out of curiosity, what can you do with Beans or JSPs that you can't do in, for example, Perl?
Java is not a 'buzzword' any more than linux is. I work at a large web company, and I only code in java...under linux. The java API (with a few exceptions) is truly excellent.
Behind the buzzword is a reality. If that reality is merely vapor (VR, I'm looking at you), people go on. Linux is a buzzword that routes my packets at home and provides me a very nice desktop machine. Java was a buzzword that got everyone excited, and when people no longer get excited with it, you still code in it. There hasn't been anything I want to do with it. The "Write Once, Run Everywhere" philosophy behind it doesn't hit me much, but to the point it does, Perl does it. The "don't write command-line stuff" of the 100% Pure Java people rubs me the wrong way, as I mostly want to run in command-line, slocal- or Apache-called settings and the like.
And I hate Java's syntax, but then again, I like Perl's syntax, so some would call me insane. But the reason I don't use Java is because the jobs I tend to program work very well with Perl and the syntax gives me a pain. There are other issues, but the philosophical issues fall far behind the practical issues in this case.
I couldn't disagree more.
I love Java. I'm much more productive in it than I am in C or C++, both of which I use professionally. I find it a superior language, and use it not because of any trumped-up hype, but because it works for me.
And Linux and Java are wonderful together. I use Mandrake 7.2, have used both Sun's and IBM's JDKs, the Jikes compiler, and Ant. Works great, and I have no complaints. I prefer developing in Linux over Windows alot.
I can appreciate some people's dislike of a given language (at the risk of being lynched, I have a strong distaste of functional languages like LISP or Scheme, and I'm not real fond of Perl, a crime, I'm sure...). But there are plenty of us that think that Java and Linux are fabulous together.
I wouldn't do it any other way.
Andy
When properly used, Java may be faster than C++ in server environment. If you try to see benchmarks on, say, XML/XSL parsers around, you may se that Java implemetations top the lists.
:-) If you take a heavy-load web site (where I currently happen to work), Apache+JServ is *much* faster than Apache+mod_perl. And, it seems, the bottleneck in our case is database performance, not Java servlets. Once servlets got loaded (and, possibly, JIT-ted), there's not much performance penalties on running them. Most code of any other server is loaded once and run many, many times, so, server-side Java technologies thrive (several big application servers and frameworks, EJBs, servlets, etc). I seriously doubt that writing web server apps in 'truly compiled' language can gain noticeable performance improvement over well-crafted pseudocode implementations (such as Java + JIT or PHP4 + Zend). And anyway, ever-popular mod_perl is very much the same 'interpreted language' :-)
Javacan be a wasting of resources to serve a wab page if you need to serve 5-10 pages per hour
Computers make very fast, very accurate mistakes
In ten years, when most code is quickly written, instantly portable Java, and Linux developers insist on the continued use of 30 year old C, who do you think will have won the desktop wars? That's right, Microsoft.
Because Microsoft, whatever you may have against it, is willing to change. They didn't stick to assembler, or basic, or C. They use whatever it takes to get the job done, and they change as the situation demands.
So, while linux afficionados continue to write web applicatins in arcane languages like Perl, Microsoft and its supporters will be ahead of them, developing more stable, efficient Java applications.
Face it, Java is the wave of the future. Most cognizant CompSci departments have already figured this out, which is why they focus on the teaching of Java and only Java. CmdrTaco's is willing to ignore technological arguments and quibble with Sun over business practices. This is the kind of partisanship we don't need if Linux is going to go mainstream.
I am,
I am,
Fine
This is funny. The people who support the O/S that has caused me more problems (upgrades from RedHat 6.1 to 7.0 failed on all machines I did it on) don't like something that saves time. When you kids leave your .edu world and actually start paying for anything you'll understand. Until then, please feel free to continue to spin your trikes around and around in a circle.
Linux user's beef with Java is completely hypocritical. It takes too long?!?!? What the hell is Netscape doing when I load it? I swear I can cook my bloody dinner, run 5 miles, get some more groceries and Netscape would STILL be loading!
/. peeps blame how Java crashes browsers on people other than the people who made the browser shows how arrogant and ignorant you are. Unless you have the bloody plug-in installed and being used, the browser's VM is what the applets are using. So, most of the crashes Netscape experiences come from...*gasp*...Netscape's implementation of the virtual machine!
The fact that some
And, also, what do you expect about Sun supporting Linux? Most people can't understand the bloody thing like most of us do and, admit it, it's does NOT have a high market share. So, quit your bitching about it's lack of support. If you want something supported, jump on a bandwagon. Otherwise, until Linux gets accepted by people who are not born with Uniux running in their veins, the support for it will always be a step behind.
Personally, I've found Java to be an awesome language(if you couldn't tell). It's better organized than C++, you can actually understand what a class does by looking at its name without reading up on it for an hour, there is data hiding (contrary to what some people have said), and there's more you can do with it.
There's my opinion. Go ahead, flame me.
I concur. I'm especially tired of hearing comparisons between C++ and Java, as though they were the only object oriented languages around. I'm actually quite surprised that Eiffel has not seen more widespread acceptance in the OO developer community (www.eiffel.com is the "official", Bertrand Meyer-endorsed home page of Eiffel, but I personally prefer SmallEiffel, because it's free). Eiffel is a superbly well-designed object oriented language, and there are compilers available for pretty much every platform under the sun. The "compilers" are really just Eiffel to C translators, which then pass the resulting C code to a C compiler. The result is very efficient programs (probably not as efficient as actual C code would be, but certainly more efficient than Java or C++).
An excellent book on the subject is Objects Unencapsulated, by Ian Joyner. It's the only book I've ever read that does a blow-by-blow comparison of C++, Java, and Eiffel. It's pretty dry reading though, unless you're heavily into the OO stuff (as I am).
Not to malign Java, there are some good ideas with that language, but for a pure OO language, I've yet to see anything more impressive than Eiffel.
--
www.scorbett.ca
By far the worst part of Java(TM) is how Sun marketed it. Their goal was to make an API that was cross-platform and would unite programmers everywhere. Unfortunately, with Netscape's Java(TM) follies and Microsoft's performance-tweaking of the VM to make their libraries, Java(TM) became a nuisance, and later, an abomination. Nowadays, just the mentioning of Java(TM) in a program's specifications conjures up images of having to terminate the stuck process. Hell, even some programmers took the source code to the Q3 vm files and recompiled them into x86 DLLs, and there was a framerate boost and a 50% UI navigation speed boost.
However, by far the worst implementation of Java(TM) is for those stupid applets. The infamous "Punch/Shock the monkey and win $20!*" banner ad springs to mind; the ironic thing is that the applet seems to run faster on slower systems; my mother's P5 233MMX with 64MB of RAM runs it faster than my P3 500 with five times the RAM. Also, there's those online casino applets; every day I see this one person seem to spend hours on end clicking on those stupid things. The Java(TM) applet, and therefore Sun Microsystems itself, is responsible for the "moronification" of hundreds of thousands of Internet users.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
One of the *first* things I do to class MyServlet derived from Servlet, or whatever I want to name it, is to create a function 'out'. In servlets, we want to write to system.err most of the time, so that's what it does. It also checks a flag to find out if debugging is on or not so that the servlet doesn't stuff the log. Now, writing to the log is simply:
out("Object orientivity will allow you to do things you never thought possible.");
I used to be a C++ bigot until I used Java at a job, and after using Java, I no longer wish to *ever* use C++ again. It's like banging rocks to start a fire, or using Oracle. Wait, that's another flame war...
A society that will trade a little liberty for a little order will lose both and deserve neither. - Thomas Jefferson
You can get it here if webappcabaret is up, which it generally is these days. Otherwise e-mail me.
Please give some respect to the Blackdown guys and their fabulous work. Thanks to them, I can run my Advanced Imaging servlets on Linux!
And by the way, most of the ISPs who offer Servlet hosting run Linux. Isn't that enough proof?
Barney's a little on the looney side. His predictions have all fallen flat, and I detect hints of sour grapes that his baby is getting wailed on ("Denouncing all code written in languages other than Java as "contamination" is insulting to programmers") I still use C++, but only when I really, really need to. For general purpose applications (servers, clients, tools), there's no reason not to use Java. It takes less time to get it done.
I hate to argue against opening something up for standardization, but Sun controlling Java might help out steering the language better--control by fiat. I would argue that C++ was screwed by the ANSI committee, and by how many implementations and versions were propagated before the "final" ANSI version. Namespaces, exceptions, even templates have been severely hampered by this slow standardization process. Check out what C++ features Mozilla uses (answer: just about none). The reason? Varying levels of C++ compliance, from lots and lots of different compilers. I don't think that's happening to Java with Sun at the helm.
If I haven't convinced you, this should... order of includes is tricky in C/C++. Really couldn't care less in Java... (imports order is irrelevant)
Other evilness: incompatible includes! Under win32 you cannot include both windows.h and MFC classes... you've got to navigate a tricky road. That would never happen in Java. You can never have incompatible classes unless the bear the same name and are in the same packages... (very unlikely if you use the proper coding convention)
Since then, I've become a sysadmin
"...and, I've _completely_ forgotten how to code."
and I know that java is very fragmented already
"...and I haven't been keeping up with the industry either..."
but most programmers, once they learn java, use it for everything no matter what the problem
"...I never thought that maybe it's very useful for many different things, oh, wait, a user can't print again--lemme go fix that..."
there's always a "best" tool for every job and java isn't it in a lot of cases
"I'll just pull this out of my ass because it looks so 3lit3. Oh, uh, 31it3. 31i43? 33l3t3?"
See, it's not just me!
"Me too! Me too!"
Yeah, Java should have been the darling of the Linux world, but unfortunately, Sun was a little late getting Linux users an invitation with a native JDK. If it hadn't been for Blackdown, IBM, and the other projects lost to my memory, it would probably be a question of why Linux didn't have a JDK period. I used to preach to people how Java was such a wonderful thing, but unfortunately Sun has up until recently neglected platforms other than the core Windows/Macintosh/Solaris.
Second, I've never found much use in one. Give me a good text editor (read vim), a build system, CVS, and a command line. An IDE is just something pretty that makes the average programmer feel better about themselves.
...and where wouldn't an IDE help out? If anything else, an IDE (ala Smalltalk) provides:
You've obviously never used a good IDE. A good IDE actually helps one code. I've not looked long and hard, but I've not seen a worthwhile IDE for C/C++ (although ddd is nice to have). They're all just thin wrappers around a compiler and gdb.
However, in almost every Smalltalk environment I've used, I've found a great IDE that actually helps me do my work better and faster. Exceptions being GNU Smalltalk and Tim Budd's Little Smalltalk.
In the past, IDEs have been very useful for rapid development. They allowed you to visually represent something and out pops 1000 lines of code to build that pretty window you drew. Because of the structure of Java, really object-oriented not just kind of like C++, rapid development is inherent. You subclass a window type that is pretty close (something for the Java API or your own class), spend a few lines tweaking it, and show it.
an Inspector (or even better, an ObjectExplorer like in Squeak): Look at the values of your objects, poke around. Far more powerful and useful than printf and assert statements littered throughout your code.
a Code Browser: Look at your code method by method, class by class, not in a huge flat file. IMHO, allows for a lot better focus on the method at hand. Also, have you ever refactored your code? Ever have to rename a class, push a method up or down (into the super- or a subclass), or modify your design? If not, you're probably just coding a cheap hack rather than a real piece of software.
and a Debugger: fairly self-explanatory.
If the only IDEs you've ever used do naught else but gen code from a spec or from a painting of the UI, you've never used an IDE. Not a complete one anyway.
What IDEs provide is another way to grok your code, to find bugs. The result? Better software (in function and design) and fewer bugs.
Yes, I agree that IDEs make the difference.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Average Joe User may not care about embedded systems. However, over half the core linux-ppc kernel developers are employed by companies doing embedded work and so presumably DO care. I am also employed to write free software by an embedded system company, and I care a lot. There are a lot more of me where I come from too; professional embedded-systems types are generally a less vocal lot, but there's a surprisingly large number of us.
I'm not so sure 'bout the last statement, but then I'm not the Java guy at my company -- and, despite being a large and well-funded company, we have just one java guy. Frankly, I don't think the aversion to Java is entirely a pragmatic thing -- many of the systems we put together are large enough to use Java, and reliability would likely benefit; however, most of the people who've been doing embedded systems work for years (and there are far more oldsters in the embedded field than most other linux-related areas) are used to working with the lowest-level language practically usable because of a need to eake out every last bit of performance. They're not comfortable with it, and in their area that's a Bad Thing; nearly all succesful embedded systems use old technology because the important thing about them isn't speed or some newfangled nifty design feature, but rather rock-solid reliability, largely gained by using only things you understand well and techniques that you know have worked before.
Of course, I'm making some generalizations here. However, they strike me as being correct for the majority of cases.
I don't see how making a malicious macro tweak somewhere would be any different from changing the behavior of a method in a base class that gets inherited, say...
Either way, you have some hidden code that gets run, all in the name of code reuse. The point is, you shouldn't be maliciously editing code!
Macros and inheritance are both powerful tools to be used and abused. Therefore, they should be used carefully, not forbidden completely.
Also, you should get at least warnings about macros that get redefined...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
A simple adjustable wrench is the solution for tightening and loosening just about every nut. For the hard to reach nuts, or the ones with a weird shape, you pull out the special wrench. Once done, you put that special wrench away and go back to the simple one that works the best.
How could you not win everyone over with such a persuasive and well reasoned argument?
When are people going to learn that language advocacy is half about pushing your favorite language, and half about the gorgeous flame wars?
Oh, and by the way, such _devastating_ sarcasm from you. It's almost as if you didn't learn it last week in your remedial lit classes. Congrats!
Compare that to the memory bloat problem: no real way to duck that one without taking a hit somewhere else. Sure you program works- but what is people biggest complaint about it now: slowness. To optimize the memory handling of a GC'd language program is tough and non-trivial. And since the code is all technically correct- there is no objective way to know that you have really fixed the problem.
Whereas with a typical compiled program, once there are no memory leaks, any optimizations are pure bonus- and usually very easy to figure out how to do/implement. A large portion of production programming is hand optimization. The very act of staying alive is an act of hand optimization. Its what humans do.
tell us how you *really* feel, Taco.
illegitimii non ingravare
I don't write byte-level machine/C++/Java code anymore (you poor bastards!!) - I layout DB schema. And in my world, you are extra wrong, b/c if you lay out a naive schema, and then dump 10 million rows in it, you are fucked. No amount of optimization and denormalization will save you, because you didn't think of scaleability first.
I've been using java for 3 years now under linux. The situation isn't half as bad. Most linux people (non java people in general) tried java once, when it was at version 1.0 . What poeple do not seem to grasp, is that java has become _a lot_ faster since then. Certainly, some parts of Java are still slow. For example, initial application loading and SWING. However, I happilly run java text applications that I develop under a 486/dx2 66. Since java's initial release, many companies have been interested in it, most notably IBM. And IBM's jdk for linux is FAST. IBM's Java 2 SDK 1.3 was actually out for linux before sun's was. Java is also the most elegant programming language that I have ever used (granted, I haven't programmed with any functional language other than prolog yet). It most certainly isn't bloated. It simply provides a HUGE library of functions/classes and methods, but it doesn't load them all on startup, only the ones that you actually use. And that's a very good thing, because it provides programmers with fast implementations of very usable tools like hashtables, StringTokenizers etc. It's like complaining that C is bloated, because of GLIB. Moreover, remember that Sun provides a Java Virtual Machine that runs on PalmOS machines. Can you say "light-weight?". You can actually run java applications (and FAST! (there's even an AWT implementation for the PALM)) on that 16Mhz Dragonball processor with 2 MB of ram. Java is also getting more and more accepted. Do you people know that recent versions of GCC (2.95.2 I think) can actually COMPILE java code to native code? For people not liking swing who only want do develop applications for Linux, there are even GTK bindings (and a GTK look-and-feel) for Java. This effectively means tighter desktop integration. Java also provides a formidable Remote Procedure Call framework. Java is also extremely well documented. Anyone who has taken a peek at the javadoc can certify that. I understand that Java is under a non-liberal licence. This needs to change, and I seriously believe that it is going to. Sun has claimed that it fears that the java spec will fork. Can you not blaim them? Every week we hear stories about the Linux kernel going to fork. I don't believe that either java or linux is going to fork, but I can understand sun's worries. I also think that the cease-and-desist letters that taco got sucked, but that's hardly a reason to hate Java! Try IBM's jdk-1.3. Apart from initial loading, you'll find that it's almost as fast as C++.
Reading through some of the above posts, I get the impression that people are still thinking about Applets when they think 'Java'. Applets have been dead and buried for years. Nobody uses Applets anymore. They sucked then, they suck now.
Where Java shines is on the server side. Download Tomcat from the Apache site (or Jserv), write a couple of servlets, and then comment.
If you were going to write a post putting down Java, and your last experience with Java was writing a little crApplet 3 years ago, stop and think 'am I qualified to comment on this?'
All the large Perl and VBScripts I have seen are considerably more difficult to comprehend and maintain than the equivalent Java code. Ask anyone.
The fact that Perl support some OOP principles doesn't make Perl "OO". Hell, even Matlab is being advertized as being OO... I even have had arguments with people who say C is an OO language.
What you must do is look at the actual code being written. What methodology does it use? How is the resulting code? Java code is always (99%) implemented through OOP and good coding practices are forced upon the programmer. Perl works well for small projects but as soon as it grows, the various deficiencies in the language (which people consider as features because they make things "easy") become apparent and make scaling difficult or even impossible.
SQL is query language supported by Java... but SQL used alone is indeed a procedural tool. It doesn't scale well beyond a certain degree of complexity.
The point is, Perl and VBScript are languages which *seem* easy. That is, they are very easy if you have an easy problem to solve. For difficult problems (the problems I care about), Java is a much better tool.
About smart pointers- well yes they can be abused. I'm not sure what you mean by two instances in one chunk of memory- I do however use shared buffers with reference counts. (one instance in one spot, just shared) Its actually rather simple- just a few access functions to handle its interface. Could even be a little template class if you fancy having all types of shared objects. I never get into massive amounts of overloaded operators.
About "your program doesnt work"- the idea was that the developer would use leak detectors, to verify that his disciplined code does not actually leak. Even if it does have a leak in a strange place- that will hardly make it crash or anything- you may just have to restart it after a long time running. And while this buggy program runs it will probably be fast.
About memory bloat: its choosing between caching lots of objects that you may or may not use again and constantly creating them anew. Either way has a draw back and an advantage. Also considerable is the pool of memory the GC has to keep around just for itself to have room. (Newer GC schemes are always improving in that aspect though)
Another nice advantage of C++ programming: many programs dont even need to use the heap whatsoever Everything on the stack and maybe a static global or two. In java you have references on the stack to things that are on the heap- needed or not.
Multiple inheritance is far more complex, no matter how you put it.
That's true you don't have to type more code... but the complexity under large projects remains...
Its crappy.
What??? That flamebait comment was moderated up to Insightful?
Then, it's sadly true. The linux-users amongst the Moderators don't like Java at all...
But I would have hoped they had better arguments then that. *Sight*
You're correct. I meant write only. And I only meant to take a jibe at perl in a good natured way. I didn't say not to use it. :-)
I'll see your senator, and I'll raise you two judges.
Linux and Solaris users tend to be very concerned with performance more then Windows users. To be honest I think the biggest reason Java hasn't found a home in Linux was the lack of a quality JDK. For the longest time JDK support under linux was way behind the quality and speed of its implemenation. That's sun fault.
Sun was never interested in java until IBM got involved, and make no mistake about it, IBM is far more important to java then Sun. IBM spends twice as much Sun on java development. Of the 33,000 tests in the Sun Java Compability Test Kit (JCK), 22,000 of those were developed by IBM. IBM's investment in java is simply huge, and given their new linux direction and focus, I full expect full java ports of WebSphere to help java find a place on the smaller linux platforms.
Java's place in this world is the Enterprise server level, not embedded servers as the author of the article laughably suggests. Enterprise means big hardware, and big money, and quite frankly linux's Intel ties are part of the problem. Quad or eight way xeon machines just don't offer as much as the solaris or hp-ux big server racks. That may not seem important to the average slashdot user, but it is critcal to SprintPCS running SilkNet on 50 WebLogic installs or to Charles Schwab running the 40 installs of WebSphere on IBM hardware.
These are the companies that are driving java development, and they're not real interested in 'toy' Intel deployments. Intel knows this all to well, and has developed the Itanium chip in response. It should be interesting.
Now, as for java performance, its pretty easy to write a slow java app, I'm talking server side, as most java apps use HTML/JSP for their client side interaction. Its difficult to profile a java application, so tweaking it after the fact is very not smart. You MUST keep in mind performance as you create the java application. Garbage collection, exception handling, and database I/O are all major java chokepoints.
As app server vendors start search for new markets (with the big customers having bought their server licenses already), linux will be a more important focus for these vendors, and java will start to play a larger role in their product plans.
EvilJohn
Less Talk, More Beer.
Copy constructors dont allow such behaivhor. Any class containing pointers to dynamic memory will have to define a copy constr and op= to handle these cases. You must either use ownership flags, refcounted buffer, or simply new copies.
As for new being expensive- yes that is true. However you are always free to devise your own memory allocation helpers where it is expensive enough to matter. 80% of the time I can avoid using the heap altogether- and when I do its in places where it is handled automatically by contr/destr, to minimize the possibility of a leak.
Dealing with all the myriad ways and places usually calls for some programmer restraint in C++. What I like though, is that I have choice and control. Some prefer a simpler and more restricted way of doing things, which has its attractions.
Java has a lot of unnessecary restrictions. The type system should be much more powerful, like the ones used in Haskell or Clean (ok:Generic Java and Pizza address these issues). However, Java has not many conceptual advantages compared to other widely used languages.
.NET. I wonder how much effort it would take to implement .NET for Linux.
In fact, developing software in Java does NOT save much time compared to C++ (does it save time at all ??). Why should I write programs in a language, which gives me slower programs and doesn't save effort ?
Look at other languages like Haskell or ML. These langages have a real conceptual advantage and langages allow writing programs in much shorter time (I read about 1/7 in a comparation and fully agree with this). The execution time is comparable to Java.
There are no advantages in using Java! Drop it.
Btw.: Haskell is being ported to
Politics aside, I have found Java, as a language, to be the most organized, powerful, and secure language out there.
You can cry about Sun being so mean about their logo, or their license sucks, blah, blah, blah. Thats politics, not java.
Slow?...oh yeah, it's damn slow. But you have to remember what it's purpose is, multiplatform. If you are going to run it on a Linux box only, good God, write it in C.
You have to use the right tool for the right purpose.
- I like pudding.
The little used MAYSCRIPT in an applet tag will allow Java && JavaScript communication. So there is some relationship as far as working, but not in the Arkansas family way
If your code looks anything like the Invaders game in the Black Art of Java Game Programming, I will laugh my ass off.
I say we take off and nuke the entire site from orbit. It's the only way to be sure.
Your statements about the Java language, VM, libraries and IDE are right on the mark, in my opinion.
However, you're forgetting about one other key aspect of Java usage, and that is its integration into web browsers. The web is the window on the online world these days, and you can't ignore it.
So here's the crunch: Java has never worked adequately with Netscape, full stop. For a few people, it just about works. For the vast majority, it has never stayed up for more than a few seconds when accessing Java-based sites. In our organization, for 4 years, every single version of Netscape has always crashed, immediately, on dozens of Linux distros, for many dozens of tech-aware people, despite numerous fixes advised by others on the net (many here on Slashdot) to no avail.
In a nutshell, Java is seen as crap because Netscape's Java support is crap. Nothing else matters. It's a blight on poor ol' Java, which as a language is quite reasonable, but doesn't stand a chance in hell of getting accepted by people who's every exposure to it is greeted with a crash over many years. The whole situation sucks bigtime.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
the source code is available. This is sufficient for 99.9% of us. Let's get real here.
The JDK cannot be put into a Linux distribution. The Sun Binary Code License (under which the JDK is released) doesn't even allow redistribution of the JDK binaries to those who don't have the money to pay cents per minute for telephone line access (local toll calls are the standard outside of the US) to connect to the Internet.
Will I retire or break 10K?
Why is Java on the requirements of the job? Because perhaps it's java that generates the web pages. Perhaps it's java that the servers run on. Perhaps there are java components somewhere.
"Java makes it hard to do easy things and easy to do hard things."
probably about 50% of my development work is in Java, but you don't see any java applets or java code on our web pages.
Think before you speak.
-- I ain't broke, but I'm badly bent.
For once I emphatically agree with CmdrNacho. Java stinks. It takes up too much space, and is incredibly slow, and FFS don't get me started on the Java support in nutscrape. The licensing thing aggravates me too. Where do they get off making us "ACCEPT" a licsence after they so boldly pulled that fast one with blackdowns JDK code? I mean let's get real here. They blatently distributed blackdowns code as thier own, and then required us all to aggree to thier liscence. I hate SUN, I hate java, and worse yet. I hate when I need a tool for linux that's ONLY written in java (read: AirportConfigurator.jar)
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
C is:
-most simple
-most portable
-most universal
-most concise
-most easy to follow somebody else's code
-most "cut-and-paste-able" from project to project
Amen to that! Pity I don't have any mod points today. :-)
Still...you have to admit it's a good language to learn the basics on. You HAVE to do it right in Java for it to even work. Knowing the way things should be done is useful. I learnt C++ without learning more than the basics of OO. But when I was forced to learn Java by my university, I HAD to learn OO, and when I figured out what OO was all about I was amazed at all I had been missing until then. I frequently ignore OO concepts completly when they aren't neccesary, but I'm still a better programmer for knowing them. The value of Java isn't in knowing it--it's in knowing what Java forces you to learn.
To THAT extent, employers wanting you to know Java might have some merit. Not that they want you to USE it, but that they want to know that your familar with a range of programming concepts and language styles.
Whitespace in python is ridiculous? I can't let you get away with saying something like that ;)
;) use indentation coding guidelines.
;)
Disclaimer: I haven't used python - but I have used Haskell (a functional language that is also uses indentations for block structure). I'm assuming that you're complaining about the idea of indendation structure.
I have a question for you - why are the "{" and "}" there in C/C++? For programmers? Nope - if that was the case, mode coding guidelines wouldn't say things like "always indent when you use curly braces".
The fact is, the "{" and "}" are there for the compiler. No other reason. Back in 1970, memory was limited, and the compiler's scanner simply threw away all whitespace.
But this isn't 1970. Memory (for the compiler) isn't as limited. All of us (most of us
So why bother with the "{" and "}"? The answer ends up being psychological rather than technical - "that's the way we did it when we were kids, and it was aweful and we liked it" (With apologies to SNL...)
And now to get this back ontopic... I think Java would be more successful if Sun added the option of indentation-bracketing
'nuff said
i'll keep plugging this 'cos i think it deserves attention. i would do so even if i wasn't working for the company...
Limbo which has a similar thread-communication model to Occam's (if anyone's heard of Occam... no, thought not).
it uses synchronous channels:
somefunction() := chan of int;
{
ch
spawn otherfunction(ch);
ch <-= 99; # send value down channel
}
otherfunction(ch: chan of int)
{
print("received %d\n", <-ch);
}
easy to use, and easy to reason about. one thread blocks until the other has received the value, hence the primitive can be used for locking, etc.(sorry, can't remember how to do indentation in html...)
And your point is?
That fact that multiple languages may work together in concert to solve a problem doesn't mean that the languages are related in any way.
My point simply was that Java and Javascript are two different beasts. It is very unfortunant that the names cause people to often think there is some relationship between the two.
I'll see your senator, and I'll raise you two judges.
I disagree. I've worked with both languages, and I hate the fact that in the process of rearranging code in an editor, you have to be careful to avoid losing the indentation. With explicit block markers like {}, this just isn't an issue. So no, it's not just psychological, and won't be until program editors become much more intelligent.
you are only talking about one use of it - yes, it sucks for applets on the page - but it is nice for back end stuff and is fine for that.- -------
------------------------------------------
There are some odd things afoot now, in the Villa Straylight.
There's a really dumb reason for that - Java internals have this nasty habit of deciding to hold onto the reference of a String - I suppose it saves memory since you have two references to a string and not two instances.
Same reason Color objects are immutable.
Well, for every possible tuple I might want, yes. Do I really want a directory full of Custard$ResultFromABCMethod.class, Custard$ResultFromXYZMethod.class, Custard$ResultFromABCButWithAnExtraBoolean.class? I'm more likely to kludge it, I think, using private member fields as result passing.
For the finished result, try a jar file. Nice, compact, no little files all over the harddrive. Java 1.2 supports compression in them too! (A jar file is a glorified .zip file.)
Um, BTW, how many tuples do you ever need to return? Ever consider trying to generalize them into an object? You shouldn't need thousands of tuples - a generalized class should do.
I wanted two timers to call back my class at different intervals. Obviously they'd both call the same method, so I wouldn't be able to tell between them without writing extra glue classes.
Inner classes, inner classes. They're all over the place, often used for exactly that purpose. Especially because an inner class has full access to all it's parents fields (including private!).
Well, the first few exceptions I stumbled across were MalformedURLException and InterruptedException.
Oh yeah. Those. Almost every time I have ever run across them, I have found myself trapping them and ignoring them. (InterruptedException especially because often it has no use at all.)
HOWEVER - the point stands that you should be forced to plan for them - Java forces people to be ready to trap an exception - so you can't skip an exception. Often times its annoying but it forces better code design. Once you get used to Java exceptions you'll find them quite useful - I couldn't program without them.
Most exceptions aren't RuntimeExceptions for exactly the reason that you shouldn't be tempted to ignore them. For example, an IOException really shouldn't be ignored. And try{}catch() blocks don't really add any overhead, so ignoring useless (like the MalformedULRException) exceptions is OK. (InterruptedExceptions shouldn't crash your program - I often use them to wake up sleeping threads (sorta - it does something every x seconds, and then needs to be woken up to clean up or whatever).)
You are in a maze of twisty little relative jumps, all alike.
There is a world outside web development.
A much, much bigger world.
---
I beg to differ!
:-) I would swear that is the best IDE outthere (and many of my team mates agree), but I understand choice of IDE is a 'religion'.
...etc. Any one who has used DDD's visual data representation would understand what I mean! (for example, it will draw the linked list with values & pointers. THis is much neat than seeing hex dumps of structs in GDB. Okay it uses GDB as underlying debugger!)
I was a VIM/gcc (or javac/jikes) fan for a long time. Still am.
Then I found somethign called Jbuilder (from Borland or Inprise what ever the current name is), and fell in love
Our typical programs have about 100+ classes and and IDE visual representation of classes / layout is INDEED very nice. You would argue, that you should know your program intimately, not having to use an IDE to decode the logic. But in companies, these programs are built by programmers who are long gone, and reading the (obsoleted) java doc comments doesn't get you any where.
Also the other BIG bonus, I would go for IDE is debugging. No, no, not the PRINTF kind of thing. If you want to put break points, inspect values, change them on the fly
So, yes, IDEs play a big role in 'language accepetance', and given Java is fairly new language (compared C/C++) it can do nothing but improve...
LinuxLover
If you say that Netscape's Java support sucks I would agree wholeheartedly. However, If you avoid using Netscape's built in Java support, Java works great. Most of responses I have read seem to be focused on client side applets. I think people should not overlook the power of Java Servlets. Java servlets are superior to CGI programming in almost every way, even on Linux.
The greatest thing about Java in my opinion is its methods for doing internationalization and localization. I just can't deliver the same timely, quality solutions in an international market using Perl, C/C++, Python, or anything else.
For me and my needs, Java is simply the best. Most of the Java-bashers I have talked with have changed their opinions concerning Java when they see some of the amazing things you can do with it, even on Linux.
wtf? no first post? an actual relevant comment? how the hell did that happen?nothing but bad lazy trolls around here...
oh, and have you ever noticed that our logo isn't the sun logo?
You mean that gray thing with the brown in it is the /. rendition of the Java coffee cup? I always thought it was a waste basket or a potted plant...!
BH
Fools! They laughed at me at the Sorbonne...!
I don't understand all these put-downs of Java.
How many of you have ever been there? I've never been there, but I've seen it in National Geographic, and it looks nice. Kind of like Florida.
And what's all this nonsense about Sun trying to control Java? How could they ever hope to wrestle it away from Indonesia? They have to give Solaris away, for Pete's sake!
- Roseanne Rosannadanna
The only thing that we learn from history is that nobody learns anything from history.
Many years ago i read some asshole's opinion about 'real programmers don't use c++'. According to this guy c and especcially assembly were far more suppioror then c++. I wonder if this dude is still coding his stuff in assembly.
First, why knock Java because of its IDE? First of all, it doesn't have an IDE. IDEs are value-added products by third parties.
Second, I've never found much use in one. Give me a good text editor (read vim), a build system, CVS, and a command line. An IDE is just something pretty that makes the average programmer feel better about themselves.
In the past, IDEs have been very useful for rapid development. They allowed you to visually represent something and out pops 1000 lines of code to build that pretty window you drew. Because of the structure of Java, really object-oriented not just kind of like C++, rapid development is inherent. You subclass a window type that is pretty close (something for the Java API or your own class), spend a few lines tweaking it, and show it.
The best part is that the developer is left close to the code, not abstracted from it like rapid prototyping IDEs do. The result is fewer bugs.
No, I don't agree that IDEs make the difference.
CmdrTaco writes:
"(oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use)"
Well, this is, I guess the difference between a company like IBM (where internal help was applied to the legal departmnet to allow Slashdot to use te IBM logo), and Sun, which essentially cease-and-0desists anyone and anything, and hopes to build good-will, and support for their technology that way.
Well, the fact that JAVA, essentially, has been reduced to just another buzzword with nary mcuh use for anyone is a good start for Sun's demise on that front.
Harry
Many of the WLS engineers run on Linux. One of the first things I did at BEA was to give Windows the boot and do all development on Linux. There were some issues involved (mostly with getting Oracle's drivers to install themselves), but I loved doing java development on Linux. So do several other WLS engineers.
Then there's the issue of some of the native code which WLS uses to get real performance out of Java. That has variously been supported and non-supported under Linux, basically based on whether the linux-loving engineers had kept up with the Linux port. We've tried to get it running in our use of it here now, and I don't think we've had a ton of luck with it.
If you were to take you .jar files and move them from linux to windows or vice versa, it should work (i.e. your user-provided .jar files). And if you just take the weblogic.jar files, they'll work as well (remember, if you download the 100% pure java version of WLS, it just ships as a platform-independant zip file).
Glad to see that a lot of posting has been redirected to Sun and not to the Java language itself. As mentioned before, java is used in many open source projects. The only 2 cents I want to throw in:
Performance is always a relative thing. Processor speed keeps on increasing. 3 years ago some of my java apps were slow. But nowadays on a 950 Mhz Athlon, things going pretty smootly.
I'm glad that the designers of the Java language did not make any concessions in favor of speed above the architectural design. Speed is solved by the hardware folks.
SFMarco
It turns out that this is not the case. Although C++ allows egregious coding decisions- it does not disallow good coding practices. It is the highest level language I know that gives me complete control of what the program I create does. When I program in C++ I can imagine what the assembly created will look like- and what it will do, and how it will do it. With java I cannot. You never really know when or how something will get done.
This is because C++ is about allowing you to do things, whereas most other languages restrict what you can do. It is a sharp tool, and you can hurt yourself with bad form, but it allows you to make fully object oriented code for everything from device drivers, to gui applications, or even JVM's.
And another thing- Garbage collection. When you dont have it you may have to hunt down memory leaks. But when you do have it you must hunt down memory bloat- the converse problem. Many java programs bloat up is size because uneeded large objects are left laying around referenced. This is a problem I consider equivalent to memory leaks, but much harder to detect and debug.
For me, using java to get something done in a large application feels like trying to use a play-doh knife to carve a turkey.
The opportunity for Java to flourish on Linux is on Linux web servers. Aren't web servers one of Linux's best penetrations to date?
Your choice is to create dynamic websites using Active Server Pages (ASP) on Windows servers (IIS/PWS) or Java Server Pages (JSP) on Linux (or Windows, Solaris, etc.)
I have programmed both ASP and JSP for a few years now and they are roughly equivilent. ASPs are easier to write and debug but JSP have many strengths (same language cross-platform middle-tier development via Java Beans) and a richer environment due to your access to the entire non-GUI Java API (class libraries).
Java Server Page Application servers are available both commercially (Allaire JRun, IBM WebSphere, iPlanet, etc.) and Open Source (Tomcat/Jakarta from the Apache folks) and JSPs/Servlets run on LOTS of platforms (I hate O/S lock-in like I hate vendor lock-in).
I have not used PHP or Python but I'm guessing they do not support same language cross-platform middle-tier development. That is, can you program a persistent, multi-user business logic layer in PHP or Python like you can with Java Beans or EJBs?
I have no love for Microsoft's answer to a middle tier (COM) as it is not cross platform, does not even try to look open or free, and is best developed using a different language ('C') from the webpage scripting language (typically VB Script but could be JavaScript).
Java lets me program webpages and middle tier in the same language so I have one set of tools (and yes, they are getting better every day). I often prototype functions in JSP and then move the same code to the middle tier when I find I need logic reuse.
You want to hurt Microsoft and promote Linux? Then get your Internet Hosting companies to offer JSP/Servlet support on their Linux offerings like the do with ASP support on their NT server offerings. Otherwise people will code ASPs on NT servers as the path of least resistance.
Put religion aside and think seriously about multi-vendor, cross-platform coding. That's where you offer your customer a value proposition. Commercial solutions are not "bad" just because they are commercial. They are "bad" when they limit your development and deployment options.
I'm scared of world leaders who think locally and act globally.