Slashdot Mirror
Java for EGCS
Drew writes "Anybody who thinks java is slow should check this out. The company soon to be formerly known as Cygnus released libgcj today. "libgcj" is the runtime library for gcj, the java front end to egcs. Find out more at sourceware.cygnus.com "
This is not a Just-In-Time compiler. The goal of the project is to produce a complete development tool set for compiling Java to native code just like you compile C to native code. I'm guessing Cygnus probably plans to market this to the embedded systems market as well as to the free software community.
Yeah, I was under the impression that gcc, cc and egcs just compiled C and C++. All the frontends do is just translate the original source language like objectiveC, Fortran, Pascal, Ada, Modula-*, Java etc... into optimized C then invokes the C compiler. Just like you have to have the devel and binary libraries for additional funtionality like GTK, libMesa, and ncurses, you have a Java library that provides the same thing.
This could mean that Linux is going to supercede Windows when it comes to Java support.
Codifex Maximus ~ In search of... a shorter sig.
This is true of any high-level language, really. This is something we learned well in the Lisp world: the barrier to entry for high-level languages like Lisp is so low, and for low-level languages like C is so high, that by the time a C programmer gets their program to even compile, they've already had to jump through so many hoops that they probably know a fair amount about what's going on.
It's easier for a bad programmer to get something done in a high-level language than it is for them to get something done in a low-level language.
Does that mean low-level languages are better, or that they encourage better programming? No, you just see fewer but better programs, because they take longer to write and exclude people who aren't really good at programming from even participating.
It's a shame when a language gets a reputation for being slow or bloated as a result of people having seen bad programs from bad programmers, whereas assemblers like C get a reputation for being efficient because you have to be a serious guru before you can get anything done at all.
And it's a shame that Java-the-language is going to have to live down the reputation of being slow merely because it's coupled in everyone's minds to Java-the-virtual-machine, which is the (arguably inherently) slow part.
All that said, I think it's easier for novices to write good (and portable) programs in Java than in C++ because Java leaves less land-mines scattered around. With C++, there are just so many parts of the language that you simply must not go near if you want the end result to be portable or efficient. Java is much more straightforward in this respect, by virtue of being significantly less complex.
If you were listening all those times, you would have heard me saying that I love programming in Java, I think it's a great language, and it's too bad that it's just not yet practical to write and deploy real end-user programs in it.
Having a Java front-end for a real native code compiler is a great thing, and an important first step. Once there's a corresponding complete Java runtime library (like the classpath.org folks are working on) then Java will be on equal footing with C.
But not until.
I'm looking forward to that day, because I really do think Java is a much better language than C or C++. My objections to it have always been that it's just not ready yet. I want to use it, but I can't.
What FUD? You're confusing "FUD" with "facts."
I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.
Because Sun knows that the best part about Java is that you can load classes into a running program. That cannot be done with a compiled version of Java.
While I think this is all good news for the java
community, and as long as careful consideration is
given to these system-dependant binaries, this
still isn't going to be fully acceptable for
all java users. One of the things this can't
do is the dynamic loading of classes, which is
very much necessary for doing anything along
the lines of plugins (Yes, I've programmed a
java plugin routine for a program that's sitting
on the back burner. The language has it all).
I doubt this will be a setback for very long;
I'm sure that someone will discover a way to
still dynamically load code with this compiler
with the help of native functions or such.
However, the VM will still have it's place (and
once Sun and others push the speed up in it,
then Java will provide the serious blow it needs
to deliever to a certain Redmond-based company).
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Yah, what you are saying is valid and true in a sense but I'd estimate I've written approximately 100 to 200 thousand lines of java (at least) in my time and the number of times I've actually encountered the ClassCastException you describe would have to be less than 5. I don't tend to create a Vector (say) and pass it around to every class under the sun and just hope they don't add a Dog object to my Vector of Windows. I'm not saying templates aren't cool/useful (I do a *lot* of c++ programming too and I like it a lot) it is just that this argument smacks of "because of x the result must be y" while ignoring that in practice the real outcomes is "despite x, very rarely y".
there are two kinds of people in this world - those who divide people into two groups and those who don't
Agreed, I certainly didn't mean to cast aspersions at your point in general - it is a good one. It is always the classic struggle isn't it? Compile time safety vs. flexibility with dynamic typing. Personally I love the flexibility that java/smalltalke/etc. give you but in practice deferring that many potential errors to runtime can certainly cause you a lot of grief. A (possibly) interesting observation about c++'s templates - they actually provide a new type of inheritance in a way, the allow you to plug in any class that has the acceptable methods (the ones you call in the template) without requiring that those classes actually inherit from a common base class. I suppose my final word on the whole deal is that with c++ (with possibly much pain) you can create OO, shippable, speedy software today - java definitely gives you the OO but the speed is sadly just unacceptable for a large percentage of programming projects.
there are two kinds of people in this world - those who divide people into two groups and those who don't
Is that it takes three ideas (a pure OOP language, a portable virtual machine & byte code specification, and a nice GUI library) with lots of promise, then it locks those ideas irrevocably together. If developers could compile to native code, link to existing object files, etc. Java would have a lot broader usefulness. Good job, Cygnus.
Interesting. I've never seen a C programmer confused over operator overloading. Would you argue that C should replace a + b with addi(a,b), addl(a,b), and addd(a,b)?
That may seem strawman, but it's the point. When dealing with mathematical structures on which + is defined (complex, hypercomplex, vectors, etc.) it's clearer to use the mathematical symbol.
it may seem like an inocent easy shortcut when you are the only person working on a small program
It is. It expresses the problem in terms I can understand, and makes it simpler for me to program it.
but what about when you are one of 8 ppl working on a large project?
I don't care. I have plans to avoid those things forever. Many people writing in Java are writing one person programs, and they should be catered to as much as the large projects. Anyway, in a large project you need naming standards and others, so just add no overloading on to the list.
operator overloading is just to ambiguous to rely on.
1. It's much clearer to say a + b (where a & b are complex numbers) than it is to say a.add(b).
2. As someone else pointed out, virtual functions and overloading can make it pretty hard to figure out what a function's from anyway. Translate a + b to a.operator+(b) and look it up like you normally would.
Yes.
(RTFM)
Those who think Open Source is now a misnomer
and want to call it "viewable source" should
look at the name SourceWare.
Incidentally, Cygnus is a good example of how
to make money from free software.
It's not quite there (no Java 1.1 support) but this is a huge step in the right direction. Once again I feel vindicated in forgetting all the C++ I ever learned.
I just hope that this doesn't lead to java forking. It's already started (CommAPI for instance) and architecture-dependent java variants could really screw up the big opportunity for architecture-independent programming.
Kudos to Cygnus!
If I remember correctly, one of Bjarne Stroustrop's chief criticisms of Java was its initial inability to support generic programming (as well as its apparent portability problems).
I haven't kept up with "Java2". Can anyone tell me if Java has improved in this regard?
This is a clear advantage of C++ that Java needs to address.
The practice of explicitly making a method "virtual" isn't there just to make C++ hard. Its part of the theory of its design. You only incur the overhead of a vtable if you want one. Java forces one on you whether you want it or not.
When you provide some credentials, I'll start accepting crap like "I can't possibly belive you
have any programming experience" without some good proof.
I object to the streams because they exist, not because they are forced on you. They provide some benefits, but they don't do things like set errno, they give you less information on file opening failures than their libc equivalents. The types of errors that you can catch are just fewer and less informative. That's my gripe with them. They're less powerfull. They do have some nice qualities, like easy overloading.
Speaking of which, overloading is a nice feature of C++.
My point, though, was that there are reasons to not like C++, and there are no great reasons that C++ is better than C. It has some niceties (the STL, operator overloading, declaring variables anywhere in a program, etc.), but none of them are necessities by any means.
So simple preference is a valid reason to choose a language when there are no clear significant advantages to either. obj1 = obj2 + obj3 is nicer than add(obj1, obj2, obj3), but not by all that much.
Btw, the word logical was probably a bad choice of words. I was trying to refer to the opposite of OO programming, which I guess might be better termed action oriented? What is a good way to describe a += b instead of a->add(b); (using a silly and never-going-to-be-used example).
Did someone just steel your girlfriend, btw? You sound awfully hot tempered for someone responding to a simple post on language choices that said that C++ is not the one true way.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Frankly, C++ has its drawbacks too, like being more complex and further removed from the computer. C++ has a different feel to it. Bloated and Anal come to mind, but that's probably just partially from the way that it was tought to me. Possibly the other part is that I don't really trust any language that has those awful stream object. cin & cout are pathetic compared to their equivalents of printf and scanf.
And those try{} catch{} blocks just feel way too much like some sort of basic. I want to program, not play a game of baseball.
Part of it is also that most of the C++ OO programming that I've seen has made anything that it could find an object, which is the wrong way to go about things. I like OO programming in C better than in C++, partly, I think, because people are more likely to write the code that does the job most elegantly and not the code that does the job most abstractly/OOedly.
Of course, that has nothing to do with the language, but I have tended to dislike the way that people attack problems to attack them with an OO frame of mind rather than a logical frame of mind. This is just a generalization, btw, and I haven't seen all that much C++ code.
But the major thing about C rather than C++ is that C just doesn't have the "designed by theory" feel to it. Everything in C feels like it's been designed from experience and logic. That's why, I think, that it's been called portable assembly. Assembly tends to be elegant, efficient, and logical. Especially some of the RISC assembly languages.
C has that sort of feel to it. It has a minimalist appeal. C is quite convenient, as long as you're comfortable with computers, and while it has its faults, it doesn't really get in your way to do anything.
C++, by contrast, feels like it was designed with OO theory in mind. It has all sorts of contructs that just don't feel right on a computer. Like the public/protected/private declarations. That just feels like something that should be in a classroom, not a real programming language. Of course, that's a feeling, but it has its validity. public/protected/private isn't part of how a problem gets solved, it isn't part of the code, and it isn't something that helps the compiler figure out what you mean.
On the other hand, classes do offer some convenience for having OO functions inherently know what data they are operating on. But it is just a convenience. It's not much of a hardship to do object->data instead of data.
Anyhow, I haven't seen any really good reasons for prefering one language over the other. I get more of a feeling of leaner, faster code from C, but that might be erroneous, it's possible that if you don't really use certain features of C++, they're not put in there because they theoretically belong in there. I haven't really looked through the various C++ compilers.
But please don't disparage C so much. There's nothing that you can do in C++ that you can't do in C (that isn't syntactical in nature), and setting up your own object model generally means a few extra pointers that would be handled for you in C++. For those who like the feel of C better, there aren't really any compelling reasons to switch to C++.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I responded to the logical part in another post, but let me address that here, too. I didn't mean that OO programing wasn't logical, I was just trying to refer to the other paradigm of programing that isn't OO. Maybe it's action oriented programming? I used the silly example of a += b; rather than a->add(b); That was what I meant. I respect C++, btw, I didn't mean to imply otherwise. I just didn't phrase it well.
.c file. C++ seems like a good language, but it's not clearly better than C++.
:-)
> If E and Gnome were written in intellegent C++,
> they might actually work.
Just like Netscape?
Oh, and in what sense doesn't E work? I can't remember it crashing on me since the 13.3 days, and I use it exclusively. Gnome is just a massive project that's growing at an incredible rate. To expect a project of gnome's magnitude to go from nothing to perfect in a year by volunteer developers is insane.
I'm not saying that C++ might not be more appropriate for them, but they're doing quite well as they are. So is Linux. And the gimp.
I never meant to imply that C++ isn't good, just that it isn't simply all-around better. And saying that you can compile C with a C++ compiler isn't an argument for using C++, it's not an argument for much of anything than it's fine to invoke g++ instead of gcc on a
Lacking a real clear general superiority, there's no reason to condemn those who like C over C++, or to regard them as inferior. Frankly, while I like C, my favorite language is perl. C feels closer to the CPU, and in that way I like it better, but there's nothing like Perl for elegance of design.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Thanks for the kind and informative reply.
You're right that I'm a student, and haven't really been a part of large corporate projects. My experience is mostly on the small things that I've written, and on the larger projects that I've looked into by other people (part of why I love open source).
As far as streaming goes, the idea itself probably isn't a bad one, but from your description of it (and my meager experience of it) it's more a syntactical convenience, like perl's default scalar, than a feature that's hard to do in C.
As far as try/catch blocks, my problem isn't really with them, though I'm a bit dubious about your claim that they're much better than error codes, is the way that they're handled. With the standard stream IO objects, especially the file stream objects, they didn't have nearly as many exceptions that can be thrown as they should have, their errors were largely generic. "couldn't open file" type errors, not "too many file descriptors open" type errors. This is more a matter of implementation, though.
But try/catch blocks aren't particularly different than error codes, you flag and error and someone down the road picks up on it. With error codes, you often have the benefit of printf("%s\n", strerror(errno));, which saves a lot of debugging work.
As far as public/private, I've never been able to gather much of a benefit from that feature of the language that isn't something that should be built in anyhow. wouldn't:
#define private public
just get wrid of the language barriers to using private members?
In C, you can stick the private functions in a header file that you don't even distribute, which is more private than giving them out.
But information hiding sounds more like a matter of programmer discipline. You should, having inelligent and responsible programmers, be able to make a header file with
/* These are the general functions, use them */
...
/* These are the private functions which may change at any time without warning, don't use them. */
...
And achieve the same effect. Sure, there's nothing forcing someone to pay attention, but what's forcing someone not to do a #define trick, or just to rewrite the header file (using a local copy), etc.
Anyhow, my point was that not using C++ for everything is not necessarily a sign of incompetance. C++ doesn't offer any tremendous, clear advantages that make C the choice of idiots only. That was my only point. Every supposed benefit of C++ that has been pointed out, I've seen to be a benefit, but not as a major benefit. That is, not as the sort of benefit that you'd be an idiot to ignore. I'm not trying to start a holy war, just defend C as a viable language choice for many applications.
Btw, I wasn't arguing about OO design. That's often the way to go. But you can do OO design reasonably well in C.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I wasn't trying to disparrage C++. It's a good language, and has benefits over straight C. My argument was just that if someone likes C better, they're not an idiot for using it over C++, even if C++ had some benefits. It's quite possible that the benefits aren't significant enough to outweigh personal preference or personal circumstance. Essentially that there's no one true language. I never meant to disparrage C++ as something inferior to C.
Oh, and I'm not clueless. I didn't learn too much C++, we don't have the best CS teachers here, but I did learn some C++, enough to have some flavor of the language. I know C, I know perl while not being a master of it, I've done a little java programming, a touch of javascript, x86 and MIPS assembly, bash shell scripting (if that can really be counted as a language), and I'm probably forgetting something that I've tried. I plan to learn more languages, I'm interested in lisp, among others.
Anyhow, I don't mean to disparrage any language, as I said above. I just wanted to point out that there aren't any real grounds for saying that real programmers don't program in C, only throwbacks do. I think that we're essentially agreed.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
This means that Java is now a real language, just like Objective-C, Pascal, Fortran, or C. The FUD official stops now.
And I bet this means we'll be getting GTK+ and GNOME and ORBit bindings for Java/gjc soon... yes...
--jon. Postel is dead. May we all mourn his, and our, loss.
I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.
With all due respect, I agree with your second reason but have doubts concerning your first. If If I'm not mistaken, their official line on why they maintained that tight control was twofold: first, they wanted to protect Java from sabotage,as Microsoft tried to pull, and second, that their initial license agreements with vendors made loosening their control legally tricky.
Could they have prevented Microsoft from discrediting Java's "Write once, run anywhere" claims if their control had been any looser? Possibly. Was it feasible for them to give up some ground any faster than they did, or to simply have released the product under a more open license to begin with? Maybe they could have done that, too.
In general, however, I feel that Sun deserves more credit than they've received so far. Vendors such as IBM, IBM/Lotus, Oracle, Apple - in short, pretty much everyone but Microsoft and Compaq/Digital have had enormous input on the class specifications, for example. Some important parts even originated at one of those other companies. And Sun has released preliminary specs for public review and criticism; they've been extremely receptive to outside influence, and I guess the fact that they've been reserving the final word for themselves just doesn't bother me as much as it seems to bother you.
It goes without saying that they're simply acting out of their best business interests; those interests seem quite compatible at the moment with almost everyone but Microsoft. Most of all, they are very compatible with the self-interests of developers. The Java community license is possibly the best compromise between the free and proprietary worlds that I've seen so far.
I realize that many people feel there can be no compromise: the Qt flame wars demonstrated that quite clearly. But for developers who want to make a living developing, without doing so as consultants, scrutinizing the middle ground is absolutely essential.
Of interface.
:)
What else do you need?
(C++, the PL/I of the 90s
-- Alastair
Getting [rid] of pointers renders Java fairly useless as a systems programming language.
ROTFL.
The operating systems for Burroughs large systems (B6700, etc), now Unisys A-series, are written in a variant of ALGOL utterly devoid of pointers.
(It does, however, have a predefined array called MEMORY. If you really need that level of access for your systems programming, add that to your JVM.)
-- Alastair
I think Bjarne's confused on this issue, if you're quoting him correctly.
Any language that supports inheritance supports generic programming, if you do it right. You don't need templates for it, either.
I started using C++ back in cfront 1.1 days, before templates or multiple inheritance were part of the language. We just created a bunch of basic classes to inherit from.
-- Alastair
A language should give the programmer as much power and flexibility as possible, and a programmer should know when not to use it.
In theory I agree, and that's fine for personal projects. In practise, however, I've seen (and occasionally had to maintain) far too much crappy C++ code (and other languages, certainly) written by programmers who weren't enough above average (and remember, 50% of programmers are below average) to use such features appropriately. On anything that needs to be reused, or maintained, its just not worth it. (The ultimate example of this is perhaps APL -- powerful, expressive language, wonderful for writing quick personal and powerful apps (I've even seen an email system written in APL), no fun to maintain.)
Having a programming language enforce what it considers good programming practice results in disasters like Ada, Pascal and Java.
Those "disasters" have proven spectacularly successful in the domain of large project development (well, Pascal less so, but it was designed as a teaching language) precisely because of that enforcement.
-- Alastair
I agree that the lack of generic programming in Java is one of its biggest weaknesses.
Java2 has a new API that tries to rectify this though. The Collections Framework (or whatever the nom du jour is) provides some generic container classes, complete with algorithms ala STL.
The problem is it is Java still doesn't have templates. All the generic stuff is implemented with standard OO inheritance and polymorphism. That means that the nice compile time checking of C++ doesn't happen in Java; you have to make sure every Object you add to a List is really a Comparible Object or else Sort will choke at runtime.
Plus you can't have lists of anything except Objects. I know, I know, everything is an Object, but that means you can add a Thread to a list of Windows, for example. Unless you create a specialized class derived from List that only works with Windows.
In short, yes it has generic progamming of a sort. But it is still a lot less powerful than templates as implemented by C++.
You are right, the particular situation I described doesn't happen in real life that often.
My real point is that C++ with templates binds everything at compile-time. If a type won't work with a particular algorithm, or you try to put the wrong type of object into a container, the program won't compile.
Java binds everything at compile time, and throws exceptions if something goes wrong. It will compile, and it might even run 99% of the time.
From a software engineering perspective, the first is much better because it catches that entire class of errors 100% of the time. They can't be caught all the time in the second situation without exhaustive testing.
Small projects that use a Vector here and a List there aren't going to have problems. But large projects that use generic programming exstensively are much better off with the static typing.
The whole argument is really the same as the argument between statically typed languages (C++, Java, Pascal, etc.) and untyped or dynamically typed languages (Lisp, Smalltalk, TCL, etc.), except on a higher level.
Agreed. C is easier to port than C++ and C compilers are more common on older systems that some companies can't afford to phase out.
Also (with the possible exception of BeOS) many operating systems and their APIs have a decided "C-bias".
Save the whales. Feed the hungry. Free the mallocs.
For syntax highlighting and other niceties, I'm pretty much hooked on NEdit ( http://fnpspa.fnal.gov/nirvana/nedit.html ). I haven't found an IDE I'm crazy about yet in either Windos or Linux. Anyone have any suggestions?
Save the whales. Feed the hungry. Free the mallocs.