10 Reasons We Need Java 3 627
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."
Forget It (Score:4, Insightful)
The only way this will work is if it is compatable with older versions. Would anyone upgrade to Borland Builder 6 if they were told they couldn't compile there previous programs.
If it was compatable , then people could upgrade and start using in the morning.
Compatability requirement (Score:2)
that compatability is a requirement, but
that incompatable features can be added and
old ones phased out...
Thus ia actually a solved problem from
before Unix was written: I learned it from
a Multician.
--dave
Re:Forget It (Score:2)
Re:Forget It (Score:3, Interesting)
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.
Re:Forget It (Score:5, Insightful)
This article imagines a "Java 3" that jettisons the baggage of the last decade, and proposes numerous changes to the core language, virtual machine, and class libraries. The focus here is on those changes that many people (including the Java developers at Sun) would really like to make, but can't -- primarily for reasons of backwards compatibility.
In other words, Elliotte fully understands *why* his proposed changes would be difficult to implement. His 10 changes are contingent upon the assumption that you can break backwards compatibility.
It doesn't seem totally unreasonable to me. Microsoft forces people to upgrade their OS in order to support newer versions of their Office product. While I'm definitely not a Microsoft advocate, I believe that forced upgrades aren't necessarily a "bad thing."
Assuming Java 3.0 were implemented and backward compatibility was broken, Sun wouldn't pull the downloads for Java 2.0 off their websites. Moreover, a magical wave of energy won't wash over the planet halt'ing all Java 2.0 and 1.0 applications and permanently erasing their JDK installations. The 2.0 and 1.0 Java applications would simply become "legacy" code until such time that they are either replaced or updated to the new Java 3.0. In fact, it would not surprise me if a significant number of the apps were not migrated (because they were not judged important enough to spend money to upgrade) and continued to execute under the old Java.
The authors of Java 1.0 and Java 2.0 applications didn't have the benefit of coding under the "3.0 conventions". If the applications they wrote could really benefit from the changes, the authors will go back and refactor. If not, the application will continue to run in it's current form for years to come.
Upgrades are like refactorings. While toothless ones are trivial, they rarely provide significant benefit. It's usually the difficult upgrades (EJB 1.1 to 2.0?) that provide real opportunity for advancement. The 10 proposals by Elliotte seem like an example of the latter.
Java 3?? (Score:2)
"Java 1" is traditionally Java 1.1.x.
"Java 2" is Java 1.2.x.
"Java 3" is
Anyway, Java 1.4.x is out now.
Re:Java 3?? (Score:2)
Re:Java 3?? (Score:4, Insightful)
Given how interesting that sort of numbering approach is already, I see no additional confusion springing from the idea that Sun could declare 'Java 3' starting from JDK 1.6 - anyone who's going to get confused by these things already is.
10 Reasons We Need Java 3 (Score:5, Funny)
2. speed
3. speed
4. speed
5. speed
6. speed
7. speed
8. speed
9. speed
10. profit
One big thing Java needs (Score:5, Insightful)
Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while. jEdit, a popular Java text editor had to overcome this by attaching to an existing server process. Kludges like this shouldn't be necessary.
Re:One big thing Java needs (Score:2, Informative)
Jon
The Mac OS X JVM has this already (Score:5, Insightful)
it also means each process has the initial overhead of starting the VM and the continuing overhead of the same duplicated code running in memory for each VM.
Apple's JVM implementation for OS X already supports some of the features which you are requesting... For instance, Apple's JVM uses a shared memory space between JVM instances. This significantly reduces the memory footprint of each JVM instance and allows classes to be loaded only once. Example: I launch 2 Swing apps, they can share the same JFC classes, requiring class loading only once. I can stop and start the one of the appilcations without having to wait for Swing to be reloaded into memory.Startup time is not only an actual problem, but its gives a very bad impression when just launching a program takes a while.
Additionally, startup time is really not an issue on OS X. I am writing a fairly complex Java Swing application right now. On start up, it parses 3 (one of which is very large) configuration files, it creates a few Swing components, and finally displays a complex JFrame to the user. Total time for a cold start (no other JVM loaded) is approximately 2 seconds. That's certainly not slow. Not Sun needs to take a look at what Apple did and implement it back across their JVM implementations.
One big thing Java needs is a multi-process VM.
I don't really see what the advantage of this is. Again, the JVMs from Sun and Apple both use native threads. On most platforms, thread creation is less expensive than process creating. This is why Apache 2.0 is a hybird muli-threaded/multi-process application. Apache used to run a multi-process only model and it bogged down on Solaris b/c of process creation overhead. The new model overcomes this by using threads more heavily. As long as the threads take advantage of native thread features, like _____, thread use is most likely more efficient than process use.
BTW, on Linux, there is no real difference between a process and a thread, so Sun's JVM is already "multi-process" on Linux. And it's not any faster than their other implementations. As a matter of fact, Apple's JVM blows away Suns implementation on Linux and Windows (I haven't been able to test against Solaris).
Re:The Mac OS X JVM has this already (Score:2)
where did you get this info? i'm not second-guessing you, i just want to read it. can you point me to these docs, or is this something that you've learned through development.
thanks,
tyler
Re:The Mac OS X JVM has this already (Score:2)
I also have read about their JVM implementation at O'Reilly's web site (sorry, don't have any links but I'll see if I can find you some).
Re:The Mac OS X JVM has this already (Score:2)
i assumed that apple's dev site was the main jumping off point, i obviously just haven't looked around enough.
thanks.
Re:The Mac OS X JVM has this already (Score:2)
Fill in the blanks (Score:3, Informative)
So much for proof reading. :)
Re:The Mac OS X JVM has this already (Score:2)
But back on topic, breaking Java1 and Java2 compatibility is absolutely asinine. That would contradict one of the core design principles. Apple's got a decent JVM, apparently; the Windows one ain't bad; and IBM's developing a clustering VM that yields an 80% performance boost (or some ridiculous number like that).
The big thing I'm noticing is that Sun's implementation is somewhat lacking. What we need is a faster, more efficient VM. We have the specs, so that shouldn't be a problem. Or at least Apple and IBM don't seem to think so.
Re:The Mac OS X JVM has this already (Score:4, Informative)
You confuse me, because you obviously must understand the difference between threaded and multi-processed, yet you claim that there's no difference in Linux. There are numerous functional differences between the two. First and foremost, you have 100% isolation (sand-boxing). You're not concerned with race-conditions (well, you have to go out of your way to produce them at least), you have to explicitly share material (e.g. pipes or magical fork-aware objects), you're crash-proof (apache has a master process image; if one worker "thread" dies for almost any reason (baring OS problems), it VERY quickly forks a new worker which is 100% ready to go), and finally, MP has better caching issues with multiple CPUs (e.g. no shared and slow writable cache). To boot, while MT saves more total memory, MP more efficiently distributes it to workers. Non modified memory is freely shared in a safe manner (marked as read-only by the OS, and thereby efficiently cached by each CPU), and only modified memory gets moved. Granted, in JVM's garbage collector, the entire heap is constantly remodified.
As other's have said, I support the general idea of Apple method of sharing memory space between JVM's; though I don't know it's particulars. Most notably, the shared memory should be read-only (to avoid interdependency crashes). Next, it should only be shared per user (or at least copy-on-write), to disallow viral infections.
My concern is obviously for that of robustness. Java is already flimsy as it is in this respect (imagine running an entire OS with a single such point of failure).
Re:The Mac OS X JVM has this already (Score:5, Insightful)
"Flimsy"? I've been a professional Java developer for six years. I have written server software (running to Solaris and Linux) and client software (Swing applications running on Windows, Macintosh, and Linux). The server-side software is used by almost a million people a day; the client-side software hasn't yet been released to the public but is already being used internally. It will be used by millions when it is released.
Number of Java crashes I have seen in the past few years: Zero.
Java is obviously only as stable as your computer, so of course when a whole Windows machine goes down, you lose Java as well. However, I have seen absolutely no crashes directly tied to Java, on any OS, since JDK 1.2.2 came out. I don't know what version of Java you are playing with, but I'd hardly call that "flimsy".
As far as "imagine running an entire OS with a single such point of failure", that is perhaps the most ridiculous thing I've ever heard. Are you suggesting the Linux kernel is not a single point of failure? When the Linux kernel freaks out, your whole system goes down. That's a single point of failure if I've ever heard one.
Fix the JVM, Let Others Fix the Language (Score:5, Insightful)
Concentrate on the JVM.
Already Python can be compiled into java bytecode, and if the capability doesn't already exist for Ruby, it will soon. Similar compilers could be created for any number of other languages (scheme, smalltalk, whatever).
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.
Re:Fix the JVM, Let Others Fix the Language (Score:3, Interesting)
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
Re:One big thing Java needs (Score:4, Informative)
Due to the fact that the java classloader happens to be one of its cool features it is actually dead easy to implement this feature safely. Many java application launchers exist already that can let you share a jvm with multiple applications. I used several of them and was amazed at the difference in performance.
Serious features seriously needed (Score:2, Insightful)
- Multiple inheritance: some problem domains just don't map cleanly onto a single-inheritance model, and need the power that only multiple inheritance can bring. Multiple inheritance often leads to clearer code representations in the developer's head, avoiding the abstract mess present in languages like C++ and Eiffel which only kludge this feature with 'interfaces'.
- Operator overloading: this can be a natural and productive extension for the experienced coder, and aid the junior programmer to get up to speed quickly. Again, an important omission in other languages which should be fixed
- Pointers and direct memory access: Java currently makes it very difficult to write specific machine-targeted instructions. I find it frustrating that I can't wring out every last bit of performance from whatever CPU I'm coding for. The designers of Java really blew that one. Direct memory access with pointers like in Visual Basic and Delphi would be a godsend.
Re:Serious features seriously needed (Score:3, Insightful)
Um, isn't one of the key selling points of Java portability?, allowing programmers to write code for a specific (family of) cpus would utterly break that..
Re:Serious features seriously needed (Score:3, Interesting)
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?
???
Re:Serious features seriously needed (Score:2)
If you want a "faster," not cross platform language use C or Objective-C. Java isn't what you want.
Re:Serious features seriously needed (Score:2)
I want a cross-platform language and Java isn't what I want? The problem is that I want it to be fast too. C++ (which I also program) isn't exactly portable. Java isn't exactly fast.
But GCJ was exactly what I was talking about.
Re:Serious features seriously needed (Score:2)
I hope GCJ is everything you hoped it to be.
Re:Serious features seriously needed (Score:2)
Performance could really increase by much...
Yeah, it use to sound like this (one day - one day!). I'm sure the JIT does an amazing job at optimizing in real-time, but I don't think it's as good as true, "precompiled", native code.
Re:Serious features seriously needed (Score:2, Interesting)
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...
Re:Serious features seriously needed (Score:2)
It's a good day to be a Java programmer, but a bad time to be a LimeWire user!!
Re:Serious features seriously needed (Score:2, Insightful)
Perhaps multiple inheritance could be done in a sane way, but there's interfaces to avoid the need for multiple inheritence.
Operator Overloading - This is asking for trouble. I wouldn't mind having different arithmetic operators for Ints and Reals, it would make my life easier in the long run.
Pointers and direct memory access - ummmm, this is part of the point of Java, portable code, no direct memory access.
I would like to see a clean up of the APIs, and threading is a bit of a mess. And making basic types proper classes would be great.
Re:Serious features seriously needed (Score:2)
Well...I find interfaces to be done fairly badly, to be honest. I would like to be able to provide a default implementation for interface methods.
Of course, once you've done that you're half-way to multiple inheritence anyway. But half-way, not the full way.
Cheers,
Ian
Re:Serious features seriously needed (Score:2, Insightful)
Re:Serious features seriously needed (Score:2, Insightful)
Sounds like you have C++ envy. Maybe you should change languages if you really need all that. Java works quite well for most things without any of these features.
Re:Serious features seriously needed (Score:4, Interesting)
according to this [google.com] 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.
Re:Serious features seriously needed (Score:2)
Contrast this to languages like Smalltalk or Common Lisp- you don't have to recompile in the same way. You don't exit and start applications when you change a couple methods. Changes take effect then and there. With systems like these, you could easily increase your productivity.
Java on the other hand, is C++ with garbage collection. A big deal to some C/C++ers who have been living in a hole for the last 30 years, but nothing that will double your producivity.
Not much left... (Score:2)
I confess that I'm confused. You use words like "supremacy" when praising Java over C++, yet you think it's missing three of the big strengths of C++ that you would find useful. It also has no generic programming support to speak of, yet this is one of C++'s strongest features.
That's covered what Java takes out of C++, though of course you're not obliged to use any of it in C++ either. Java then gives you some degree of portability, GC and a vast standard library, though each of these also obviously has bad points as well as good (write once, debug everywhere/lack of deterministic destruction/bloat and bad design in places).
I can't really think of any other "big features" that distinguish programming one from programming the other in a really significant way. That being the case, I can't understand how you could describe either language as being better than the other; surely if you're after portability and safety for junior guys you'd err towards Java, while if you're after performance, low-level hacking or more powerful design tools you'd err towards C++?
Re:Serious features seriously needed (Score:5, Insightful)
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.
Operator overloading
I agree that it is a shame that this was not included. The usual arguement against them, that it's very easy to change the semantic meaning of an operator and this can confuse developers, is just as applicable to an "add" method, but I don't think it's a devastating loss to the language.
Pointers and direct memory access:
Ye gods. No. The moment you start doing this is the moment Java stops being cross platform, and this is a far more important feature than the extra performance that you could squeeze out of it with direct access. Since they sorted most of the performance issues out, I've rarely seen an app where there was any noticable issue in the speed of the actual java code at all (speed of DB link/RMI from overuse of EJBs are much more likely to be problems and unlikely to be sorted out with direct memory access. If you really need to do it, then write that bit in C or assembler on your native platform and call it using JNI. It's messy, but it makes sure that you really think about whether you need it or not.
You seem to have missed the biggest C++ related ommission from Java - templates. The ability to create typed arrays using a single line is something that Java would really benefit from.
Re:Serious features seriously needed (Score:2)
I like templates, but in this specific instance, part of the idea is that Java storage containers (arrays, lists, etc.) can hold any object. You want just arrays of X? Well, just unconditionally cast to X when you retrieve the elment.
Although the excessive casts in Java do annoy me a bit. Do we really ugly code like this:
Vector v = new Vector();
Integer x = new Integer(42);
Integer y = (Integer) v.elementAt(0);
there's far too much redundancy in all these declarations. The compiler should accept implied casting from Object to any type of object if the L-type of an assignment is already known. Admittedly, you'd still need a cast for things like:
int x=((Integer)v.nextElement()).parseInt();
But templates are extremely flexible, for instance allowing you to have an array indexed by some arbitrary object, etc. Also, templates mean that you end up without the need to check object type at run-time and reduce the requirement to have an anonymous Object type.Re:Serious features seriously needed (Score:3, Interesting)
Coming in J2SE 1.5, by all accounts. A "preview" compiler implementation is available from developer.java.sun.com.
Re:Serious features seriously needed (Score:3, Insightful)
Well, in well-defined language (Eiffel), this isn't a major problem: the developer have to solve by hand the conflict and that's all.
> >Pointers and direct memory access:
> Ye gods. No. The moment you start doing this is the moment Java stops being cross platform.
Pointers and direct memory access are two different thing.
Pointers in themselves can be used without preventing cross platform portability.
As for direct memory access, it's true that it is against portability, so what?
JNI are also non-portable but it doesn't mean that we should totally get rid of JNI.
As for the end, I agree: the lack of template in Java is quite annoying.
Some old myths surfacing here again (Score:3, Insightful)
Multiple inheritance of implementation has absolutely no major problems. If you have a conflict in a derived class, you can simply rename one or both functions in its interface. When your object is used as a base class object, it advertises the base class interface, and when it's used as a derived object, it advertises the derived interface, with the renamed features. If your derived version wants to provide an override of either or both base classes' implementation, you can always do so. None of this violates the Liskov Substitution Principle, or any other OO design rules. The only reason languages don't support MI is because it would break their object model or something that depends on it, not because of any theoretical flaw with MI itself.
I agree, often MI is not the right answer to a design problem. But when it is, it is. If your type genuinely can be interpreted as more than one base type and behave as such, multiple inheritance is the correct relationship to model that.
Indeed. The arguments against operator overloading are bizarre to say the least. "We don't like artificial operators!" they say, as they concatenate their strings using the + operator, while writing z1.addTo(z2) to add two complex numbers.
Added to which, as I've argued here before, operator overloading is a very important complement to writing generic algorithms. If I want to write a generic summation algorithm that can add the elements of an array of any type, is it more sensible for me to write it using the natural + notation and provide the ability for complex numbers, rational numbers, fixed point numbers and such to implement that operator, or is it smarter for me to hope that everyone gives their classes a method called add, and not addTo, sum, increase, or bananaMilkShake?
I agree entirely about the low-level features (hide them, don't make them part of a language like Java) and templates. Templates is a particularly glaring omission, and even the proposed generics aren't really up to the job of basic generic programming AFAICS. C++ IOStreams may suck because they gave every method a stupidly obscure name and no-one understands them, but compared to Java's "five lines of bizarre OO to read a string from the keyboard" approach, it's a godsend. A little generality would probably go a long way here, aside from improving things like the container class situation.
Re:Serious features seriously needed (Score:2)
class plane {
Nice and simple. interfaces and abstract classes to do the same is not nearly so quickmove()
}
class boat {
move()
}
class flyingboat inherits plane, boat {
if(flying)
plane::move();
else
boat::move();
}
0. (Score:2, Funny)
9. Fix incorrect naming conventions.
8. Eliminate primitive data types.
7. Extend chars to four bytes.
6. Fix threads.
5. Convert file formats to XML.
4. Ditch the AWT.
3. Rationalize the collections.
2. Redesign I/O.
1. Redesign class loading from scratch, this time with human interface factors in mind.
If he's so prolific, and knows exactly what it needs...
0. Do it himself.
He's a critic (Score:2)
Or so sayeth Brendan Behan.
very informative (Score:2, Interesting)
Some of his ideas do seem pretty radical. While using exceptions correctly without destroying OOD can pose a challenge, his claim that "exceptions amount to little more than fancied-up goto statements, and thus should be considered harmful," struck me as a little extreme. In the Java coding I've done in the enterprise over the last 9 years, I've never had a problem incorporating exceptions into clean designs. One point that I strongly agreed with was his assertion that a hypothetical Java 3 "would have some of the same shortcomings as Java 2," among them that it is too slow to really be effective for desktop or web services programming, where C++ and Python, respectively, have demonstrated their superiority thanks to more resistent type semantics and lazy virtual typing. This has been my experience, and in my firm we use Java exclusively for laying out interfaces that are later reimplemented in a more appropriate language. Because this reflects the way 90% of Java's users actually use it, I think a cleaner, slimmed-down Java could only benefit the Java community as a whole.
Re:very informative (Score:3, Insightful)
Not only extreme, but simply wrong...
Do goto statements propagate through inheritance hierarchies and let you differentiate between the errors they refer to through their type? Do goto statements generate easy to follow stack traces? Can you extend goto's to incorporate methods you might call?
Saying that goto statements are fancy exceptions, is like saying an Athlon is a fancy calculator, and in both cases it shows a great lack of insight.
Re:very informative (Score:3, Informative)
Although I haven't made up my mind yet on this myself, it does seem a quite reasonable idea.
Re:very informative (Score:2, Informative)
This has been my experience, and in my firm we use Java exclusively for laying out interfaces that are later reimplemented in a more appropriate language. Because this reflects the way 90% of Java's users actually use it...
Huh? - Ive worked for several large financial institutions in three European countries doing java development and I have never seen java used for rapid prototyping. The only project that Ive seen that *could* be described as working along these lines is the jxta project...
- Has anyone else seen java used for rapid prototyping ?
Any experiences pro/con?
- My initial impression is that it seems like quite a waste of resources...
Exceptions goto (Score:2)
Most flow of control statements, e.g. for loops, while loops, if-then-else blocks, are little more than fancied up front-ends to goto.
In that they do away with the need for raw gotos, they are good thing. Likewise exceptions.
More flexibility in swing (Score:2)
Wouldn't it be nice to be able to write java apps and have them look and act more like native applications.
Re:More flexibility in swing (Score:2, Informative)
Jon
Re:More flexibility in swing (Score:2)
There are already bindings for GTK+ and Qt for Java, so you could write "native looking" apps in Java easily.
Not sure why you'd want to trade one slow cross-platform widget set for another slower, less portable cross-platform widget set though (mozilla's UI).
[1] Some may be missing from anygui, or I have missed included toolkits, just giving you the idea.
Re:More flexibility in swing (Score:2)
In a word: No. The proof of the pudding is in the eating, and very few programs have tried to swallow the multitude of cross-platform toolkits available. The successful ones divorce themselves from the problems of trying to get a GUI to look the same on multiple platforms by providing their own widget set.
Quite simply, you can't do with a cross-platform GUI what you can do with a native GUI or an abstract widget set. Window's native checkbox, for example, can't have a background image or be transparent (without significant hacking); whereas checkboxes from many other native widget sets can.
On that topic, where do you (or anyone) get off claiming Qt to be the Linux native L&F. What about GNOME users? Or those who are using Twm and Xlib? Or those who will use FAWMAD (Future Amazing Window Manager And Desktop)? Even with Windows the "native widget set" argument is starting to slip, because many extended controls in older programs are not based on comctl32, and have the old Windows look even in XP.
backwards compatible (Score:5, Insightful)
True... (Score:4, Insightful)
1) Stick with the old Java 2 VM for a really really really long time, claiming backwards compatibility, and watch Sun fall on its face, or
2) Upgrade to Java 3 immediately and watch everything break.
Either way they obey the letter of the law, and it gives MS an opportunity to really push C# as developers get frustrated with the transition.
No need to remove functionality, just deprecate (Score:3, Insightful)
If the price of not pissing off the current user-base is to support some deprecated functionality, then I really think that the good outweighs the lack of asthetic simplicity of not having deprecated methods.
The Smalltalk way about numbers is right (Score:3, Interesting)
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.
Who would benefit? (Score:2, Insightful)
Not the users. IN GENERAL the cost the rework would be greater than the cost of the benefits of additional clarity.
I think the only real beneficiaries would be the Book authors, who would make a killing from killing trees to feed the poor confused users.
Now I wonder which camp ERH comes into...
The "most controversial" proposal (Score:4, Insightful)
> Eliminate primitive data types.
> This will undoubtedly be my most controversial
> proposal, but bear with me.
I can agree with almost every other proposal in this article, but he's right - this one will cause a fracas.
> I am not talking about removing int, float,
> double, char, and other types completely. I
> simply want to make them full objects with
> classes, methods, inheritance, and so forth.
One word - ew!
> This would make Java's type system much
> cleaner. We'd no longer need to use type-
> wrapper classes to add primitives to lists and
> hash tables. We could write methods that
> operated on all variables and data.
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.
> All types would be classes and all
> classes would be types. Every variable, field,
> and argument would be an instance of Object.
> Java would finally become a pure object-
> oriented language.
However, that wouldn't make all Java programs "object-oriented programs", nor would it make all Java developers "object-oriented programmers". I have a suspicion that it might impact things like the JNI too.
> Programmers in each environment need a language
> tailored for them. One size does not fit all.
<ahem> Quite. That's why you don't start an exercise in OOD by deriving everything from "TObject".
Re:The "most controversial" proposal (Score:5, Informative)
The article was about what can't be built on top of Java2. As Java2 (in 1.5) will be getting generics, I'm not surprised this was left out of the article. I believe there may well be some automatic boxing if you wish to use it, e.g.
List<Integer> x = new List<Integer>();
x.add (5);
but it's all up for debate at the moment of course...
Jon
Re:The "most controversial" proposal (Score:2, Interesting)
> 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.
Re:The "most controversial" proposal (Score:5, Insightful)
Why ew? Because of your limited programming experience with languages where this was eschewed?
In general, in computers, closure is a good thing. Ask any functional programmer. Ask any language theorist. Closure is good. To simplify closure, I am referring to having rules that don't have exceptions. Having a uniform representation for as much as possible.
In LISP data and code are stored the same way, as lists. This is the ultimate closure. Other languages implement other closures like having all data types be of a common type.
> What you really need is generics (as in C++ templates).
Lord God NO! Don't you EVER use C++ templates as an example of generics again. C++ templates are an attrocity. What you want is generic methods with multiple-dispatch. Look at Lisp's CLOS, or Dylan.
> However, that wouldn't make all Java programs "object-oriented programs",
Explain? How can you write a Non-OO program in a Pure-OO language? Cause, you see, it's not possible. You can write a program that isn't in the OO style that you think of when you think of OO. But you can't write a program that has data that isn't an "object" in a Pure-OO language.
> I have a suspicion that it might impact things like the JNI too
JNI would be as fine as it is now (yuch). Even the "float" class has to have an internal variable that actually stores the float.
Justin Dubs
Re:The "most controversial" proposal (Score:5, Interesting)
> 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.
Re:The "most controversial" proposal (Score:2)
http://www.cis.unisa.edu.au/~pizza/gj/
This was intended to be added into Java, I suppose it hasn't (haven't checked 1.4 though).
Re:The "most controversial" proposal (Score:3, Interesting)
>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 [avayalabs.com] (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.
Re:The "most controversial" proposal (Score:2, Interesting)
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 [jcp.org]
Re:The "most controversial" proposal (Score:2)
Furthermore, Java doesn't support operator overloading. I don't think it should, and I hope it never does. Converting primitives to objects would make such a kludge necessary, making what now seems somewhat inconsistent seem totally inconsistent.
And like you said, this would probably have a major impact on things like CORBA and JNI, since primitives are a part of IDL.
2 to 3 Valid points, some so-so, the rest bogus (Score:2)
Unicode:-
The man is right on with this. Crappy I18N capability is the next thing that has to fall for good in any computer/OS/VM that wants to be taken seriously. Especially in times of a global market.
API-weeding:-
So Java's API is bloated. Actually that's what made it successfull in the first place! Ton's of stuff for any Task - lots of it quick and dirty hacks and now they're slowly upgrading the crappy stuff whilst keeping the old on line. Sounds familiar? In case you haven't noticed: That's the only way you'll be successfull with a stunt like pushing something like Java into the market.
Yet it's bloated after all and really could use some serious weeding. But for the reasons stated above - I doubt it will happen.
XML:- Yeah, nice idea. If Java makes an uncombatible skip it would be nice to add this too. But I won't do wee-wee in my pants if it doesn't happen.
Where he's IMHO not quite right:
Build the VM for MP.-
Wrong. Computers are getting faster by the minute, but what we really need is a new architecuture all together. The other way around would actualy be more logical: Build a (addon) CISC CPU to radically enhance Java VM speed!
That would open a new market for all those considering Java as the holy grail of developement allready.
Where I don't agree:
Follows more Unix like philosophy than Windows or Mac.-
Big fat hairy deal. The Unix strukture is the best in common use when it comes to melding data abstraction with the way computers work. What do you want? The DOS/Windows way? Drives C:,D: and E:? C'm'on, gimme a break.
Isn't (Score:2, Interesting)
What a great article. (Score:2, Insightful)
Talking about "what should be Java" and "what should not be Java" is a volatile topic no matter how you slice it. One thing I think the Java community has going for it is that they're not nearly as fragmented or hyper-screaming knee-jerk as a lot of the C or C++ community is.
I could see Sun and/or the JCP taking these proposals and starting the J3 development cycle. The trick is that much of what he's talking about is more than just a couple weeks hacking by a few dozen coders. Theres some serious internal redesigns here. However, he has worked them all through, with well-thought out arguments for and against each of his points.
I don't profess to be a Java guru. I've only been working in the language for about a year, but I've found it strong, the community intelligent and professional, and the environment a pleasure to work with.
Java ain't just applets and painfully slow JVM's anymore.
Point by point (Score:4, Insightful)
10. Delete all deprecated methods, fields, classes, and interfaces
They don't get in my way much, so removing them wouldnt help me at all. It would only force me to re-write old but working code. I disagree with this one.
9. Fix incorrect naming conventions
Is InetAddress really that confusing that I need to re-write everything? And where is the benefit to me in moving java.sql to javax.sql. None that I can see, and it will create more errors until I learn the new way. I disagree with this one too.
8. Eliminate primitive data types
I can see the benefit to this. I like C#'s compromise where it automatically casts from native type to Object. BUT I don't think it is a good idea to slow Java down. It already has a bad reputation for speed, lets not make things worse. And as for "The int/char/double/float/boolean objects would be immutable, so these objects would be thread-safe and could be interned to save memory" I don't think you've really though this through Eliotte. What about "i++"? So I disagree with this one too.
7. Extend chars to four bytes
May I dont spend enough time writing XML parsers, but I've never been bitten by this one. So to me it doesn't seem worth the cost of re-writing everything. So I disagree with this one too.
6. Fix threads
Yes Thread have had problems, but they are still very useful. I'm prepared to make use of Thread and wait for the JSR to come up with improvements. I am more in agreement here, but not to the point of shoulding applause
5. Convert file formats to XML
I can see the benefits, but not enough to re-write all my servlets etc. And I don't think this change requires Java 3, just some updates to the servlet spec etc. Reason for Java 3? Not from where I stand.
4. Ditch the AWT
I can hear people (IBM) wanting to drop Swing because it is too slow, but not so much wanting to drop AWT. The key thing is where does anyone benefit from removing AWT? Surely have a class call JButton is not that complex that we need to break all that code? I'm not agreeing with this one much either.
3. Rationalize the collections
Well there aren't that many problems. I suggest we just *gradually* deprecate Vector and Hashtable and carry on with the alternatives.
2. Redesign I/O
No not again! Please! I've taken 2 re-writes already. Perhaps File could be updated as some of Eliotte's suggestions, but that hardly requires Java3.
1. Redesign class loading from scratch, this time with human interface factors in mind
Accepted this is a problem. But while neither I nor Eliotte has a solution, perhaps we should make do with learning the idiosyncracies, or finding solutions rather than calling for Java 3.
Re:Point by point (Score:2, Insightful)
> Accepted this is a problem.
Classloaders are a little difficult to understand, but they are not a problem!
Classes loaded by different classloaders may never have the same type, because they might be completly different, implement different interfaces and have nothing at all to do with each other.
Also you could load a class java.lang.String from a different Classloader and pass it to other classes. The class is declared final, but who cares, if you can just load a different class in a different classlaoder? This would cause huge security problems.
Classloaders are implemented the right way. So don't change this (The exception messages could be improved though).
Re:Point by point (Score:3, Insightful)
Ok, all of your disagreements amounted to: "It doesn't affect me so i don't know but it shouldn't change anway", "I'm too lazy to learn a new way.", and "I can't think of a better way so there must no be one."
About the most useless and long commentary i've seen in a while.
Of course this response entire can be summed up as "You're dumb" and thus isn't real useful, but yeesh.
Re:Point by point (Score:3, Interesting)
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.
Re:Point by point (Score:2)
No, i++ is shorthand for "i.increment()". If you make ints etc immutable you can't do this, because it's like trying to write 1++, hence making all instances of 1 in the system into 2.
It's no great loss imo; I thought I'd miss it in Ruby, but it turns out that i+=1 isn't much more to type and there's a lot to be said for having a nice clean object model.
Of course from a backward compatibility standpoint it would suck somewhat. It'd have to be called Java++ or something
Re:Point by point (Score:4, Informative)
Exceptions come in two flavors, and the difference is simple. Checked exceptions must be caught, Unchecked exceptions don't. If you call a method that throws a checked exception, you must catch that exception, or the compiler flags it as an error. If the exception is unchecked, you can call the method outside a try-catch block without complaint from the compiler.
Interesting that Java has checked exceptions, .NET doesn't, and developers from both camps want things the other way around.
Missing the essential (Score:3, Insightful)
So in my not-so-humble opinion what Java needs greatly is a completely redesigned & revamped architecture (bytecode & JVM) with compatibility modes, of course.
Most points discussed in the article are just library-related. Those simply do not justify a new major release.
The Raven
Re:Missing the essential (Score:3, Insightful)
Or you could look at it this way: the JVM is like an operating system. It handles threads, scheduling, memory management, I/O--this list goes on. And as in an operating system, design choices made for each of these subsystems have an effect on overall performance. Certain scheduling algorithms, for instance, favor I/O-bound processes, while others favor CPU-bound processes. I bet Sun compromised in a lot of areas of their implementation in order to get decent performance overall. I'm sure different implementation decisions will have different results. There just aren't a lot to choose from.
And Sun was targetting a server-side market from the start. So it's probably safe to say that their implementation favors the Sparc in all its 64-bit glory. I'm sure if someone really focuses on the desktop and kept Swing in mind they could come up with something better for the end user.
Re:Missing the essential (Score:3, Insightful)
This is just plain wrong, I'm afraid. It just requires that you don't take a simplistic approach converting bytecode to native code.
If you're converting a function from byte-code to native code, you can easily look at a stack based bytecode and build up a full parse tree for each statement and optimise that for the target platform.
Besides, how many registers would your ideal JVM have? 4? 8? 32? 256? What if it's run on a machine with more registers? It just won't use them. What if it's run on a machine with less? Well, it'll have to start swapping registers to memory back and forth, and become very inefficient. Using a JIT and a stack based approach, the target code is optimised for the host machine and the JIT doesn't have to worry about what "registers" the code is using for what.
Perhaps Donald Knuth sums it up better: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
If you weren't talking about a JIT but a byte-code interpreter, then you'd probably be implementing registers in an array anyway, so your comment doesn't make too much sense.
Class loader (Score:2)
Some observations (Score:5, Informative)
This is a refreshing view on changes to Java, because it doesn't make the traditional calls for templates, a preprocessor, and operator overloading. Most of the article is well considered and logical, and should be implemented in a move to Java 3.
There are however some issues with which I must disagree:
While the overhead of promoting all primitive types to objects may be insignificant, the overhead of checking all arithmetic for overflow does have the possibility of causing significant overhead.
Not only that, but you will still end up with a RuntimeException, because you cannot expect ALL arithmetic to be in a try
Overflow errors are a well known problem - well-written software should not suffer from them.
Many Java developers are caught by using code like b = (byte)i; rather than b = (byte)(i & 0xff);. It is generally true that when dealing with bytes, you want to keep data as bytes until you explicitly make it into another type.
Finally, byte arithmetic should always overflow, as is expected in CPUs.
While J2ME is not fully Java-compliant (no floating point support, for example), it still largely conforms to the write-once test-everywhere rule, and this is part of Java's attractiveness.
More memory is not always a good solution. Java's garbage collection architecture is very wasteful of memory at the best of times; at the worst of times you are using immutable objects like Strings, so you can't pool or reuse the objects. As increasingly more applications handle text because of our new XML obsession, this situation becomes worse.
Java implementations typically do not emulate threads on their most common platforms - they make use of the native threading model of the operating system. This means that making a 64-bit operation atomic must involve the use of a lock; so instead of a 64-bit operation taking up 4 times the time of a 32-bit operation, it could take that plus two calls into kernel space.
As mentioned before, the same is true of using arbitrary-size numbers. Only a number that the CPU can treat atomically will result in an atomic operation without additional synchronisation.
Thus, to have different types of operations (all implemenented in one object) synchronised on different locks, simply use each in an explicit synchronisation block and have private or protected lock objects specifically for that purpose.
Decoupling monitors from objects would kill a lot of the ease-of-use that makes Java threading such a pleasure by comparison to many other models.
Furthermore it ONLY has monitors as locking primitives, which rules out the use of overlapping locks, which are one of the few effective synchronisation primitives which can overcome weakly-defined scheduling.
Java would do well to add an additional synchronisation primitive - either mutexes (as error-prone as they are), or interlocked increment-and-compare (which can solve a number of synchronisation problems far more effectively than mutexes).
For a better critique of XML take a look at http://www.eastcoast.co.za/twylite/pml/pml.html" >my anti-XML page (incomplete, but the anti-XML rationale is presented).
In particular, XML is a very poor choice for the encoding of Java objects, because of its lack of terseness, and the relatively slower speed of parsing XML - both of which impose significant penalties in a distributed environment.
Some hard facts to back up these claims: in an application I have worked on, we experimented with SOAP instead of our original binary protocol. The result was a 80% decrease in call rate.
In a few years, the XML phenomenon will wear off, and world+dog will wonder why we are wasting our precious bandwidth on all the overhead. Already WS developers are starting to wonder how it will affect their resources, and we have proposals for a binary encoded XML for the mobile world.
This "simple" specification is too complex and too overkill for most tasks, so every "lightweight" XML parser on the market conveniently leaves out certain parts of the specification - be it DTD, PI, CDATA, whatever. We already have XML documents that aren't compatible between two parsers, the situation will only worsen.
And in the end we will realise that it isn't necessary to make computer data human-readable, because really, everything is just a bucket of bytes and a rule on how to view it, and XML is a very, very poor rule.
Java is not perfect. It is not a silver bullet, and it is certainly not everything to everyone. Instead, it offers an environment that, to a lot of people, is a damn sight better than C++ because it avoids the error-prone complexities and power of the latter. But you must accepts its weaknesses as a trade-off.
Nitpicking from a professional programmer (Score:5, Insightful)
9 ) Ok, within the java API the naming convention should be consistant. Outside of the API it's the programmers decesion. To dictate a style of writing would place an undue burden on programmers
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
As for your comment about 2b + 2b != 4b... No shit you add two SIGNED 32bit values and expect it to work properly despite the buffer overflow! BigInteger is part of java.math and is a perfedt counterpart to Integer, but can be as big as you want.
7) Um, mabye. Chars are already expected to represent string and I doubt there would be much resistance to having a JVM decide how big those should be. It's not like he's trying to suggest that short should be changed ( oh... yea ).
6) I can see some cleanup here. Threadgroups could go away and 99.9% of people would not care. As for the non-atomic nature of 64bit+ primatives that has alwyas been clearly documented in the spec. It does not guarentee atomic operations on anything longer than 32bits. Although this could be changed it was always a trade off between the smaller systems and the larger systems that java would be running on.
5) No, please, no more bloat. XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
4) Smoking the BAD crack. AWT has it's warts and problems, but just look at mozilla on the MAC for all the reasons that native widgets should continue to be supported at all costs. I would not mind an alternate WM/WT as long as it had true native peers so that java can participate as a first class application on all platforms. AWT currently is poorly designed to handle the diffrences between OS's and take advantage of the niceties on some platforms, but that's no reason to abandon native widgets.
3) Java has two sets of collecations. Ove that was based on 1.1 ( Vector, Hashtable ) and one for Java2 ( List, HashMap ). Anybody that's bothered to read a performace tuning book would realize that the Java2 collection system ( although without generics ) is by far the better system. The Java2 system allows either synchronized or non-synchronized operation. This is because the vast majority of java collection use is internal to a class or method where syncronization just adds a burden to the system. Why use a beartrap for holding your desk pens when a cup would work just as well.
2) Yes, count me in. The I/O subsystem uner java it totally inoperative for many tasks. A RFE currently pending ( for several years ) is to adda simple way of finding out how much free space is availible on the filesystem. Metadata information is a casulatly of war. It just needs to be tossed out.
One thing that he doesn't hit on, but it a REQUIREMENT for interoperability is some standardized way of doing fixed block decoding/encoding ( think struct ). It's just amess trying to get complex binary structures into and out of java without going quite mad.
I don't agree that Streams should be buffered by default as that can CAUSE problems. Buffering should alwyas be under the control of the programer.
1) Yes, it's already known that the current class loader has some issues, but they are working on a better one. There is no reason to throw the baby out with the bathwater. Many advanced programs are running into problems expecially when they are using custom class loaders.
But.... he didn't even mention quite a few issues I have personally with my big pet peve being....
The GC. Many programs need some feedback and some wat to hint or force the GC of specific objects ( since they peer with NATIVE blocks of ( memeory/code) ). It's very important that the programmer be able to programmaticly control SOME operations of the GC subsystem. I'm not asking for malloc/free, but there are some objects that can be a pain to work with and some programming requirements that cannot be achived under the current GC system. It's a black box without any feedback. I would like to be able to tell the GC when I have 10ms where I know the system's time would be better spent cleaning up after itself to go ahead nad do it. I need to be able to force the cleanup of specific classes/instances when they are holding on to native resources.
Anyways..... I think I've rated enough. I can see where this guy is comming from, but most of his points are whining or ignorace of the system.
Re:Nitpicking from a professional programmer (Score:3, Insightful)
And your reason is? You have of course studied the way that C# does this, keeping both primitive-type-speed and uniform-object-hierarchy uniformity?
As for your comment about 2b + 2b != 4b... No shit you add two SIGNED 32bit values and expect it to work properly despite the buffer overflow!
Um, I think that's his point: Bits & buffers & overflows are right for data, addition working properly without the potential for buffer overflows is for integer math. The two are very differnt things.
Re:Nitpicking from a professional programmer (Score:3, Insightful)
(Must...resist...spelling...comment.) Why? Using primitives with objects (especially colllections) is ugly, inconvenient, and inefficient. If properly done, speed won't suffer and you'll continue to use operators on int and float "objects". Much as it pains me to say it, C# does this right.
BigInteger is part of java.math and is a perfedt counterpart to Integer, but can be as big as you want.
Right, and if primitives and objects were merged it would be much easier to use BigInteger and BigDecimal, since you could use standard operators instead of clunky methods, i.e. "bignum += 2" vs bignum = bignum.add(new BigInteger("2")).
I can see where this guy is comming from, but most of his points are whining or ignorace of the system.
XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
Huh? He's talking about using XML as the serialization format instead of the current binary format. It doesn't change the API at all, nor add bloat. Text formats are almost always better than binary, and as the author points out, it may actually improve performance.
I can see where this guy is comming from, but most of his points are whining or ignorace of the system.
I guarantee that "this guy" knows far more about Java than you.
Top ten reasons we need Java 3 (Score:5, Funny)
9. Cool 3D-glasses marketing gimick potential
8. We can all complain more when MS doesn't support it.
7. Library need another complete overhaul of the GUI classes.
6. Add in all of the C/C++ features that we're left out.
5. O'Rielly can sell another series of books (how about a fungus?).
4. Since all of the people who know Java 2 are unemployed, this project will keep them off the streets and out of trouble.
3. Java doesn't have enough incompatibility issues as it is. We need to level the playing field.
2. 'Cause the alternative is caving in to C#.
1. Emacs is better than vi.
Re:Top ten reasons we need Java 3 (Score:3, Funny)
Seriously, lt's not cave in to C!so#
Why not just drop the depricated... (Score:2)
Dropping the original IO or AWT would suck because at times they are 10x faster than the newer equivalents. I learned that by porting, then screaming, then unporting. I wouldn't mind if AWT and the original IO were lost in Java 4, after being depricated when Java 3 is introduced. Then we can push for the performance and completeness increases in those before we have to use them, perhaps by carefully refactoring the newer stuff not to depend on the old, nativizing some things, etc. So a JColor would be introduced for instance. The new io is too complex, but it is the complex we know
Porting code to a new languange is no small thing. I'd rather port to C++ if the effort is that large, it has become a lot more standards compliant in the last 7 years...
I know people that complained Java 1.3 wasn't backward compatible enough because of how it treated anonymous packages. I can see those ppl switching to C#.
myArray.length, myVector.size(), myString.length() (Score:5, Insightful)
myArray.length
myVector.size()
myString.length()
It also drives me nuts having to convert all the time between the primitive data types and the Object data types (int/Integer, long/Long, etc).
Other than that, even with its current flaws I simply have to love Java (I guess is like being married to someone who is not perfect, but that you wouldn't change for anything in the world...)
Rebuttal (Score:5, Insightful)
While I would also like to see these die, to tell the truth, Java has done an above average job here. In most other (should I qualify that as "practical") languages, there isn't even a concept of deprecated. Deprecated is your client calling you up and telling you something is breaking in a weird way and you say "oh yeah, don't use that". In Java when you deprecate something it means something. The compiler compiles in a flag, and anything that is built against deprecated methods, the compiler will spit out a big fat "THIS IS DEPRECATED" warning. You can't do much better than that. So while I'd like to see these things gone, the reality is that there is a lot of code that is using them, and they really aren't doing much harm. The most "harmful" are the deprecated thread operations. Everything else has mostly been for name changes or additional functionality. Take the most out of your own eye first and all...
This is just a library issue, not a language issue.
9. Fix incorrect naming conventions.
Amen. Given that we adhere to whatever we resolve to do with deprecations, fine. But again, Sun has done a terrific job, and if you look through the libraries, I'd say 90% or greater (including deprecated stuff) adheres pretty well to the standard. Again, this is just a library issue, not a language issue.
8. Eliminate primitive data types.
What you want is "boxing" (like C#/.NET/CLR does), and they're already working on it: RFE 4609038 Request auto boxing of primitives in Java [sun.com].
7. Extend chars to four bytes.
Meh. I don't use Unicode that much, so it's not as relevant to me, I'll trust you on this one. Just don't bloat up good ole US-ASCII character strings.
6. Fix threads.
I generally agree. The first 5 bullets are pretty trivial. I have never ever run into a problem when using threads, even with complicated synchronization implementations. The last bullet is already possible: write your own damn monitor! Nobody is stopping you as long as the sychronization primitives work. Here I'll give you a clue: custom monitor implementations [toolsofcomputing.org]. Easy as cake. I'm not sure what the author is really asking for here. Sun cannot possibly make every single implementation of a monitor somebody would like (ok, well, it *could* but why?). It gives you the primitives and you go from there. That is why you are a programmer.
5. Convert file formats to XML.
No no no no no no NO. XML is not a panacea. Please DON'T turn everything into XML. The formats that exist (properties format, manifest format) are simple and designed for their purpose. XML has its uses, and simple, flat, non-hierarchical, terse data, which has absolutely no expectation of being rendered visually or translated into another form, is not one of them. I don't see any REASON being proposed other than "everybody is using it". Well, if everybody jumped off a bridge...
4. Ditch the AWT.
Meh. I have a better one. Replace AWT with a natively back-ended Swing or Swing-like API, akin to IBM's SWT. Swing is a lovely API, but it is cumbersome to lug all the libraries around, and it is slow. SWT is a nice compromise (nice high-level abstract, generic, Java API - to the metal native implementation).
3. Rationalize the collections.
This is basically an argument against the deprecated classes, for which there are already replacements. I don't see much wrong with the Collections API (i.e. java.util 1.2+), and when generics arrive, it will be much more useful (no tedious subclassing or casting to contained type). The author is making some fuzzy argument that the Collections APIis not cuddly enough or something. It's a starting point - it has the most used structures (hashtable, linked list, growable array, etc.). If you don't like them, feel free to subclass or write your own. They are fine for me, and certainly don't rank up at 3 as far as complaints to Sun go.
2. Redesigned I/O
A bunch of non-arguments here. Again, for something like 90% of the time, this is going to do you just fine. Please DON'T sneak buffering into classes which do not announce this fact. This is the charm of composition, and I think it works nicely. Want a stream buffered? Wrap it with a buffering stream. Want a stream GZipped? Wrap it with a GZip*Stream. Anyway, there IS a new IO API, which promises much better performance (introduces asynchronous I/O), java.nio.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Agreed. This is getting to be a headache. Especially when deploying in application servers/servlet engines that have their own custom classloaders. There probably isn't a good solution other than good documentation, and reduction of unnecessary conflicts when security is obviously not an issue (the whole reason of seperate classloaders to begin with).
Summing Up
Well, this article is largely gripes about the library not the language, and where it gripes about the language, those gripes are already being addressed. I would complain about things like, methods not being first-class objects (callback classes are really annoying), unspecified symbol resolution in the language spec, inner classes not being allowed to have static declarations, lack of enumeration type in the language itself, interfaces unable to declare overridable fields, array types being pseudo objects when they could instead be easily made to be real objects which could be subclassed, etc.
Re:We already have Java 3 (Score:2)
Re:We already have Java 3 (Score:2)
Our slogan: Prettier code, less RAM requirements, faster startup and more fun!
Dangerous words around these parts!
Re:We already have Java 3 (Score:2)
Smalltalk made the following mistakes:
1) Everything is objects and messages. Anytime when a language overrides mathematical prcedence is when I say bye-bye. Math has been around for several hundred years and Smalltalk only 30. Smalltalk looses this one.
2) Smalltalk was a live running system. Nice idea, but when a Smalltalk system corrupts you have definite issues.
3) Smalltalk reinvented UI. I have worked with Smalltalk and on Windows Smalltalk looked butt ugly because Smalltalk did its own thing.
Add everything up and you get the reason why Smalltalk was dropped like a hot potatoe when Java came out.
Sorry... Worked too much with people who used Smalltalk and "crow" over it.
Re:We already have Java 3 (Score:3, Informative)
1) That is one of the appeals of Smalltalk, that everything is an object, every action a message send- no exceptions. If you're not into OO or even object-based programming (not same things), then Smalltalk certainly isn't for you.
Never understood why people get upset about precedence- use parethesis. It doesn't throw math out of the window like you imply, it just makes you be explcit about it. Also, there's no reason you couldn't add precedence to the Smalltalk compiler, which if available in the image, of course. People have done it, but it never has stuck, because it preaks consistence with other Smalltalk implementations.
2) Which is why you can save images of Smalltalk systems or use version manager systems like ENVY/Developer (which roughly serve the same purpose as CVS does for everyone else). Same argument could go for anything not etched in ROM- files corrupt, so don't use Java or C. If you don't backup your code or otherwise be dumb about saving your image, you'll get yourself in trouble- whether it's Smalltalk, another image-based language, or a file-based one.
3) Correction: Smalltalk *invented* the WIMP UI.
It is heavily dependent on the implementation. The Smalltalk I use for computational ecology research and for my OS is Squeak- which doesn't look like any native widgets. Don't bother me, as I run it full-screen in lieu of X11 most of the time, so for me, Qt is the odd-man on my system, ruining the consistent-look-and-feel across my machine. (only non-Squeak app I use is Opera) I'm in the minority on that one, though.
That's only one implementation. IBM's VisualAge Smalltalk uses native widgets, I used it when doing an internship at an insurance company. Dolphin Smalltalk uses fully native Win32 widgets and has great integration with the Win32 system. Smalltalk/MT, Cincom ObjectStudio, also do the same. Older implementations like Smalltalk/V also use native widgets on Mac OS and Win32.
VisualWorks Smalltalk, probably the most popular commercial Smalltalk, is the only commercial Smalltalk that has emulated widget looks like Swing, any more. Definately not as pretty as getting wraps around the real widgets, ala all those other implementations I listed.
A handful of threads in here are lauding Java because it have native look and feel, but saying the same thing about it as you are Smalltalk. But with both Smalltalk and Java, you can use native widgets by binding to them.
Re:We already have Java 3 (Score:2)
Re:Arse (Score:3, Funny)
Hey, it's hard to figure out the classpath! You need to take the dots and change them into slashes, for crying out loud! And never forget the classpath is relative to the base directory! my head hurts... *sob*
Re:Arse (Score:3, Insightful)
people shouldn't be using deprecated methods anyway...that's why they're deprecated, becuase they may not be supported in future releases...this makes perfect sense...
Eliminate primitive data types - oh yeah, please let me do x = new Int(1) + new Int(3);
did you even read his explanation??? from the article: "The new byte, int, long, double, float, and char classes would still have the literal forms they have today. Just as the statement String s ="Hello" creates a new String object, so too would int i = 23 create a new int object."...the way you use them wouldn't change at all...in fact this would totally eliminate the need to create new Integers, Doubles, Booleans, etc, when you wanted to put primitive things in lists, hashmaps, etc...that's a big pain now...
Re:once burned... (Score:3, Insightful)
You must not have done much work in C++ or C. The K&R C to ANSI C transition broke many of my programs, and C++, well, all I can say is that I remember having to make changes to my C++ code almost every time a new compiler version was introduced in the early 90's.