Why Linux Lovers Jilt Java 766
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*
Re:those are your reasons? (Score:3)
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.
Java is dead while Netscape Java is dead (Score:2)
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.
Re:A Java-coding Linux supporter (Score:2)
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.
Re:Why I dislike Java (Score:2)
On the good side I really like the design of Swing. Sure it's slow and buggy, but it's nicely designed and powerful.
Re:Hacker Mentality (Score:2)
I do, though not by choice
Re:Simply annoying... (Score:2)
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
Re:I can't stand Java, but maybe that's just me... (Score:2)
#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?
650 comments and counting! (Score:2)
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 [slashdot.org].
Re:those are your reasons? (Score:5)
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.
Re:those are your reasons? (Score:3)
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?
java? (Score:2)
Small & Portable (Score:2)
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.
Python replaced Java (Score:2)
Re:Why I dislike Java (Score:2)
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.
Re:Hacker Mentality (Score:2)
Re:C++ attracts the wrong kind of programmer (Score:2)
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.
Re:Why I dislike Java (Score:2)
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.
Re:Why I dislike Java (Score:2)
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.
Re:A Java-coding Linux supporter (Score:2)
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.
Re:Taco, Chill. (Score:2)
Or even P. Two-and-twenty points to whomever gets that reference first:-)
Java VM is excellent (Score:2)
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.
Re:Don't confuse the language with the IDE (Score:2)
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.
Re:Why I love Java and why I hate java (Score:2)
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 [aceshardware.com].
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.
Re:Perl and VBScript don't scale well..... (Score:2)
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.
Re:Hacker Mentality (Score:2)
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.
Ada faster than assembly? (Score:2)
"Ada Whips Assembly" [port.ac.uk]
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.
Java Threads Get Their Collective Asses Kicked (Score:2)
Comparing Java to Mozart [www.sics.se], 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
Re:C++ attracts the wrong kind of programmer (Score:2)
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.
ML Server Pages (Score:2)
ML server pages project [dina.kvl.dk]
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.
Re:Why I dislike Java (Score:2)
- 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.
Re:those are your reasons? (Score:2)
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.Re:java? (Score:2)
For example, several changes are required to port 1.0 programs to 1.2. [gtk.org] If you've checked out the 1.3 version you'll find that it's incompatible with just about everything. (Although I think most of that is just to keep clueless people from complaining when app foo doesn't compile.)
The GTK developers try to maintain a minimal number of changes required for existing programs, but they're not afraid to make backwardsly incompatible changes if they feel it will significantly improve the library.
Imagine that in a comercial program! Hardly anyone in the Wintel camp is willing to do that. In practice, I can't see why (other than because of laziness) making backwardsly incompatible changes should be difficult in a one-vendor product such as gtk as long as they provide an emulation library for backwards compatiblity. Documenting the programming interface changes is also essential.
The problem with a multi-vendor standard such as Java is that any changes to the standard have to be implemented not just once but in every provider. You have the social issue of ensuring that all providers do it and the technical issue of ensuring that they do it right. (Java is somewhat less disadvantaged than many "standards" on this point.) This is enough to discourage many worthy improvements.
Re:Why I love Java and why I hate java (Score:2)
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
Re:Why I dislike Java (Score:2)
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.
Re:I can't stand Java, but maybe that's just me... (Score:2)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:He who likes Java does not know other languages (Score:2)
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.
Re:Different needs (Score:2)
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.
Re:Taco, Chill. (Score:2)
Re:Java Threads Get Their Collective Asses Kicked (Score:2)
Then you haven't seen Mozart [mozart-oz.org]
Java code 168 lines
Mozart code 30 lines
Re:Fighting the Logo Removal (Score:3)
"Fair use" is a copyright conmcept, not a trademark concept.
As usual, Cmdr Taco displays his "amazing grasp" of intellectual property law.
Some syntax (Score:2)
packages
Re:MS VM (Score:2)
What I hate about Java (Score:2)
;)
Re:Simply annoying... (Score:2)
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.
Re:those are your reasons? (Score:2)
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...
Re:perl for the swine (Score:2)
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!
Re:Simply annoying... (Score:2)
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
--
Re:Server side is its strength (Score:2)
Re:My thoughts on why java is not good (Score:2)
TWW
Re:Why would anyone want portable code on servers? (Score:2)
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.
GCJ: GNU Compiler for Java (Score:2)
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 [redhat.com] 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 ...
Why would anyone want portable code on servers??? (Score:3)
Damn straight I want to address the actual devices I plonked down all that money for.
Re:C++ attracts the wrong kind of programmer (Score:2)
Too many people associate Java with the Web (Score:2)
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.
Re:I can't stand Java, but maybe that's just me... (Score:2)
Don't confuse the language with the IDE (Score:4)
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 [squeak.org] 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.
Re:Java bad (Score:4)
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.
Re:Why I love Java and why I hate java (Score:2)
Re:I can't stand Java, but maybe that's just me... (Score:5)
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.
He who hates Java.... (Score:2)
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.)
You go Taco! (Score:2)
(JAPH, Pim)
Re:Taco, Chill. (Score:2)
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 is Good. Python Might be Better. (Score:2)
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
Re:Simply annoying... (Score:2)
Re:I can't stand Java, but maybe that's just me... (Score:2)
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); }
Re:He who likes Java does not know other languages (Score:4)
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.
those are your reasons? (Score:4)
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...
Re:Was the logo really removed? (Score:2)
Re:I can't stand Java, but maybe that's just me... (Score:2)
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.
Re:Taco, Chill. (Score:3)
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 [apple.com]?
Java isn't going anywhere? (Score:4)
Java is used by almost every major player in every major industry in the U.S. and beyond [sun.com]. Personal Java runs on the myriad embedded systems with their own JVM [ibutton.com] and even American Express credit cards [sun.com]. Java servlets and JSP run myriad websites from mail.com [mail.com] to First Union [firstunion.com]. Enterprise Java Beans [sun.com] 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 [sun.com] 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
Java is well accepted by OS (Score:5)
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 [gjt.org], to the Java [apache.org], Jakarta [apache.org], and XML [apache.org] Apache projects. There is even an Open Source application server called Enhyra [enhydra.org] 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 [sun.com] 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.
Java misconceptions (Score:5)
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.
Re:Was the logo really removed? (Score:4)
--
C++ attracts the wrong kind of programmer (Score:5)
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.
Thoughts on Java on Linux (Score:5)
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
Fighting the Logo Removal (Score:4)
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?
Taco, Chill. (Score:5)
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.
Re:those are your reasons? (Score:4)
Before you say "Use JNI, it's the VM not java", let me explain to you why you have your head up your ass.
Yes, the VM causes a larger memory overhead and bloating. That's the nature of a VM, and I don't fault java for it because you can compile natively and not use the VM. However, the bloat I am referring to comes from the nature of the java language.
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.
If you want fast small programs, use assembler. It'll take you a week to write Hello World but it'll only take a single clock cycles to run. C is slower and bigger than assembler, but faster to code in and more portable. C++ is even more scalable but a little slower and bigger memory-wise. Java is bigger and slower than C++ because it's higher-level and more OO. Lisp and Scheme are even higher.
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. True OO design makes code more modular and more scalable and a hell of a lot easier to program big projects. But it also makes it slower and take up more memory. That's a truth of OO programming that you learn to live with.
You can write a big project in java in fractions of the time it would take you in C, much less assembler, but I guarantee you that when it did get finished in assembler it would blow your java code out of the water in terms of speed. But your code would blow the assembler out of the water in terms of maintainability.
The world is full or tradeoffs and that's one of 'em.
1) Language is more High Level -> Language is slower and takes up more memory
2) Language is closer to machine code -> You have more power over the machine -> Code can be faster
3) Code is abstracted -> Less control over actual generated machine code -> Code is slower
Justin Dubs
Re:I can't stand Java, but maybe that's just me... (Score:5)
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.
Re:Java Exceptions (Score:5)
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!)
Server side is its strength (Score:5)
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.
Who jilted whom? (Score:5)
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.
Support for Java (Score:3)
Re:Simply annoying... (Score:3)
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)
A Java-coding Linux supporter (Score:4)
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 [utexas.edu] 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.
Re:He who likes Java does not know other languages (Score:3)
You can call any method in any object in java through the reflecion api. The java.lang.reflect package includes all the info you could want. It is possible (and relatively simple) to write a java program that reads as a string the name of a class from the command line, loads that class on the fly, outputs the names of all its methods and paramaters, instantiates it, calls whatever methods you want etc. It is one of the languages most powerful features. I have java programs that can load classes and use them just by having the classes name in a propertied file. No need for dlls or anything like that, just knowing the name is enough.
Of course you have being modded up nicely for your misinformed rant so well done. There is a Method class that can be used for a callback, quite easily it must be said. You might want to take the time to look it up. And what of javas other powers, Its multithreading is some of the easiest you can ever use, It has a uniform database access API that you can actually use accross multiple databases without changing any code. Its network code is clean, easy to use and very solid. And of course the executable is the source code. Why do people give out about java not being open source when any java class file is inherently reverse engineerable. Once you have the class, you have the code. Some people obfuscate alright but you generally have pretty usable code just from decompiling.
Not everyone... (Score:5)
Embedded Java?? (Score:3)
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?
--
Java (Score:3)
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
Re:java? (Score:3)
Its a catch-22, if a product is wide spread and popular then you have to maintain compatibility or risk upseting the user base. Thats a big part of the reason why the x86 architecture is still in use. There are things chip manufacturers can do to greatly improve chip performance but they break the ever important backwards compatibility. Joe User dosen't care if a chip is a RISC or a CISC chip so long as he can run Windows and type his spreadsheet. But Joe User is comforted by the fact that if he wants to run Wolfenstien on his system that all the hardware changes over the years haven't made that impossible.
The same goes for standardization. There is a Java standard set by Sun, and every browser of note has a Java VM in it. Sun has to be very careful about what they do to Java because while I'm sure there is stuff they could do to make Java better, have more functionality etc, they run the risk of breaking both the VM and angering programmers who have made an investment in learning Java as it exists today.
Any tool or library goes through an early stage where it is very dynamic and flowing, because the number of people affected is minimal. As it gains wider acceptance the development cycle slows down and eventually the tool stagnates. Somewhere along the line someone develops a new tool that surpases the old tool in one way or another. Around the time that the new tools functionality begins to exceed that of the old tools is when the new tool will stagnate. Why? Because at this point more and more people will start to use it because it is better. But the more people that use it the more any changes have to be analyzed for their impact.
Take a look at Motif vs GTK. As I understand it both are windowing toolkits. For the longest time Motif was "it" when it came to graphical toolkits. But it stagnated, part of the stagnation was that it didn't go open source. Along comes gtk, and early on, no one uses it because the early versions stink. But that means that stuff that dosen't work well can be purged out and replaced. Then it gets big, people start switching to it from Motif, more and more people start using it. So now, every change that the developers make to the functionality of the program they have to look and see if it will help more people then it will hurt. As a result it will begin to stagnate, and something else will come down the road a little later.
Why I dislike Java (Score:5)
- 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...
Re:Simply annoying... (Score:4)
1) on the server side. Most input and output will be going through network connections, not to stdout/err.
2) on the client side. Most input and output will be going into cute graphical widgets, not to the console.
Basically, the only thing you ever use System.out for is to write debug stuff. Unless you're writing a command line app in Java (someone email me if you've EVER done this, 'kay?). So it's fine that it's buried under some heirarchy called "System." It's kind of like a programmer's backdoor (in a good way!) to get things done efficiently. If it makes you feel better, think of System.out as a Singleton and look up the Singleton pattern in "Design Patterns." Lots of applications have things that you only need one of, all around the code. That doesn't have to ruin the object heirarchy, and I don't think it does here.
Why I love Java and why I hate java (Score:3)
Why I Hate Java
Re:Simply annoying... (Score:4)
...
OutputStream whiner = System.out;
whiner.println("Learn Java");
That's the biggest pile of crap I've ever heard (Score:3)
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.
What's good about Java (Score:4)
- 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.
Re:C++ attracts the wrong kind of programmer (Score:5)
Actually some of us prefer C++ over Java because C++ better reflects what I intend to do. Code crunching BigNums is very frustrating to write without operator overloading. Some real live code at my job reads: "s = (k - x*r) % q;" where s, k, x, r and q are all BigNums. I can easily compare this to the product's specification of this equation. Without operator overloading I'm stuck with something like "s = mod(subtract(k, multiply(x, r)), q);" Ick.
(Many people complain that operator overloading is too dangerous since operator*(BigNum lhs, BugNum rhs) might not mean what you think it means. Fair enough. Of course, there is not certainty that multiply(BigNum lhs, BugNum rhs) does what you think it means either.)
Ripping on C++ for lack of class libraries is simply foolish. The core features of the STL are pervasive now. Modern compilers all have solid support for the fringier features. Having worked with a large, standard library of typesafe containers and algorithms for arbitrary types makes coding Java frustrating.
Java is a great language. C++ is very dangerous in the hands of beginners (It's a loaded machine gun helpfully pointed at your feet with the safety off). Java keeps it simple. But Java is less expressive. Larger, more dangerous languages give you more power to say what you mean, or to blow your foot off. Don't project Java's faults onto C++. If you want to find fault with C++, complain that it's too powerful (and thus dangerous) for your average programmer.
Re:Hacker Mentality (Score:3)
> 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???
IDE?!? (Score:3)
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.