Slashdot Mirror
10 Reasons We Need Java 3
An anonymous reader writes "This article on O'Reilly Network (written by one of the most active Java book writers ever, Elliotte Rusty Harold) has some interesting points about the need for a new 'cleaned up' Java version, made to incorporate the advances in the last 7 years of its life and without the requirement to keep compatibility with old versions."
But the beauty of java is that we don't have to directly access/manage memory. I for one would be scared to see what would happen if you gave a java programmer access to pointers when they never programmed in c/c++ before. Java does have pointers though because everythign is passed by referennce but it's all done for you. Pretty sweet actually...
Operator overloading is an excellent way to code in c++ but I have no problems in saying Array.copy(array1, array2) myself.
If you ask me the major problem with java is the speed issue. It will never be as fast as c/c++. But thats life...
"I believe in everything in moderation. Including moderation." -Dean DeLeo, Stone Temple Pilots
I always wondered why Sun didn't make compilers for the most common OS'es. So we'd have something like this:
.. or .. .. etc.
Java Source -> Bytecode -> Windows
Java Source -> Bytecode -> Solaris
Not only the source would be portable, but also the bytecode, as always. No changes, just a damn bytecode compiler. Of course, the java interpreter should still be included if you for some reason didn't want to run optimized code for your CPU or had a CPU that wasn't supported with specialized native code compilers.
The only thing that would mess things up would of course be if someone just distributed the native compiled code, but wouldn't that be just a brainless thing to do since if you included the bytecode everyone would be able to use it?
???
Beware: In C++, your friends can see your privates!
If you ask me the major problem with java is the speed issue. It will never be as fast as c/c++. But thats life...
Not true! Sun has recently published some benchmarks which clearly show Java pulling away from C++ in a number of key B2B, B2C and ERP related benchmarks, including the ugly object-creation heavy SKAN-K test, the datamining 4-EYES benchmark, and the industry standard scientific calculation HOmark suite.
It's a good day to be a Java programmer!!
So I say the Smalltalk way is easier to use, there is only one integer type when doing computation, yet I can do I/O with integers in all formats I want (8-, 16-, 32-, or 64-bit, signed or unsigned, big-endian or little-endian). If high performance is required, maybe C-like types can be added too, used only in speed-critical things.
java allowed you to increase productivity, substantially?
according to this whitepaper, when developers are given their preferance of language to use to implement a solution, they're most productive. ie, someone who knows c++ and enjoys working in c++ will be just as productive as someone who knows java and enjoys working in java.
i'd be extremely interested to see some concrete independant studies showing otherwise.
making improvements to Java, which make it incompatable with older JVM's, and simplifying and improving the GUI bit, exactly what MS did and got slated for?
> This would make Java's type system much
> cleaner. We'd no longer need to use type-
> wrapper classes
Actually Smalltalk solved this problem
by always executing the machine code
primitive for, for example, integer add.
If this failed an assertion, it faulted out
to the more general class code.
Substantially the same thing could be done for
Java, so that one could have full generality
without a performance penalty.
davecb@spamcop.net
... we need to fix the ones that we have. I have used five diffrent languages already, and I am only a student of programming.
Making a varsion of a language that is incompatable with all previous ones would be ludicrious, especially on an intreprited language such as java. I can see joe blow sitting in front of his computer trying to figure out why his java solitare game won't run, even though he has just downloaded the latest and greatest java3 engine. All the hours that the planet has collectively put into to Java 1.x.x would then turn into a grand waste of time.
I am not saying that there is nothing wrong with Java though, the backend needs some work. But that can (and should IMHO) be transparent to us programmers. We need new, faster VM's to run the code on the host machines. The windowing toolkits need an overhaul, and we should do away with AWT almost completely. But all of this can be done in such a way that the old stuff still runs. (They have smart people at sun, they can find a way....)
Adding pointers and memory management would be nice, but what would we do for cross-platform compatability then? I can just see the mess we'll get when our pointers refuse to work on the palmos/ sun/ pocketpc/ OS11/ whatever version of java...
-unused_user_name
(The thing wouldnt let me log in BTW)
> What you really need is generics (as in C++ templates).
>Java collections are vile, since they suffer from type loss
> even when used with "real" objects. I'm surprised that didn't
>come into this top ten; it's a major language deficiency.
I couldn't agree more. In fact, there is a proposal (from Sun in 2001 based on Generic Java) to do just this. I really hope it will find its way into Java soon, since Generic Java solves exactly the problem you are rightly complaining about.
Java does not need just to incorporate the advances in the last 7 years, but rather the advances (e.g. in type systems) of the last 20 years.
Generics will will be included in Tiger (1.5)
They don't break either source or binary compatibility (at least not the way Sun is going to do them).
You can even download the beta compiler and give it a whirl if you're eager. Java Generics
> > One word - ew!
:)
:))
> Why ew? Because of your limited programming
> experience with languages where this was
> eschewed?
Nope, just flamebait
> Explain? How can you write a Non-OO program in
> a Pure-OO language?
I'm not sure what your question really is here, and you seem to have answered it yourself. You can take your problem, use structured design / functional decomposition to come up with a solution circa 1980, then implement it in Java much as you would do in C. A single class, with many methods and members (hell, make 'em static while you're at it)... no polymorphism, no inheritence, no data hiding, no application-level abstraction.
You can go one step back up the ladder and pretend to be using Pascal/Modula2/Ada, using classes as abstract data types and providing simple access functions. Still not what most people would call an "object-oriented" program.
Remember, design *is* programming. A program which deliberately avoids the object-oriented features of its implementation language cannot be called OO just because it "contains objects". A good language is one which allows the programmer to express him/herself in the most suitable way for the problem being solved. If a developer has to find "ways around" a particular feature of the language, then that language is flawed.
Me? If I was asked "what is the most harmful programming construct", I would choose type casts every time - yes, even over gotos and pointers.
As you've probably guessed, I like C++. I tried Java and didn't like it. Therefore, I am just ranting bitterly and should be ignored at all costs.
These sigs are more interesting tha
Multiple inheritance has major problems (if both superclasses have the same function, which one do you use?). A much better answer is often to use "Composition", where the class you are writing contains both of the superclasses that you want to extend, and have your class manually delegate to which ever one of the classes you want to perform the operation. See the "Inheritance versus Composition" section of "Design Pattern" for more details.
Composition is, IMO, a cludge. One of the promises of OO is code reuse; I shouldn't have to do inordinant ammounts of work to get at functionality I have already written. As for the diamond problem you mentioned, the solution is simple; if more than one parent class implements a function, force the child class to implement it's one, even if all it does is call ParentName.func();
Thomas Galvin
Coming in J2SE 1.5, by all accounts. A "preview" compiler implementation is available from developer.java.sun.com.
Well, technically people are upgrading to VB .NET, which is wholly incompatible with VB 6.0. They are so different, and VB.NET is so unready as a passable alternative for application development, that I'm sure there's room in this space for somebody e.g. Borland to make a killing selling non-webservice, non-CLR based "Visual" development environments.
A few things I've "recompiled" into VB.NET (it really is recompilation, nothing looks the same as VB.NET is a real object oriented language, or as close as it comes from redmond's "think/market-tank") look nothing like the originals. Tight loops I spent hours optimizing run five times slower. Stuff I didn't optimize is even slower than before. But I can kind of sign off on this -- it's so nice to finally have real constructors, etc.
Hey freaks: now you're ju
Java isn't what is important, it is the write (bytecode) once, run (bytecode) anywhere that is important. Whether that bytecode is generated from Java, Python, Scheme, Ruby, or Joes New Language For His CS210 course, doesn't really matter.
.NET runtime. Any language that will work well on a stack-based architecture will compile very nicely to the JVM.
.NET.
I'm suprised that this fact just doesn't come up often when debating Java vs. the
Even though I really know nothing about C#, I suppose even it could be ported to the JVM, because C# is touted as a Java clone. Microsoft markets a "migration path" from Java to C#; does Sun do something similar for C# to Java? I have seen that there are Visual Basic to Java options.
Another interesting question is whether the GCJ implementation can handle non-Java bytecode. Imagine being able to write Java, Scheme, or Python source, distribute it as bytecode, and, if the end-user wants native binaries, they just run it through GCJ. JVM + GCJ has a lot of potential to be very formidable against
Healthcare article at Kuro5hin
String foo = "Hello ";
// fobar now equals "Hello World"
String bar = "World.";
String foobar = foo + bar;
Then why shouldn't I be able to write a Matrix class that has addition, multiplication, and equals overloaded to be matrix addition and matrix multiplication? Which of these two examples looks like clearer code to you?
Matrix x = new Matrix(a.matrixMultiply(b));
or
Matrix x = a * b;
But let's not let this turn into a Java bashing forum. Even with it's limitations and frustrations I still love the fact that my favorite programming editor (Jext, written in Java) works exactly the same in Windows 2000 as it does on Linux. I love the fact that I can work on servlet and JSP ideas at home on Linux using Apache and Tomcat and then go to work and flesh out those ideas on Windows 2000 with WebSphere. Then, when we move that program to production it runs on an IBM mainframe running AIX. All without requiring a recompile.
No language is perfect. Any language can be improved. The 10 points in this article would make Java an even better language than it is now.
I'd say his commentary ammounted to "The ratio of benefit to breakage seems far less than one." And, I agree with him. Most of the proposed changes are nitpicking -- which is to say the final distance between the originial language and the "overhauled" language is not very far, and for all that effort, you bought incompatability.
Give me templates and typedefs. Those are changes worth breaking the language over. Those are suggestions that can hold their weight in a "Top 10 Java 3" list.