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*
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
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.
On the good side I really like the design of Swing. Sure it's slow and buggy, but it's nicely designed and powerful.
> 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.
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
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?
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.
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.
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.
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.
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.
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.
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
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
>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.
> 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.
> 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.
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.
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
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
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 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
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.
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.
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
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.
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
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
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.
It's just too damn hard to write obfuscated code!!
;)
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.
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
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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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.
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 ...
Damn straight I want to address the actual devices I plonked down all that money for.
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.
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.
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.
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.
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"
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.
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.)
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
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); }
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.
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...
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.
Totally agree on that. I'm working in a team with guys using linux and developing java. Guess what, they never complain and are happy using Linux and developing Java.
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
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
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.
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
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.
> 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
- 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.
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.)
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.
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.
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.
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?
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 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.
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.
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.
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
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.
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.
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
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.
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?
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.
Moderate this article (-1, Flamebait).
-no broken link
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
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.
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
#define const public static final
Thank God they didn't include macros in Java. Whenever I have to read larger portions of other people's C and C++ code they're the ultimate source for confusion. In terms of maintainability, they're hell.
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.
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.
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.'
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.
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.
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?
I don't thing the Hashtable vs HashMap thing is so bad. Having both synchronized and unsynchronized hash table is classes is useful. Of course, the names could be better (replacing "Map" with "table" doesn't really indicate much of anything)
The API does have numerous warts. The lack of anything like select() (as you mentioned), the completely awful design of the File class, numerous quirks in earlier versions of AWT, the rather poorly defined Image* classes, things in the wrong packages, packages with bad names (ie: java.sql probably should've been called javax.sql or javax.jdbc), the incredibly stupidly named Calendar class, and the list goes on.
Things are getting better though, and the nasty stuff is slowly being deprecated away. Pre-ANSI C was pretty icky too. It took roughly 15 years for ANSI C to be developed after C was created. Java's a fairly young language, so it isn't too surprising that it'll have some growing pains. It's interesting to note that most of these problems are in the API too, not in the language itself.
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.
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
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.
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.
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 isn't how it's done in industry. Frankly I don't understand why anyone should introduce Java via GUI programming and even worse JavaBeans. If you want to see what real Java code looks like, look around Sun's site for the example programs used in the Java tutorial(the only source you need to learn Java) and take a gander at those.
You may also search on Google for Open Source Java applications, there are lots of them.
Grabel's Law
- 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.
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.
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.
I think you missed his point.
If you randomly edit C++ in the way he suggests it might be a huge job trying to correct it -- which he is implying is a deficiency in the "design" of C++.
If you randomly edit java in the ways you suggest, it would relatively easy to find and correct. Not to imply that you couldn't introduce subtle bugs in other ways, but the way he suggested screwing up a C++ file is also trivial to screw up, but difficult to find. In Java it would be difficult to screw it up in a way that is difficult to find. (Hope that made sense?)
I'll see your senator, and I'll raise you two judges.
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.
I moderate this article (Score: -2, Troll). Really guys...
end communication
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.
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.
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.
You do know that "using Java" goes far beyond allowing applets to download to Netscape, don't you? Particularly using J2EE, Java's enterprise network tools, Java is rock-solid on Linux. My team and I have about 12 development versions of our company's site, utilizing JSP, JavaBeans and Enterprise JavaBeans, JDBC, Resin (as a JSP engine) and WebLogic (as an application server) and it's been one of the best, most stable environments I've ever worked in.
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...
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.
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.
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.
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.
I'm tired of that argument. Anything can be accomplished in C++ as long as you play by the operator rules. In this case, the operand left of the + HAS to be a string object, otherwise it doesn't work. In other words
CString Text = CString("Count = ") + Count;
works, but
CString Text = "Count = " + Count;
or
CString Text = Count + CString(" items");
doesn't. I simply find restrictions like that too limiting for something as uniquitous as strings. Strings should be built-in data types, period.
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
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.
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.
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).
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.
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.
Well, for starters, it violates one of the basic tenents of Java: no operator overloading. Ever. Most string handling does, as Strings have a whole load of special rules applied to them. Its not that much of a pain, but I'd love to be able to apply some of those special rules to my own classes every now and then. Operator overloading can be dangerous if overused, but what can't? Used in moderation, it can be very handy indeed.
As a warning, I'm a dedicated OO programmer. It just seems to fit the way I think better than functional programming, for most things. But I do tend to code with a mix of the two, when needed, and I don't really like it how Java forces everything to be OO.
(Yeah, apologies if the terminology in that last paragraph is a bit screwed up. I'm tired)
-RickHunter
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.
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?
You obviously never have to maintain anything if you disapprove of descriptive names in software. I hate lazy coders who would rather call a variable ccn rather than credit_card_no. I'd rather the original coder was thinking of the poor sod(s) that have to look after his/her code six months down the line rather than just trying to save him/herself typing a few characters.
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.
As much as it pains me to say this...
Use IE on MacOS instead of Netscape. (Ouch! that hurt!)
It comes preinstalled with the OS. It works. Java even works. It's faster. And did I mention that it works?
I'll see your senator, and I'll raise you two judges.
Yes it is getting cheaper and faster. But apparently not fast enough to keep up with the lazy coders who make such statements.
Every time I see a statement like this, I see red. It is people like this who waste endless hours trying to make a program that will run well on a 286 that have no practical sense of reality. You must live in an ivory tower and not have to pay any bills.
There may be some truth to what you say.
I certianly am not a lazy coder. I look for efficient algorithms, and do performance measurement and tuning. I'd just rather spend 1 hour doing this in Java rather than 1 week doing it in C. My point is that I would rather use a language/OS/GUI/etc. that makes people more efficient, because the ultimate cost is far lower than trying to make code that can run on a 286 in order to have hardware efficiency.
Don't you think there is some balance to be struck?
Don't you think that giving up some amount of hardware efficiency is worth huge gains in human productivity? Aren't some cpu cycles, ram, etc. worth spending on shortening development effort? Or are cpu cycles, ram, etc. only to be considered in trying to get the cheapest, oldest, most trailing edge hardware possible?
Hypothetical market survey. The latest cool wizbang program (insert your favorite tool, language, office productivity, or whatever here) will be available soon. If you don't mind it eating up 33% more cpu cycles, you can have it six months sooner. I'll bet that the market would take the sooner delivery time. Heck, in six months, hardware that is 33% faster will cost the same as today's hardware.
Please don't get me wrong. I am completely against bloatware. That is, stuff where coders are ignorant, lazy, stupid, unskilled, etc. Or maybe even just driven soley by marketing with no consideration given to technical issues. Again balance.
I'll see your senator, and I'll raise you two judges.
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++.
Last I checked, you could do that with C++ too, if you just write a string class with operator overloading.
Actually APL would seem to be a natural...
The take and drop symbols for the actual projectiles, the 'grade-up' (christmas tree-looking-thingy) would be a good player/shooter, and the transpose (looks like a null), quotequad (bloody phonebooth), ln/log (pentagram), and some of the others would make great little aliens... hmmm, time to go work on that...
--
"It's tough to be bilingual when you get hit in the head."
> 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'.
Yeah, you can actually write something like
int Count = 5;
string Text = "Count = " + Count;
without needeing an itoa() or anything. What's up with that???
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.
That's not the syntax, that's the JDK classes. There's nothing to stop you overriding them to make them simpler. Java is good in that a lot of the coding is already there for you in the JDK, but it isn't perfect, or the way you would have done it, so you extend it.
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.
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?
I did indeed.
And I was marked down for it.
-10, willing to learn; I'm sure they're all laughing about it now.
No, the fact of the matter is, my instructor is sold on getter/setter methods in any and all forms, regardless of how they may compromise a design, and any design other than that is suspect.
Surely you've heard similar Zealotry from the Extreme Programming people who think that no method should be longer than three lines of code?
Anyhow, if you haven't seen incompetence in action in the Java world, then congratulations. Maybe I should move to where you are. But it exists, and it is widespread. Maybe when it becomes more standardized and less buzzword-compliant, we'll see a reduction in the current level of cluelessness in the Java community.
But I'm not holding my breath.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
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
The Java AWT is designed around a model where you add gui components to containers using a layout manager which is responsible for looking at all the components, figuring out their needs, and positioning and sizing them to fit the window they are placed in.
By using these managers, a Java GUI program is meant to be able to adapt to different font and component sizes on different platforms. GUI programmers used to working with the much more homogeneous Windows platform sometimes are tempted to do a 'setLayout(null)' to get rid of the layout manager complexity, and just position the components within their containers directly. This breaks horribly, of course, the moment that Java code is run on a system with much bigger or smaller fonts, or whatever.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
There is a world outside web development.
A much, much bigger world.
---
I know; that's why I'd have to put each class in a separate package.
I generally only WANT class scope, and not package scope, and there's no clean way to do this in Java; it involves the inane process that I have listed above.
Here's actually one example where the C++ object system is superior, in my opinion. Scary, huh?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
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.
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).
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.