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."
"without the requirement to keep compatibility with old versions"
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.
Cruise TT
Hmm...
...?
:-)
"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.
Beware: In C++, your friends can see your privates!
Microsoft Visual Studio .NET is not compatible with old versions. Visual Basic.NET only has a shallow likeness to it's predecessors.
Sometimes it is possible and necessary to break compability.
1. speed
2. speed
3. speed
4. speed
5. speed
6. speed
7. speed
8. speed
9. speed
10. profit
One big thing Java needs is a multi-process VM. Think about it, how many processes does your machine run? Probably lots. How many does a Java virtual machine run? One. Each process has its own VM. While this might have some advantages when it comes to controlling crashes and security, 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.
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.
I have spent the majority of my time over the past 4 years programming Java professionally for a number of large corporate clients, mostly in the banking and telecoms sectors. While Java has certainly allowed me to increase my productivity substantially over more 'traditional' languages like C and C++, there are still a number of important features that should be included in Java 3 in order for it to fully cement it's supremacy over C/C++:
- 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.
10. Delete all deprecated methods, fields, classes, and interfaces.
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.
If voting were effective, it would be illegal by now.
I noted in a comment to the initial article
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
davecb@spamcop.net
If people start writing for new java, then people with old java shall get cut out -- the Windows users, more than likely. They are going to have to get new java on there own, and i'm not sure how many people want to. However, they will likely have .NET forced on them anyway. New Java will just encourage use of C# unless it remains backwards compatible.
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.
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...
DWR is Ajax for Java
One thing that desperately needs to be done to increase the speed of Java is dynamic translation of the binaries to the format of the native platform. This works well for emulation and the AS/400, and the results could even be cached for quicker load times on the next run. Additionally, it's high time for specialized 'Java' expansion boards to arrive; we accelerate MPEG4, and I believe that providing the option of speeding Java binaries past the execution speed of native binaries would be a huge boon to Sun and developers. Finally, the ability for applets to access ActiveX controls on the remote system would greatly enhance the ability of developers to roll out content such as custom movie viewers and embedded controllers. Completely necessary if it's going to reclaim some of the webspace lost to Flash, IMHO.
Virtualization techniques could also speed things up overall, perhaps to the point of making multiplayer OpenGL via Java a reality. Java 4, perhaps?
I know I know
1. really a clean multi arch small JVM would be really nice (somthing like the KVM) as a ref which is not encumbered by signing up to use SUN's software just that you will contribute any work back
2. classpath actually working well (needs a good maintainer)
The reason Java used primitive data types in the first place was speed. Oh how they failed.
Number 8 -
:)
> 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".
These sigs are more interesting tha
haveing to do
new int
or the equivlent in the JVM would slow things down I am sure
regards
john jones
What the hell does that guy even know about coding? I bet he hasn't done any programming since he left Hard Copy for Fox.. oh.
...is to know what to use to make it work on all of your target platforms...and wasn't this supposed to be one of Java's strong points? So, actually, a fresh start might not be that bad at all.
"Top ten reasons to use C# and not java" - This is great ammo!! Thanks Slashdot!
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).
10. Get rid of deprecated methods - don't be an arse, ruins past compatability with no benefits.
9. . Fix incorrect naming conventions - Jesus, Get OVER it!
8. Eliminate primitive data types - oh yeah, please let me do x = new Int(1) + new Int(3);
7. Eliminate primitive data types - oh, ok then
6.
OK, bored now...
but, really,
No single topic is as confusing to new users as the class path. I get almost daily e-mail from novice readers asking me to explain the "Exception in thread 'main' java.lang.NoClassDefFoundError: HelloWorld" error messages they keep seeing.
Well, tell them to get fucked and go and read the Java tutorial then! You don't even need classpath from Java 1.2 onwards. Jesus, let's redo a language because first-time users can't get Hello World to work!
This is a really wank article - I like the conclusion..
Java needs fixing, I really don't know how or why, so lets discuss it. Arse. and Arse again.
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?
Its wonderful seeing well thought out postings on this topic - my respect for this guy has just gone up a LOT, and I'm going to take a look at his books.
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.
Event Management Solutions : http://www.stonekeep.com/
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++?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
this comment says it all
bluntly....
I mean has this guy ever actually looked at the debugger and tried to optermize things ?
new objects are a big penelty and this guy wants to make int into one ?
mapping a stack based VM ontop of a register based machine is never going to be easy
and ontop of that you cant get rid of AWT and expect SWING to work arrgghhh
fools
I've actually tried to Base64 encode binary files in Java to make them safe to represent as strings and it ain't pretty memory-wise.
This person has some good points too but I don't believe s/he knows the base64 point first-hand.
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.
DWR is Ajax for Java
... 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)
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
The Raven
I doubt that it would be possible for anyone to fix the entire Java language by themselves. Compilers are tricky things to write, not to mention a fully-featured/multi-platform language like Java.
Java 1.5 will add autoboxing for primitive types and typed containers. Breaking compatibility seems neither a realistic nor a good option. Concerning AWT and SWING issues, I'd like to recommend to take a look at the SWT of the Eclipse project.
which are better, (bush's) baked beans, or (van camp's) pork and beans?
i know ed gein was a big pork and beans fan..
Things like - 'java lets you write once and run everywhere'.
Java *DOESN'T* "run everywhere" as the original Sun mantra stated.
If you are going to flap your yap about what Sun "needs" to do, start with getting Java to do what it was supposed to do...run everywhere.
In the last 2 developement environments I've worked at we've always kept several version's of java on each system. When a new version was released we added that to the system leaving the old version also so that developers could put either version in their path. So if this theoretical version 3 was released why can't maintainer's keep an old version in place as well?
Java was the first major language to integrate multithreading as a fundamental feature rather than a special purpose add-on library.
Except Ada83 which is
There are probably others too.
One point he mentions is making the class loader better -- but he doesn't know how. Amen! I hate the fscking class loader!! :-)
i can't find your camel section. do you sell these? thanks in advance.
yrs, pinchpenis
So much for proof reading. :)
You could do it yourself.
But Sun owns it, so you can't.
Why don't people use a free JVM-workalike like Kaffe to implement these ideas?
Eventually you could opt not to use Sun's Java at all.
It seems like Sun is hindering the evolution of Java.
Some people are good at some things and some people are good at others.
You could be a great designer, but be crap at building things. It's better that you stick inside you skill set and don't cross into things you'r not good at, that do do some really good design a make a hash of the implementation.
Patient: 'Doctor I have a problem with my leg.'
Doctor: 'Ahh I see I think it's this but I'll just phone the consultant'
Patient: 'Will he come round and fix my leg?'
Doctor: 'No he's a consultant'
thank God the internet isn't a human right.
What's all this about Java 2? I thought we were on version 1.4...?
Hmmmm.
Invoicing, Time Tracking, Reporting
people that get into arguments about thread implementation at the bar deserve our attention on the issue.
The original Java developers were Unix programmers, Windows users, and Mac dilettantes. The I/O APIs they invented were more than a little Unix-centric in both obvious and not-so-obvious ways, and really didn't port very well. For instance, initially they assumed that the file system had a single root. This is true on Unix, but false on Windows and the Mac. Both the new and old I/O APIs still assume that the complete contents of a file can be accessed as a stream (true on Windows and Unix but false on the Mac).
I'm no Java expert, but I'm sceptical that *all* the contents of a Windows file can be accessed as a stream. What about the hidden NT Alternate Data Streams? They can't be deleted (apart from the file to which they are attached), and can even be attached to directories. This is analogous to the Macintosh Resorce Fork.
Paul Gillingwater
MBA, CISSP, CISM
And I hope we all remember that critics are like eunuchs (as opposed to unix) in a harem: They know how it's done, they've seen it done every day, but they're unable to do it themselves.
Or so sayeth Brendan Behan.
"...At the end of the day"..."when everyone goes home, you're stuck with yourself." RIP Layne Staley
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Comment removed based on user account deletion
As another noted, the JVM is already capable of running multiple processes on Mac OS X. Fix the JVMs for GNU/Linux, FreeBSD, Solaris, and those obscure, mutually incompatible operating systems from Redmond :-), and let others fix (or replace) the language.
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.
The Future of Human Evolution: Autonomy
But what if it's not just your code that needs refactoring? What if the language itself has inconsistencies, inefficiencies, and just plain idiocies that need to be corrected? When you get right down to it, the entirety of Java is really just like any other large code base. It has some brilliant parts, some functional parts, and some parts that make just about everyone scratch their heads and ask, "What the hell were they thinking?"
Reminds me the good old arguments against using C++. Isn't Java supposed to be a revamp of C++. I guess Bjarne Stroustroup was right about what is going to happen to Java.
Later
Realize that it needs to happen someday.
---
Realize that his 10 points arnt all correct, but most of them are well justified through other papers and significant work outside his article.
I fundamently disagree with his argument about the primitives and their objectification (a word?). Instead I advocate type-signficant templates and language support to naturally extend collection support to leverage primatives in the collections.
I would also advocate more primitive types that better cater for the real machine level issues.
I strongly disagree with #5, the serialization of objects using the XML file format. Where speed is necessary, XML is insignificant. (Ideally, the XML standards org needs to define a compact binary format for XML. That would be good. Using the current XML text based xml fileformat is crazy, if only usefull for final stage output storage.)
His #1 is flawed, and should not be his #1 priority.
---
Realize that the only real way to implement the proposed changes in Java3 is to provide a 'compatability' layer between prior versions.
This means it should be possible to install 'clean' libraries, or 'compatability' libraries.
I would hesiate to be too quick to move to Java3. as there are more than 10 aspects need to be tackled.
A difficult task in the real world of business and legacy. I hope it happens within the next 3 years.
I'm fairly proficient in C++ (it's been my primary language for years), and I'm more comfortable using it than just about any other language. However, while I would use C++ for a production application every time, I recognize the advantages of using Java for building prototypes and simple test apps. Between the much simpler library, thread support and garbage collection, you can really do a lot more in a short time without planning or worrying about memory.
A friend of mine said it best, when we were forced to use Java for a compilers class: Java is like candy. Meaning that so many of the details are taken care of by the language that it's almost effortless. You can do things quick and dirty, in a way you wouldn't in C++. Of course, all of that ease and sloppiness comes at a cost, and in some instances that's acceptable.
Besides, Java and C++ are so similar anyway. If you're comfortable with C++, there's absolutely no reason why you shouldn't be comfortable in Java. You might not be as proficient as a full-time Java coder, but you're not exactly going to be lost without a paddle. Going the other way, I'm not so sure.
This one is a no-brainer. Just about all of the real programmers I know remove deprecated calls from their code as they are encountered. If something has been deprecated, it was probably for a good reason. Leaving these things in the language only serves to build cruft.
9. Fix incorrect naming conventions.
One of the things that I like best about Java is the internal consistency; many times, I can guess the correct method to call simply because simmilar methods exist for other objects, Still, Harold is right; there are a few places here and there where imporvments could be made. Is it String.size() or String.length()? Little things like that should be cleaned up. It's still a far cry better than C++, but it could also be better.
8. Eliminate primitive data types.
I disagree with this one. As a semi-interpreted language, performance has always been precieved as one of Java's faults. There is no reason to complicate matters by promoting primitives to objects. There are some cases when this would be useful, especially when using the container classes, but I think this will be better solved by the "auto-boxing" of the upcomming Java release than by defaulting all fields to objects.
There is no need for primitives to have inheritance; they would almost certainly be final anyway, and providing them with methods such as int.compareTo(int) would just clutter mathematical code. I say leave them as they are, and box them as necessary.
7. Extend chars to four bytes
I can see his point; Unicode is getting huge. Still, I'm not sure justifies doubling the space every character takes up; perhaps a new unicode type would be better. Of course, to be of any use, String would have to default to this new type, so I might just be gull of hot air on this one.
6. Fix threads.
I'm not a thread expert either, so I'll keep my mouth shut except to say Java's thread support has been sufficient for my needs.
5. Convert file formats to XML.
I don't see any problem with this. As Harold indicated with his mention of XMLEncoder/XMLDecoder, Java is already moving in this direction, and since XML is becoming a de facto standard anyway, I say jump on the bandwagon. I would also like to see JEditorPane expanded to include support for an XML file format; if it was compatible with OpenOffice, so much the better.
4. Ditch the AWT.
This one gives me nightmares...I have a lot of GUI code laying around, and having to rework all of it...ah well, that's what weekeneds are for, right?
Harold is right, the AWT is out-dated and poorly named (there isn't very much about the AWT that can be considered advanced), and lacks the functionality for real GUI design. SWING can always be improved, but in general, I like what it provides.
One thing I do take issue with; converting JFrame etc to Frame. This might be more logical, and is what would have been done if AWT hadn't claimed all of those names already, but I like being able to hit the documentation and look at all of the Jbar, Jfoo classes and know that I'm seeing the SWING stuff.
3. Rationalize the collections.
Again, he is right in claiming that consistancy is important, but I don't see any reason to remove Vector or Hashtable; these are the only containers I use with any regularity, and most people coming from a C++ background will be the same way. If I spent the time to investigate ArrayList or HashMap more, I might convert, but for the sake of intuitivness, I still think that the Vector and Hashtable names should be kept if the classes are merged. Also, Vector and Hashtable are synchronized, ArrayList and HashMap are not. Thread safety is almost always nice.
2. Redesign I/O.
Ugh. Yep. I have never been a fan the way Java handles IO. Perhaps I was spoiled by C++. Perhaps it was just because I had no idea what classes I should be looking for when I was trying to learn it. In any event, I agree that File needs to be expanded to allow for real file manipulation, and that something has to be done to make sense out of all the streams and readers and writers laying around.
1. Redesign class loading from scratch, this time with human interface factors in mind.
Class loading, in usual cases, isn't a problem. I suppose it can get tricky when you start fiddling with CLASSPATH and packages and dynamic loading, but I really haven't seen enough problems with this to comment one way or the other. I've never encountered the bug he mentioned about Class A implementing Class B but not being an insatance of Class B because they were handled by different class loaders, but that at least should be fixed.
There are a few things I would also like to see done with Java:
Thomas Galvin
What about making garbage collection less of a lottery? I've heard a lot of people complain that certain J2EE servers (that shall remain nameless) can often sit for 30 seconds collecting all the garbage when they should be serving the application.
.net does this, and I think it's a very good idea...
Secondly, what about specifying some sort of jar/war/ear wrapper that encrypts the package and adds a pile of meta-data. How often have you looked at a jar and thought "Is that the one I built yesterday or not" ??? In a production environment this can be a big problem. Yes yes I know that configuration management can fix this problem, but if you are picking up a production environment that a just-gone-to-the-wall dotcom was supporting, the chances are you won't have a clue...I hear
Invoicing, Time Tracking, Reporting
Save your wrists today - switch to Dvorak
10 ) Ok, but what about moving to a better system where you can compile against a specific version. Try to compile agains 1.3 with methods that were depreciated and it will fail.
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.
10. Java 2 isn't big enough.
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.
Someone you trust is one of us.
I wonder whether encouraging people to switch to an incompatible java3 will just convince them to jump ship?
A few years back I made some java-based webpages for a science course I teach. I had been interested in the language, and this little (few 100 lines) application seemed just right for a test case. So, I took some cgibin code and started rewriting. The results were fine, in the end, and I thought that my time had been justified.
The next year I wanted to add something new to the code. Whoa. My old code no longer compiled, given java function renaming.
That was enough to turn me off Java. In several decades of programming (assembler, fortran, algol, PL/1, C, C++, ...) I've never had code written in one year fail in the next.
I've been told that I was just being caught in the "early adopters" disease, and that java now has now stopped making incompatible changes.
And then I read this /. thread. Oh my.
Java, VB and Windows is responsible for a whole lot of crappy systems out there. The more you spoon feed them, the more I-want-to-be-a-programmer-because-tech-is-a-good-c areer-option guys start writing code. And crappy code.
I suggest everybody just sticks to UNIX and C :-)
Stack-based bytecodes are fairly trivial to map to registers (google "register coloring algorithm"). Stack-based opcodes are a compromise for all the register-deficient machines out there (see x86). There are dozens of papers on the subject of mapping stack slots to registers.
I do agree with your point about most of the grievances about Java are library related. This is easily fixed by comparison to the design problems in the JVM itself: such as not having a proper data section in the class file format (look at the bytecode for array initialization sometime), or not having versioned jar files or opcodes that can run pointer-based operations in order to support languages like C. The JVM is not a great universal virtual machine for all computer languages. It is too Java-centric (no tail-recursion optimization for Lisp, no pointers for C, no continuation support).
Sure people are going to disagree over what is more important, but the fact these discussions occur in the expert groups regularly shows the community is open. Reguardless of who or what company invented the language, the more important thing is it include a process by which the community can drive its direction. Balancing the needs of all the users isn't an easy task and in most cases if much harder than writing the code.
Of all the suggestions in the article, this is the one I liked the most --- I've been paying some thought to this idea in general (i.e. not just Java classes, but anything that requires the notion of linking against libraries). I think what needs to happen is that something conceptually equivalent to a version control system for libraries be built, with a central master repository containing the "official" version(s) of things and per developer sub-repositories containing the latest versions of whichever libraries the developer was working on. As changes get committed into the main source tree, a periodic build process could be used to keep the main repository synchronized. Now linking becomes a fairly trivial matter --- the class loader checks the developer's personal repository first and then the master repository, favoring newer and developer versions of objects in its resolution. Now for the fun (and possibly less than useful) bit --- teach the classloaders how to talk to each other, creating a shared cache of those libraries used most often. This approach does have several major holes in it, not the least of which is how to deal with versioning, but I am all for trying anything that doesn't involve the current classloading scheme.
I can't agree with the dropping of primative types, since they are just so darn useful for graphics programming. But I wouldn't mind if the methods first depricated in JDK1.2 (Java 2, right?) were eliminated in Java 3. It would require a little bit of fixing for me, since I've used them for backward compatibility, but only an hour or two per program.
;P
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#.
people still program JAVA ?
Java is not better than C++. It may be easier for you to write your particular web-based business application, but that does not make it better in general, per se. Show me a good word processor and spreadsheet with all the functionality of MS Word and Excel written in Java. Show me a good browser written in Java comparable in feature set to Mozilla or IE. Show me a robust operating system written in Java. Just because you are not competent in C++ does not mean it is inferior to Java.
I am happy to see someone else has this logical view! :)
JVM is the most important. It must run beautifully!
Dear Bill, do you have a
Normally, when somebody says "Upgrade Java," I wholeheartedly agree. But what Harold (a good writer, two of his books sit on my desk falling apart) suggests is in many ways just foolish.
) ?
Removing deprecated methods may seem like a good idea, but a lot of the deprecated methods, Thread.stop() especially, are essential parachutes. If a thread stops responding in a manner that's untestable, or if it's within an anonymous class, you need that method...deprecated, dangerous or not. Similarly, making the language more long winded does not really help us. The appreviations in java can be counted on two hands, and they're all things we use pretty often. What's next, extending String.valueOf() to UnicodeTextualString.returnTheValueOfThisInteger(
Primitive types are nice to have around because they optimize sweetly and can be trusted as the the fastest part of an app. Relying on machine speed to clean up the bloat of using too many objects is what's going to make CLR kill Java in the benchmarks (that I guess we're technically not supposed to do anymore).
Ditching the AWT means ditching all browser support. NO! Furthermore, XML is not the darling of the planet that it purports to be. I like my tiny, efficient serialized objects; easily compressed and not very human readable. I don't want to conv to Base64 and serialize to XML. Why burn those extra cycles just for some ostensible "human readability" when no humans will ever need to read it other than those of us who understand deserialization?
There are so many things broken with java -- complexity of class structures, taglibs, the inconvenience of formatting and calendar classes, EJBs, stupid JDBC bugs -- I find it troublesome that Harold's biggest issue is the spelling of InetAddress. He knows damn well why it can't be InternetAddress...that's used in javax.mail.internet for a totally different task! He wrote the damn book that taught me that package!
Hey freaks: now you're ju
This design pattern is called Composition and gives you the same exact result.
No, it is not multiple inheritance, but you won't have m-i in java.
And why exactly would it not work?
Beside the fact that the syntax is not like you would like it to be? (no flame intended, just a question)
I'd rather be sailing...
I thought there was only one reason we needed Java 3: Three Times The Caffiene
I assert that my comment is only my opinion, not that of any employer, past, present or future.
C# and CLR
MI, Operator Overloading and Pointers mustn't be added to the Java.
-MI does not exist in nature. It is cheating to abstract some entities in an easier way. It simply does not work except for several cases.
-You can do everything you can do with Operator Overloading without using Operator Overloading. It certainly helps to reduce the syntax complexity of numerical applications, but, generally easy to abuse, or misuse by creating wrong semantical correlations. There are many cases, in which the "addition" operator for some entity may be defined with more than one semantics. In big projects, it leads to confusion, and hard to determine bugs. I had a problem with them, I know. Much better to not to have it.
-Once pointers enter into a language, expect memory leaks, dangling pointer bugs etc. By the way, on virtual machine based systems, you cannot implement dynamic languages, which contains pointers, and memory access.
Dear Bill, do you have a
The point is not that the JVM uses multiple processes, rather that the JVM may run multiple processes. ie. the ability for the same JVM to run (say) jbash and jls simultaneously. Thus you need one JVM per user, or per system. The apple shared memory approach goes a long way towards this, but externalises the memory and process isolation whereas a pure multi-process JVM would internalise them.
The java 1.4 vm runs 1.0 1.1 1.2 and 1.3 code, the 1.2 vm even runs 1.3 code! The bytecodes are not the problem, even a major change can be picked up by version number in the class file and a different vm called, it's the heavily bloated libraries that make java slow.
Using JIT, java is compiled to the optimal native code for any platform, thus making it (sometimes) faster than C code compiled for compatability on many processors. The problem is that the unused deprecated methods take time to compile from bytecode to native code, so each time a new object is created, it takes ages before it can be used.
Also all the unused methods take up RAM, with java's bloat memory is used up very quickly
As to getting rid of primitive types, think of RAM again! a byte primitive takes up a byte of ram, but a byte object (like java.lang.Byte) takes up the byte of it's value plus all the methods.
I think java 3 should screw compatability and just cut out all the deprecated/rarely used methods, thus making it faster and more portable (rt.jar - the core java library - is 22meg, but a fair chunk of it is never used, think of all the 56k AOLers!)
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
ERH makes some excellent points in the article, which happens to touch on a couple of issues I've felt is mediocre in Java, but moderately cool in the .NET Common Language Runtime - things that could do well in being transplanted into the Java language and runtime.
The .NET CLR, being a relatively recent creation has naturally gotten the benefit of 20-20 hindsight. Two area that it seems to do better than Java is of course, class versioning/loading and the issue of primitive types in Java.
For those of you who aren't familiar with C#, it implements it's primitive types as "value types" (as opposed to the familiar reference types we know and love from both Java and C#). Value types are passed by value (but can be boxed if you need to take a reference to an instance of a value type). The .NET CLR type system imposes some restrictions on what you can do with value types (I can't remember what they are offhand, sorry), but they enable value type instances to take up a very little space, making them virtually as efficient (time and space wise) as the "atomic" primitive types currently in Java. Would the introduction of primitive types as classes be so inefficient as other posters are claiming. I think not.
In the .NET CLR, you don't have no bloody CLASSPATH, but you do have two types of assemblies (private and shared), assembly probing (standard "protocol" for searching for dependancies of a given module), a powerful way of tweaking module loading through user-written configuration files, and a neat versioning model.
I highly recommend all haters of Java's class loading mechanism take a look at how the Microsoft people have done it. This is seriously good work.
MSDN: How the Runtime Locates Assemblies
Sorry...just need to clear something up...AWT stands for Abstract Windowing Toolkit, not Advanced as you seem to make out...just thought I'd clear that up.
:o) oh...the fun I have!
Personally I want the AWT to stay, at least for the time being. I sell a chat solution that uses a Java applet...with my own lightweight components, many people would have to download the java plugin to get swing and this is frowned upon by the kind of sites I work for...the customer shouldn't have to download anything at all to get it to work...it should just..."work".
I am NaN
Microsoft would like nothing better than for Sun to release a version of Java that isn't backwards compatible. That would give them two options:
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.
Isn't this what keeps happening with sucessive versions of gcc? We're already seeing binary issues with 3.1.x and 3.2 compiled programs, if Linux users are expected to suck it up, what's the difference?
Wu-Tang Name: Half-Cut Skeleton Get your own Wu-Na
First, I admit that Java is very cluttered. It was developed over a decade by hundreds of people at different times with different ideas.
>10. Delete all deprecated methods, fields, classes, and interfaces.
ok
but I will point out the gains are asymmetric.
Neat freaks have less 'cluttered' reference docs but some companies and programmers will have to rewrite their applications costing many, many man hours and dollars.
Maybe a better way would be make a versioned class interface, sort of the way COM does it.
>9. Fix incorrect naming conventions.
ditto
>8. Eliminate primitive data types
>This will undoubtedly be my most controversial proposal
It makes steam shoots from my ears like Elmer Fudd.
>computers are a lot faster and have a lot more memory than they used to
And I use it all! The cycles are mine! all mine...I am not giving back any just so the docs are shorter.
>Java would finally become a pure object-oriented language.
I am sick of Smalltalk fanatics raving how this or that is not 'pure' OO. Language Purity is like Communism, a utopian ideal that winds up causing mass destruction in its blind wholesale application because it does not work 100% in the real world.
>I simply want to make them full objects
Primitives as objects would at least double the amount of memory because the JVM would need the object reference as well as the value.
>Just as the statement String s ="Hello" creates a new String object,
>so too would int i = 23 create a new int object
This would increase the work of the garbage collector by a giant factor. Memory burn is a serious problem
int search( ) {
int i;
for( i=0; ione integer type that is not bounded in size, and perhaps it should be the default type
So basically we would have to do all math in software which is like 10X slower. That is what BigInteger and BigDecimal are for. They are rarely used because most applications will take the performance for the trade off of living within a primitive type data range.
This would also cut I/O speed in half because of the overhead of object construction.
The only place where this has any merit is the container classes. Primitive wrappers are a pain in the butt. Don't change the primitives, change the containers. There are only about a dozen of them. Rewrite them so that they can accept primitives as well as objects. I have several containers (BTrees, Quadratic Hash) I have written that do just that. It is not very hard to make it deal with a bunch of types rather then just Object.
>7. Extend chars to four bytes.
Only if the JVM can use a compressed 1 byte representation on the fly.
I am not compelled by the idea of being able to have musical notes in strings.
>6. Fix threads
Other then removing the deprecated methods, they seem alright.
>If these types aren't made into objects, then they need to be as atomic as the other single-byte types.
If your code relies on these operations to be atomic, no wonder you have problems with threads.
> (a single) object can have multiple monitors for different operations
This sounds like bad class design in need of refactoring. If the different operations truely did not interact and could have seperate monitors, you probably should split up that class. Anyway, it would be very easy to make several guard object members and synchronized on each one rather then on the implicit this.
This would be very hard to do and not buy you much.
> 5. Convert file formats to XML.
Ok.
but a lot of work for Sun for only a small gain.
> 4. Ditch the AWT.
Painful but probably a good idea.
> 3. Rationalize the collections
Ok
As I said in 7 collections should accept primitive types.
We also need parameterized types built into the language. Putting and object into a container and then casting it back to the correct type is a lurking time bomb. During run time you can get an exception. It is donkey work that the compiler should do for you at compile time. This was promised for Java 1.4 but got pushed back.
>2. Redesign I/O
sigh. Like AWT, IO is a mess (and too slow). It changes with every release so at least Sun is working on it.
> 1. Redesign class loading from scratch, this time with human interface factors in mind.
Yes! problems with the class path is the one of the most common problems people have.
Maybe a 'java registry'? Maybe make a bootstrap executable with all the class path information?
To the class loader and loading speed problem problem and its solution. It is rather easy and has existed before smalltalk. The solution is memory images. Smalltalk had this for ages with the result that those apps start in an instant and no classpath was needed ever. The problem with Java apps is not the startup time of the VM (about one second if at all). It is the tedious class loading class verifiying mechanism, add to that a non existent binary resource handler and you end up with 10 seconds startup time where 9 seconds are used for class loading verifiying and image loading for pictured buttons). Sure the class loading mechanism made sense in the early days when class files in applets were referenced directly since the evolution towards jar files it doesnt make sense at all. Id say ditch the jar files and movie to real binary images like Smalltalk and C# has. (Smalltalk had that for ages, dont they call this image generation, seal off?)
May I suggest to include SWT into next release, this GUI implementation is far more superior than Swing, much cleaner and faster. For more information please go to: www.eclipse.org
http://dtum.livejournal.com
The article is written by one of the most active Java book writers ever, so he's probably written about every aspect of Java and needs a version 3 to write some new books.
Java was designed as an easy to use language, targetted to the business user, NOT programmers. It was designed to replace, especially, the much missed and eminently useful dBaseIII+. ParadoxDos 4.0 also solved huge problems for businesses, neatly and inexpensively.
The author is complaining about all the gotchas. These languages are useless for a business. Most businesses just go back to file cards(!), the Windows 98/XP/2000 world just doesn't cut it. The only contact with J/JS is through an IE browser window, it'll never overcome that experience.
There's a huge sales opportunity here, I guess you don't have the temperament to take advantage of it. Sun has never produced consumer level software, and won't, StarOffice notwithstanding. Oh, Dr. Pauker, where art thou?
"Java was the first major language to integrate multithreading as a fundamental feature rather than a special purpose add-on library."
Obviously the man has never heard of Ada83. OK, they were called tasks instead of threads. They were still threads.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
removing confusing and unnecessary classes like StringTokenizer and StreamTokenizer
wtf? obviously this guy has never parsed anything in java. StringTokenizer is infinitely useful (though I must grudgingly confess to liking c#'s String.split(char[]) method). StreamTokenizer is much harder to use, but very helpful for parsing CSV files.
geez, don't throw the baby out with the bathwater. that includes leaving my primitives in place too.
reech bee-yond ur clip-0n
Of course it works, but it isn't at least what I would call the correct model (My opinion only).
..
..
Using the typical ISA/HASA comparison between inheritance and composition a flyingboat IS A plane and IS A boat. It's not an object that HAS A plane and HAS A boat.
Sure, you've created an object that works the same but doesn't really model the objects at hand.
try this call with the above:
class airport {
takoff(plane);
}
airport.takeoff(flyingboat);
it won't work real well.
Multiple inheritance is really my only gripe with java.
Well, I can't argue about your ISA/HASA comparison.
:-)
;-)
and for your airport to work with the composition model, it should only expect to receive and interface, flyable for instance.
Then your flying boat could implement flyable AND moveable. When you'll call takeoff, passing it flyingboat, it would call the method move or fly or whatever provided by the flyable interface.
Anyway, no need to both argue so much I think
I think we both made our point...
Have a nice day!
I'd rather be sailing...
with all the regEx stuff built into 1.4, I was happy when it finally started coming out of beta.
nothing you couldn't write yourself, but it is always nicer/easier if it is already built in.
as for the 10 points on that list, I have no issues with them, they wouldn't bother the programming that I do or have done, and making it all truly objects would be nice IMO
There are some odd things afoot now, in the Villa Straylight.
I skimmed your XML critique. One of the points worth making is that SOAP is not really an RPC protocol - there is too much baggage for that - headers, envelopes, etc. It is, funnily enough, meant for simple object access...
For RPC there is XML-RPC, which works fine enough. SOAP is more along the lines of moving data between objects. An example of this is a lightweight online client - validation and processing happens on the server, while interface niceties, user input and pre-validation happen on the client. Communication between the server and the client is as simple as if(isValid()) outputStream.write(toXML()).
I agree that XML is no silver bullet, but it does have a large number of applications in a variety of areas. High-load network communications just may not be one of them.
other than to sell a gadzillion "Java in Minutes" books? Which is the cart and which the horse here? Buzz words, media frenzies, etc seem to drive all 'advances' in computing these days, Java acceptance and use in particular.
When that sad day comes that I lie on my death-bed, and heartbroken throngs surround my frail and aged form, looking to glean what wisdom they may from my last words; and when one particularly attractive young acoloyte leans across and asks, ``O exalted master, what one thing remaineth a mystery to thee after these many years?'', twelve gets you seven that I'll reply with my dying breath, ``Why in the name of all that is holy doesn't Java have enum?''
(For much more on this, if you can bear it, feel free to check out my rant at http://zoom.z3950.org/bind/java/comment/enum.html )
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
m-a-j-o-r language.
Ada has nowhere near as much use as java. ever.
Everybody else is getting into the fray, why not me?!?
10. Delete all deprecated methods, fields, classes, and interfaces
Funny that everyone bitches at Microsoft for bloated software, but the same is not said of Sun and Java. This proposal reduces bloat. Sounds like a good idea. If you have an application written that uses deprecated methods (which you BETTER NOT have written while ignoring a deprecation warning! If you did, bug off, it's your problem!), you can either rewrite it or don't upgrade the JRE. Deal with it. I agree with him.
9. Fix incorrect naming conventions
Probably the least important proposal, I don't particularly care either way. I am quite anal in my own code about naming conventions and formatting, I have a very definite style that other programmer can recognize immediately if you have experience looking at my code (and they tend to appreciate it). So, why not do the same for the language and class libraries itself? I like this idea personally, but if it didn't happen I wouldn't be disappointed either. I'm ambivolent on this point.
8. Eliminate primitive data types
The idea is consistency: if everything in the language is an abstract data type, so much the better, you never have to even think about whether your dealing with a primitive or an object. I mean, there's been a couple of instances, as everyone has experienced I'm sure, where I had to deal with wrapper classes. Hey, that's not exactly a big deal. But then again, why not avoid it completely? I like this idea, but it's another I could live without, but I do lean to agreeing.
7. Extend chars to four bytes
Yes, excellent idea. Frankly I've never been bitten by it not being four bytes, but his argument is perfectly reasonable and makes total sense. I agree.
6. Fix threads
FIX them? How about make them not a total pain in the ass to work with! I've written multithreaded applications like most people have, and I'd rather do it in Java than many other languages, but I still have to think too much to do it (partially familiarity, true, but also partially because it's illogical the way it works). So, ANYTHING to fix threads is OK by me, I agree!
5. Convert file formats to XML
I agree. Especially in the case of serialization. I mean, if I serialize an object, nothing says I have to use it in Java again, I can pull it into anything down the road and deal with it. Yes, XML everywhere, I agree. (Now, if the hard drive manufacturers want to make a ton of money, wait until everybody IS using XML everywhere, then bump the prices of storage up. What choice will we have? And of course we'll need 10 times as much space storing everything in XML, so they'll be rich. Where's my Seagate stock anyway?!?) I completly agree.
4. Ditch the AWT
Don't ditch it, just combine AWT and Swing and make one good, coherent set of GUI classes. I like Swing, that's all I use for GUI work, but AWT still has things about it that are useful. Combine them and GET IT RIGHT THIS TIME!! I agree with him.
3. Rationalize the collections
Forget rationalizing them... cut down the number. Just give me one or two collection types that encapsulates all the functionality of the others. No reason this can't be done. That would fulfill his wish of rationalization as well, assuming they were designed properly. So, I agree, in a manner of speaking!
2. Redesign I/O
I hate to agree since it's been what, two revisions already? But he's right, there is basic functionality missing or poorly implemented and that shouldn't be the case after seven years. I agree, grudgingly.
1. Redesign class loading from scratch, this time with human interface factors in mind
Yes, the class loader needs to be fixed. Not so much because of the newbies with class path issues, but for efficiency's sake mostly. I agree. Oh, by the way, don't be too hard on the newbies... honestly, how many of you got Hello World to run the very first time? Don't lie, I doubt more than 50%!
How to fix Java is an argument that could go on for ages, but at least this guy had the balls to come up with some ideas, and even proposed solutions in many cases. At least give him credit for that, even if you completely disagree with everything.
By the way, I view Java as the lesser of all evils... it doesn't thrill me, I don't love it and I grudginly use it now, but there isn't anything better that I've seen (.Net has potential, but it's not sufficiently different enough to warrant a wholesale switchover). So, until something comes along that blows me away (like direct nueral programming where I picture a GUI and the functionality thereof and the code for it is written for me), I'll just bitch about Java like everyone else, and continue to use it daily.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
I love Java's simplicity, and wouldn't mind to keep it as it is (although I WOULD adopt the proposed changes for Java 3), but the following is what drives me nuts: Three COMPLETELLY different ways to get the length/size of things:
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...)
When CL deprecated things, it did so by creating a new default top-level namespace (a "package" in CL terms) and leaving the deprecated stuff behind. The old namespace and the new one shared most symbols, so old and new stuff could coexist, but in general deprecated stuff would be flagged and had to be specifically requested for it to work.
CL is in general not case-sensitive, so it ducks the properStudlyCaps problem. CL names have always been unabbreviated except for a few historical symbols.
Never had 'em.
The exact size of the char datatype is not part of the CL specification. Implementations can and have made it bigger over the years, and programs that care can check at runtime if the implementation has big enough chars for their purposes by making a specified environmental inquiry.
Threads aren't part of the CL language. Every major implementation has them, though, and all of them are easier on programmers than Java's threads (see here - scroll down about halfway to "You can't close over anything but final variables in an inner class!").
Always had S-expressions as a default universal file format. See my
CL doesn't have a specified GUI. The closest thing it has is CLIM, which had a lot of the speed and resource problems Java GUIs have. We had them ten years ago, though. The commercial CLIM implementations are quite useable these days.
CL's collections have always been rational. It mostly comes from #8 above - when objects are typed and variables are not required to be, most of your problems go away.
CL's abstract interface to filesystems and pathnames has always been less Unix-centric.
I gather a lot of his complaint here stems from the distinction in Java between an interface and a class. This distinction is there because of the Java designer's allergy to multiple inheritance, which CLOS has had since day one.
There, have I pissed enough people off yet?
To a Lisp hacker, XML is S-expressions in drag.
10. Delete all deprecated methods, fields, classes, and interfaces.
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.
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. 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.
It's 10 PM. Do you know if you're un-American?
Decouple monitors from objects? Yeah, it would have been nice if it was that way from the start. The easy way to avoid most of the problems that arise from it is to use private synchronization objects in your class implementations.
Thread groups? That was an attempt to deal with thread scheduling issues. POSIX threads has some of the same issues. Both it and Java have to deal with having to be implemented on different platforms with unknown scheduling capabilities. Unless you are on an IBM mainframe, everything seems to devolve down to darwinian scheduling and you'd better get used to its consequences and cope with it.
Joe Seigh
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 should have predicted this! What is it about generics advocates ? You never quit harping on about this even though generics have been repeatedly rejected by the JCP.
Java needs Generics like a People need holes in their heads. They are pointless, cannot be added without badley breaking the VM, they add nothing except complexity; produce code bloat, break type safety and are hated by the real OO experts, because they are a crutch for people who do not understand polymorphism.
I'm really forced to wonder about the motivation of people who want to so badly break Java.
- Virtual Machine
- Language Specification
- Supporting Libraries
The biggest problem with all of these is that Sun alone owns the spec. I doubt it would be possible for highly motivated individuals to try and "fix" any of these items (as in Open Source project) without Sun legal getting their undies in a knot. Sun at minimum shot themselves in the foot by not submitting all of the pieces that make up Java to ECMA or another recognized standards body. Like it or not, this is where M$ will pull ahead with C# and CLR - even though they are everyone's favorite Evil Corporation.Anyone who has taken a deep look at the the JVM has to question its design (exercise left to the reader). It's interesting to see how the JVM's CISC-like, non-orthogonal instruction set has been perpetuated by one of the leading RISC vendors (perhaps it's not really RISC anymore these days).
The language itself has lots of holes - realizing of course that nothing is perfect. Primitives in Java are messy at best. I hate having a million get() and set() methods to follow the supposed JavaBean "pattern". Why not support something like Properties in C#? Generics? Coming Real Soon Now. Unfortunately the bureaucracy and lack of timeliness in the JCP leaves someting to be desired. A quick reminder: How long did it take to get simple assertions added?
I could easily get over some of the bumps in the JVM and language spec if the standard and extended libraries had some god's-eye view design applied to them. No one but Sun can touch the java.* packages, and javax.* is under their thumb as well.
What rocket scientist thought of java.awt.List and java.util.List? (perhaps no one at Sun ever works with Collections and GUIs at the same time). java.net.URL is a first class citizen, while URLs in other places (such as JDBC connections) are simply Strings. Sure, these are minor details, but they reflect a lack of maturity at many levels - and as they say, the devil is in the details. I won't even go into the monster that is EJB, since that to me is a lesson in how to make the simple very complex.
Bottom line is this: Java has its flaws, many of which can be lived with. But Sun having a stranglehold on the spec is a serious deterrent for anyone (beyond Sun) to step up to plate and make a difference. It's quite sad, since Java is the least of many evils out there in terms of building software in general, and I would love to see it mature well and eventually succeed.
So, anyone want to redo this the right way, free of Sun's shadow?
Why have a strong compiletime typed language, when you just throw it all overboard using casts? If you want a scripting language, use perl, python or whatever...
Using collections with java means generating a new wrapper class for every collection. _Very_annoying!_
it seems to me that this is just a product of the language itself and the way it was created, but do i really need to create another object just to return an extra value from a method?
QED
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
If it was open source we would already have multiple versions of Java and they would all be incompatible with one another. You would have the neat freaks going with a version of java that has the articles fixes, and would completely ignore backward compatibility (Because after all were going to do RIGHT this time!), you would also have the hacker crowd who would make Java++# that would include pointers and remove garbage collection and also make it incompatible with existing code. (Because they are making it RIGHT as well).
In a few years the language would be forked just as bad as C.
Thank God Sun hasn't Open Sourced it.
That can't be a good philosophy, can it? I think we've all been shorn of the starry-eyed naivety that had us chanting ``write once, run anywhere'' way back when; but doesn't ``write once, compile anywhere'' still seem like an eminently attainable goal?
One Java is enough. Maybe even more than enough.
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
int i = 23 as in his example would, if I understood correctly, make a construct like i++ impossible. How would a for loop work? This doesn't quite make sense to me - maybe you'd need both mutable and immutable classes for the primitive types?
Energy: time to change the picture.
Maybe I've missed the boat on Java (chime right in and say so, we know you can) but I've seen Java as in part one of the most significant book-selling computer technologies that has ever existed. Almost from the beginning, what Java 'meant' was that there were going to be tons of books, many of them horrible fluffy hype, about Java. I know it's gotten better as Java has slowly become usable for more than dancing screen doodles.
So here we have an article: '10 Reasons We Need Java 3.' Written "by one of the most active Java book writers ever." Clearly he needs Java 3, because without cycles of obsolesence, how's he going to make his boat payment(s)?
On his suggestion of removing AWT, you can't, at least completely. Swing is built on AWT. On another note, anybody ever try to do multithreading with a Swing app, you get some interesting results and Sun doesn't recommend doing it. So really you could remove it from the public API docs, but it'd still be under the hood (like many com.sun classes)
On his suggestion about modifying the I/O classes, true buffering is important for performance reasons on most applications. However, to me the way the Java crew implemented I/O is genius and its patterns based. You construct the exact tool you want by stringing together lots of simpler tools together. Yes it would make life easier for those who aren't comfortable with this approach, but at that point why not bastardize it completely and go back to a C style fopen() function.
Incidentally, I wouldn't mind seeing a revision to the RandomAccessFile class in that it does behave a bit like the C-style fopen(). I don't know how you'd improve it, but it would be nice if it was consistant with the rest of the I/O classes.
Finally, on file access, while I haven't done a whole lot of Java development on Windows or Mac, I've got to believe that a tree based file system can address all of your file access needs. Granted you might not be able to do something like new File("C:\\WINDOWS\\"), but why couldn't that be represented and accessed by "/C/WINDOWS/" or use URL style syntax. Perhaps it already does and this is his gripe. This sort of reminds me of my experience of using Perl on VMS. You could access the VMS filesystem using either the native syntax or a UNIX equivalent.
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
Todays trend in our industry is to obsolete as much as possible with each release..
This way you can 'regain' customers that were quite happy with what they had.
Hard to sell new product on meaningless 'features', soooo just 'force' people to 'upgrade' everything..
Then make it all pay per use during that upgrade process.. the holygrail... income forever..
---- Booth was a patriot ----
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.
The fact is that it is not Java that is broken, but the common perception of what is actually needed, and this very o'reilly article shows that clearly. It is not possible to "fix" a language just by removing bad API and generalizing its ad-hoc constructs. It is mind which needs fixing.
:-)) There is not reason to neither fix or drop anything in it; just push for better implementation and more standards. But if you feel like looking for something true and ethernal, try objective caml, and implement a java bytecode compiler for it.
One might say Java is secure. It is secure in terms of JVM, but it is broken in terms of typing, and it is funny to see this skipped in the article. For example, collections are not type-safe.
One might think Java is reliable. Yes, its object model forces people not just to implement things, but also to someway "declare" what they are going to do. But "enterprise programming techniques" are mostly about overcoming this, for they use "reflection", which is about overcoming type restrictions.
Java has born templates. As somebody already noticed, templates are means to secure job, for nobody else will be able to figure out what's the hell is going on in your code. It's a joke, but the actual reason why templates are bad is that that they are a hack: Java is not expressive enough to let people develop abstract algorithms.
People are used to OO modelling. That's good by itself, but the common practices are harsh. Everybody knows that virtually any UML guy is capable of producing tons of completely incomprehensible diagrams, incomprehensible save to him. By programming, we build a computer model of the problem we solve. Since people generally dislike abstractions, it is considered more useful to have the world totally modelled than to have as much abstractions as possible found. So, just to add two integers, objects are created, and messages are passed. Nobody even tries now to teach programmers think abstract.
Let me make a conclusion. It is not because Java is good by itself that it has gained so much, and not because it is convenient lots of people are forced into it. It is because it is really a sort of agreable common ground (And it is better than VB anyway
Noone (or noone significant anyway) thinks the
primitive types should be layed out in memory
the same way as object types. The argument is
that they should be semantically the same,
but implemented differently. Thus, if I
want to take the sine of a number, I can
write:
(6.0).sin()
Rather than:
Math.sin(6.0)
Which involves the nasty, irrelevant class "Math". You should also be able to subclass the primitive types. Furthermore you can remove the length and precision limits on the various types. Integers should be stored as 32-bit ints where possible, and then gracefully degrade into big ints when they exceed 32 bits.
The technology to do this already exists. Lisp and Smalltalk VMs have done it for years. Unfortunately, the developers of Java got confused in just the same way as you're doing.
Comment removed based on user account deletion
I dunno. Breaking compatibility is always dangerous, but eventually you have to erase the mistakes. You can still write code that uses the 1.0 event model and uses all of the deprecated classes/methods.
People managed to catch on to java 1.0 when there was no compatibility to anything else. People are catching on to C# because of it's syntatical/conceptual sililarities with C/Java (and the the mammoth marketing budget). With this in mind, I don't doubt that you could make "Java 3" that scraped off some barnicles.
Generics are well on their way. They keep getting held back from actualy inclusion in the VM, since in practice their absence is just an irritation, but the standard is already signed off. C++ templates are a pretty poor example of generics anyway. It has been done much better elsewhere.
You don't really explain why you think the primitive types are necessary, so it is hard to answer you, but the fact there is no common supertype of the primitives + Object is a complete PITA if you do anything complex in Java. Just look at the JDBC interfaces for an example. The need to promote and demote primitives to get them into collections is a major source of inefficiencies in Java programs.
Just to avoid any misunderstandings: the point is to give the primitives object-like semantics, not to store them in the same form as other objects, or to require people to use object-like syntax. The technology to treat primitives as objects has existed for Lisp and Smalltalk for years. The only reason it hasn't made it into Java is NIH syndrome.
Another thing he missed: metaclasses
Flame on. I know you want to.
1) Plenty of languages that do what Java does and in many ways better (Perl, PHP come to mind)
2) Ivory-tower design plagued Java for years. Still today it's very hard to control external processes or work on "real life" entities like the file system. The shell language can do things that Java can't.
3) Even with primitive types handling of data in Java is cumbersome compared to other languages.
4) The JVM is really an attempt on rewriting an new OS. We have an pseudo-OS on top of an OS. Should we focus on writing useful software instead ?
5) Speed might have improved but Java is still one of the most memory-hungry languages out there.
6) Elliotte has written a lot of non-sense starting from the first book I reviewed at the timeof the release of Java 1 and he still continues. Proposals like 4-byte char and use of XML everywhere are the clear demonstration of the ivory-tower mindset of some Java people. It's about time we forget about these jerk-offs and start writing software that is usefull, optimized, and to the point.
There are easier ways to claim how well hung you are, you know...
That would be why the JCP is working on a standard for them ? and why there is an implementation mechanism (type erasure) which requires only a small change to the VM ? and why 1.5 is slated to include them ?
...
Hmm
Is that it sucks for client side apps. MS was the only one working on improving it, albiet for their OS only, and Sun put a damper on that. Now Sun wants every windows user to switch to their VM which is many magnitudes slower then the MS VM. Moreover their VM is extrememly bug riden. Upgrading to Java 3 will porbably only make things worse, as performance has actually gone down with each subsiquent release. And for all you Mac guys out their touting their cool VM, its a shame it doesn't fully support java, missing things like Java 3d classes. Unless someone produces a much better VM designed to improve client side performance I predict client side java will die in the next 5 years. Its to bad since it would be nice to write an app that works on all platforms. And the whole applet scheme under all of the various VMs is just that much worse.
My two fathers and I are having orgies every night! It should be hard for your mom, but she looks like she is able to handle three cocks. Lucky boy! ; )
Dear Bill, do you have a
... in Java, because it is statically typed. Where code is not polymorphic, and manipulates the primitive types directly, it would be possible to use full-precision numbers, as supported by the hardware, just as Java does now. Something like C#'s automated boxing and unboxing could be used when the primitives were assigned between a polymorphic and a non-polymorphic context. That would answer the performance concerns with needing to distinguish fixnums from reference types, and still give fully OO primitives.
I find myself quite dubious. I don't particularly like the Sun license, so much so that I haven't even been updating the current versions of Java. (I'm hoping that Python or Ruby will expand to fill the spot where Java currently resides.)
Sun hasn't given much sign that it intends to improve it's licensing. McNeary's recent comments seem to inticate that it may tighten up on it. And the current license is already a bit much. So I don't think any new version would be attractive. I'd rather trust Miguel's version of C#, but I have this suspicious mind that keeps hinting that MS holds patents that will sink either it, or large portions of it.
I think we've pushed this "anyone can grow up to be president" thing too far.
nt
Dear Bill, do you have a
His points 4, 6, 9 and 10 are only about ditching deprecated APIs and not about "incorporating the advances in the last 7 years".
Point 8 is really stupid. He writes:
and Is he on drugs?Points 2 and 3 are the only ones I agree with, but they don't require a Java 3, that is not backward compatible.
And in point 1 he writes
All in all, this guy seems to be a complete idiot. How comes he writes Java books?The generic classloader is slow. Java is not particularly slow.
Look at the effort needed to implement a new GUI layer.
Look at what eclipse is doing with SWT.
Ask yourself why they're going to the trouble.
The answer is that the GUI layer is slow, the logic layer is (reasonably) fast.
Why doesn't Sun work on it? They don't care anymore, what's selling for them is (non-GUI) server code so they are (rightly from a business perspective) concentrating on J2EE, not J2SE (which is a lot of what we're talking about).
Most of these changes are for the programmers' sake. The author seems to have forgotten that the point of programming is to satisfy users' needs, not to amuse programmers.
Java falls short of user's expectations in at least two areas:
1.) Performance. It's still too slow overall and the Image classes are incredibly inefficient.
2.) The UI sucks. It's easy to make a crappy UI in java, but it's basically impossible to make a good UI. The File chooser/open/save windows are pathetic. There are all sorts of little nuisances in the widgets. There are no good UI tools for java like microsft has for c++.
The next version of java should focus on the user's experience.
...Number 1 reason for Java 3... Needs to make some more money from another book.
The Kruger Dunning explains most post on
What about good ol' functions? Even many OO fans agree that "sometimes procedural is the right choice for a particular problem".
"system.this.that.print()" is a Demeter Principle violation anyhow.
Also, get rid of the "break" statement, instead allow multiple match items.
Table-ized A.I.
This article is a waste of time. All he is suggesting is minor semantics when he should have addressed more important issues. I believe Java needs to address the garbage collection issue a lot more aggressively. If you want to develop an high-performance server-type application, and if you come from a C background, you want the ability to immediately free memory, not just mark it ready for garbage collection. I guess coming from a C background, I inherently don't trust things that say, "OK, trust me, I promise to free this ASAP". We have transitioned some of our applications to Java, but the biggest hurdle we have consistently come up against is memory management. Memory tends to blow out really quickly, and it makes us nervous. Even worse, Java begets lazy programming where programmers code without any regards to memory management, making it hard to go back and fix things even if a better memory manager were implemented. They have designed themselves into a corner for that one.
"Remove Thread Groups" - These things are used for security in applets. A thread must be in the Applet's thread group for you to modify its properties (priority, name, etc.).
"Eliminate primitive data types" - This is just plain stupid. Why create an object to use as a for loop counter? If you want to use objects for all of your primitives, go right ahead, use Float and Long, etc. Personally, I prefer to get something in exchange for giving up efficiency, and Object oriented utopia doesn't cut it.
"Drop all depricated stuff" - Why can't this stuff be phased out slowly. What's with the shock treatment? Why not get rid of all the 1.0.2 stuff depricated in 1.1 now and, when most people have adopted 1.2+ vms, we can start to make the other changes. Either way, what's the big deal? If we take them out of the docs, will that be enough? Don't say "in the interests of efficiency", not after the "eliminate primitives" thing.
"eliminate 1.0.2 event model" - Well, I can't argue with that.
"replace all data formats with xml" - Mighty fashionable, but if you try to pass serialized objects to an earlier VM, say from a 3.0 server to a 1.1 applet, you will also have to pass along several hunded K of parser. I suppose we could use comma sep instead, but since my StringTokenizer is gone too, I don't know what to do.
Most of these suggestions are good, but I see no reason to leap into them in one version. Backward compatibility IS important. A lot of coders "don't get that depricated means don't use this in the code you are writing now", but people who code this way deserve what they get.
How about built-in fault tolerance, distribution, and concurrency (and no stinking dependency on pthreads). Which are all available in a language called Erlang :).
C# is basically Java without a lot of the annoyances. (Unless of course you consider Microsoft itself a major annoyance..) For instance boxing/unboxing primitive types, get/set blocks for attributes (the getXxx/setXxx convention in Java is a little klugdy, imo)...a foreach operator ... enums ... delgates (like "function pointers")...other stuff..
Basically Microsoft did the usual microsoftish thing, they looked at what's available, ripped it off, and changed the bits that they thought were annoying.
I must say after reading some C# books on O'Reilly Safari I like C# a lot more than Java and am looking forward to 1) a C#->native code compiler for linux and 2) a C#->Java bytecode compiler (it must be possible).
The author is right, in spirit (even though I don't agree with every detail). Java is starting to look a little crusty. I believe the reason Java took off so much in the beginning was because people were desparate for a "better C++". Now as time goes on we need a "better Java", as we search for that elusive "perfect language"..
In a lack of it I have to use Kawa and suffer from performance.
Less is more !
Templates are called generics and available as an extension to Java: GJ. This implementation (or at least something very similar) will probably be included in a next version of Java.
BTW. If you are a member of Sun's Java Developer Connection (free), you can vote for the features and bugs you want them to work on. Vote for Generics! Of course, sharing memory between JVM instances is also a good feature to vote for. It has been proven to be possible already (MacOS X' JVM), so they just need a kick in the ass.
The Drowned and the Saved - Primo Levi
without a way of stopping Microsoft from throwing old and incompatible pseudo-JVM's into their browser, simply to fuck with the developer community. First they take it out, then they throw the wrong version back in. Bah.
This time around however, I'd like to respectfully point out (as many other posters already have, although they've been mostly modded down as trolls) that every single thing this dude wants Java to do is already in... wait... C#.
Actually, I think this article was quite the exercise in hipocrisy. For every single point made in the article he could have added "C# already does this" at the end. I'm sure he came up with all those insightful recommendations thanks to a visit from the Angel Of Languages, instead of from intalling and using Microsoft Visual Studio.NET for a few months and reading the ECMA spec for C#. Yeah, I'm sure that was it.
Microsoft created C# (and .NET) to compete with Java at the enterprise level. I think it's obvious they're succeeding when one of the "leading voices" of Java cries out and demands the very things that are built into C#.
I actually hope Sun (yes, everyone here loves Java so much despite the fact that it is a language controlled by a single company, like... wait... C#) does all this to Java. That will make it a much more level playing field. But alas, they're paralyzed by the need to have backwards compatibility, which is important regardless of this guy's acid dreams. No company, not even Sun would risk their current user base to clean a language up. Sorry!
Sounds like most of the author's complaints have been addressed 20 years ago, in Smalltalk. Now maybe if Gosling had done his reading.....
Talk Small and Carry a Big Class Library
Adding object semantics to primitive types doesn't have to slow things down, C# seems to do it fine. Having separate int/Integer types is a hack that produces ugly and inelegant code, and should be removed.
Ditching the AWT means ditching all browser support.
Why? I've run Swing applets in browsers, they worked just as well as AWT applets (which is not very, but still). I actually prefer native widgets to the one-size-fits-all Swing widgets, but Sun disagrees and I don't think they need to expend resources supporting two completely (well, mostly) separate UI libraries.
I like my tiny, efficient serialized objects; easily compressed and not very human readable.
And not interoperable with anything else, and prone to breakage with new versions. If you're concerned about size, gzip your XML data and you'll get close to a 90% reduction.
He knows damn well why it can't be InternetAddress...that's used in javax.mail.internet for a totally different task!
Classes in different packages can have the same name, e.g. java.util.Date and java.sql.Date (although I'd argue that's also poor naming).
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Java 2 was Java 1.2. Java 3 is Java 1.3. Sun released Java 4 a while ago (Java 1.4).
;0
Solaris 9 anyone? Oh, right, 2.9...
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Onto the XML question, and getting to my area of pet hate: The XML Silver Bullet.com. The author's bias towards XML is understandable, but he needs to realise, as do the millions of developers who let the marketting machine think for them, that XML is a poor implementation of a decent idea.
Of course XML is a silver bullet! JARs and properties files are just the beginning. What we really need is for the .class files to be nice, readable, XML documents. This will pave the way for .java code to be written in a proper XML format. There is no reason that these things need to be written in an ugly properiety format.
My apologizes if my sarcasm is lost.
I'm not a smorgasbord.
It's not that Swing apps don't work in a browser -- more than Swing apps will only work in a browser under certain conditions which are not easily met by average anonymous user X.
Maybe in a year or so, when all those XP homes have downloaded WebStart and/or NS 6.2+. Until then, I need my AWT to make fancy wavy backgrounds in my shout out pages.
Hey freaks: now you're ju
There is a much better way. Objective CAML and other ML-like languages have parametric polymorphism. Objects by default are never optional. If you want an optional object of type Foo, then you declare it as Foo option. 'a option is a polymorphic data type. The type parameter name is 'a. The type value of the type parameter is Foo in this example.
This way, the compiler can enforce that the non-optional objects are always present.
Parametric polymorphism buys you a lot more, of course, but the NPE's are the most irritating thing about Java I'm aware of.
Unlike most other programming languages with parametric polymorphism, Objective CAML also supports object-oriented programming.
I normally never do this ;)
You hit the nail on the head:
From the article:
The non-atomic nature of doubles and longs is a sop thrown to architectures that can't efficiently do 64-bit operations. That's not nearly as much an issue today as it used to be, however, and few VMs ever took advantage of it. If these types aren't made into objects, then they need to be as atomic as the other single-byte types.
What he seems to be missing is that longs and doubles CAN'T be atomic on some (4 byte) thread capable processors.
long a;
a++;
Will be non atomic on 4 byte processors. In the case of 0XFFFFFFFF, it first becomes 0X00000000 and then as a second operation checks the overflow and becomes the equivalent of 0X0100000000. If a thread switch occurs in the middle of the a++ and the new thread references the variable stored in a, there is a possibility of getting a value 4 billion off of the value that should be stored in there if the function performing this operation was synchronized.
Solution: lock longs on every operation. Yuck. Just what Java needs, more overhead on numeric operations.
Question: You point out that Java uses native threads but then complain about a lack of a thread scheduler. Aren't the two incompatible (some kernels hide thread scheduling details)? Would you really want Java to emulate threading as a method of creating a thread scheduler? Also, for single processor systems, thread emulation is fine, but multiprocessor systems don't lend themselves well to emulated threads for actual performance. How do you reconsile the two?
Network Security: It always comes down to a big guy with a gun.
An Array is not an object. You merely are accessing a data field in its structure which is R/O. How is this hard to understand? Is is hard to understand that a vector is multidimensional (unlike a string), so its size, not its length is what you want? It makes logical sense to me.
As for the data types, if you don't want to mess around with the "dirty details," stick to pure Computer Science languages and scenarios. In the RealWorld(TM), you write code that deals with things. I know you want to do things in less code, but it's about working smarter, not complaining about working harder. Write a class which does all the nitty gritty in an easy-to-use interface, and use only that interface. Make it generic and useful, and you'll be able to re-use that object in all your projects.
As an example of working smarter, take Glade. With it, rather than spending 5-10 lines of code laying out and initializing a widget or part of a widget in a mega-huge init call, I can simple create an xml description file that also has the names of the callbacks for each widget. Then I just write the code to handle the call backs, and include one call that loads my template and populates it. The same is true with PHP. Why should I include hard-coded strings everywhere, when I can load a template and just ereg_replace all the escaped variable names? I can work alongside people using Frontpage or Dreamweaver, and I need never tear my hair out because of it.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Autoboxing is of debatable utility - see this critique.
Because it's less efficient in a man-hours way.
You can sit down and write out a native code output setup for "common" machines, but then you've just gone and wasted a lot of effort for a sub-2% performance increase (assuming you can duplicate the OO latebinding arbitration and garbage collection any faster in "native" mode without a supporting runtime like the JVM). Each native output compiler would take at least as much man power as the one which outputs the code for use with the JVM. And then you'd need to write some sort of runtime library which duplicated the JVM for the functionality I mentioned above.
So rather than spending thousands of man hours working on that, why not wait until 18 months from now when your code runs 200% faster? The tiny little "god" of performance is tempting, but don't go towards it if it means sacrificing all the gains from computer science in the past 20-30 years. Assembler is fast, but no one uses it except in device drivers and careful cases where it's found to be more beneficial than doing it in a higher level language.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
See the "Petilon" critique.
Personally I think they're pretty even, which is something of an indictment of MS's strategic planning.
What do you suggest for distibuted computing if not XML messaging in some form? IMHO, there is really no way that a C++ developer is going to be able to communicate with a remote Java application except by passing XML. The Java RMI protocol is hard to implement in another language (it serializes exceptions and pipes them across to the remote client in a non-obvious way). I don't know enough about CORBAs model to comment, but opening a socket and sending strings (with inline XML schemas to verify against) is straighforward for all languages. Building your own parser for anything sucks, but there are XML parse libraries freely or cheaply available for any programming language. Also, XML messaging is convenient because you can upgrade a server to provide extra information / functionality without upgrading clients: just spec that unknown tags are parsed and ignored. Also, most XML parsers don't choke on malformed tags. If you write your own protocol using a home brew format, specing that kind of stuff is a real pain in the ass.
Network Security: It always comes down to a big guy with a gun.
Sounds like he is re-inventing C#.
/g
But forgot the most for powerful feature of C# -
Attributes, which allows you to do things like XmlSerialization with no hand-written code. I think Attribs will improve the way we write DB clients.
If you want to see an example, go see Example4, listing one.
It's also annoying he never mentions the term "boxing" and "unboxing" when he talks about turning 'ints' etc into objects. Sometimes you can borrow a page from your competitors' vocabulary.
Also - how about adding the following C# language features:
A) foreach(Type t in mylist){...} to prepare ground for templates
B) tailcall IL instruction to allow Prolog etc
C) System.Windows.Forms for a fast windows kit
(goodness, IBM had to invent their own AWT replacement to create eclipse IDE)
D) enums which can be flags, which can be or'd together
E) events + function pointers ("delegates" in msspeak)
go mono!
A special syntax since it acts very much like a structure. And, as the Sun docs state, "Arrays are supported directly by the Java programming language; there is no array class. Arrays are implicit extensions of the Object class, so you can assign an array to a variable whose type is declared as Object." There is no class to implement the length member like the original poster wanted. Implicit isn't quite the same as is, IMO.
"Not messing around with "dirty details" is one of the goals of almost every language."
One of the goals, yes, but that doesn't mean you don't sit down and work with them somewhere. Smart programmers abstract it away, as I suggested to the original poster who stated that he hates mucking about with the primitive types. Based on how he was complaining about it, I don't think my suggestion that he abstract it away was at all off base.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I guess I was bashing a square peg into a round hole :) Using templates around hetergenous data structures makes a lot more sense than what I thought they were for.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
The Java Developer's Journal can be found here: http://www.sys-con.com/java/
Unfortunately one needs to pay a subscription fee to access the archives. :(
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Look at the discussions of compiling Perl which uses the same "byte code running on a virtual machine" mechanism. The compilers evolve with the expectation of the virtual machine. As a result the byte code compiler isn't really doing anything more than adding a copy of the VM to a comiled byte code and making some of the links "harder". There is almost no speed gain and there is something of a memory loss.
In Perl you have the worse problem of "evals", so Java should be easier. What I tend to doubt is that you end up with any real performance boost.
Python in/under Java is known as JPython, and apparently there is also an implementation of JRuby underway. There are already several implementations of Scheme and of Smalltalk too. Caveat emptor: I've not tried playing with any of these myself - with the exception of JPython.
You can find a comprehensive list of alternative langauges for the JVM at http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
Productivity always depends on the developer's preferences. Personally, I don't miss GC at all when I'm programming in C++, but I find it crippling to lose basics like enumerations and templates in Java. I'm quite happy with a language that doesn't hold my hand, because I adopt programming practices that mean my gun isn't loaded so I can't accidentally fire it. YMMV, of course; that's why there are so many languages in wide use.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
.
- First they ignore you, then they laugh at you, then ???, then profit.
I think it would be a great idea to "clean up" java.
:-)
However, I disagree with almost every single idea the guy has about 'clean'.
Basic types like 'int', should STAY in.
Char should stay at 2 bytes. strings are bloated enough already, and we dont need explicit klingon support
XML is a bloated pig. I thought the object was to REDUCE bloat, not increase it. So converting configs to XML makes no sense as 'cleanup'
and lots of other things that I'm wondering what the heck went through his head.
10. Obviously better to keep them for people who actually write code, not just lame articles
9. Already being done, again protecting people with investment in code.
8. 'cause java is too fast now, right ?
7. see #8
6. I don't know what I'm talking about but I know they are broken (very insightful) see the jsr and doug lea's website
5. Already being done
4. Lets get rid of a usable low level interface beacause there is one I think is cooler.
3. Already being done. Josh Bloch is on the case, think this guy could do better ?
2. A couple of minor points
1. Not a trivial problem.
The article doesn't even mention parameterized types, which are already implemented and on the way. The jsr's go way beyond what he discusses. O'Reilly used to be good, looks like they are going downhill.
But it doesn't mean merging is necessary, or a good idea at all.
C# solved the "boxing" and "unboxing" problem its own way, and I guess that's what inspired the author to propose the merge, but I don't think that's the simpler, best solution for the language.
It is my inexperienced opinion that he pointed something better (from the point of view of a programmer that wants to know when he's dealing with primitives or with an object) when he said it wouldn't be much more complicated than the + operator for String:
- Why not "overload" the arithmetic operators for the container classes?
This would be part of the merging process, but it would be 95% of what's really needed, and I'm still trying to figure out why they did it for String and not for Integer.
I can still now that "int a" will be forever an int primitive, and "Integer b" will forever be an Integer object, and will still get a compiler error if I mix them up... but "a + b" will give me sensible results.
The other 5% of the "need" for merging comes from Collections and their use of Object. But I still don't see why this should force us to turn everything into Objects.
Why not solve this with convenience methods in AbstractCollection and/or static methods in the Collection/Array classes?
Static methods would probably imply less work and be a bit more consistent. Static methods for adding large arrays of primitives (and retrieving them) from a Collection solve many of the Object/dichotomy problems.
The problem is that a method for adding/retrieving individual elements does not "belong" there. Collections.addInt(Collection c, int a) would do the work but reads a bit awkward.
Since most of the trivial common work for a Collection is already on the AbstractCollection, having some primitive-oriented "get" methods (like in JDBC) would be feasible and perhaps sensible.
My main gripe with this would be that I'm not sure this should be a change in the Collection interface, so as to not make it annoying to implement from scratch. But probably it should.
Freedom is the freedom to say 2+2=4, everything else follows...
Moderation Totals: Flamebait=1, Insightful=2, Overrated=1, Underrated=1, Total=5.
Moderation is a joke. The only mod point missing here is "funny" which is what this posting really is. All the "features" enumerated here were deliberately left out of Java. It wasn't Java anymore if they were implemented.
You guys are really having a linguistics dispute not a computer science dispute. You are using two different definitions for OO programming. Something like:
1 - A type of program where all functions are class methods and all data is bound within classes.
2 - A philosophy of design emphasizing encapsulation, polymorphism and inheritance. .
However, there's already a mechanism for this, and one that he mentions in his first point! Stuff in 1.0 that's been deprecated since 1.1 can surely be removed with very little impact: responsible developers have had several years and 3 major JVM versions to fix their code by now. If people need to run code that old, they still have the old JVMs to run it on as well.
And most of his other points can be solved by deprecating existing API elements and providing alternatives. The old ones will still work for the time being, and developers can get busy adapting, so in a few years the cruft can be removed. That's what deprecation is for, after all!
Ceterum censeo subscriptionem esse delendam.
There is absolutely nothing wrong with using RTTI, including dynamic_cast, where it's appropriate. The issue is that while dynamic_cast is actually a very clean feature since it has a built-in test for whether the cast makes sense, other casts (particularly reinterpret_cast, if you like C++ terminology) coerce data in an unnatural way, and that is a recipe for bug soup.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The ultimate list is at: http://www.jwz.org/doc/java.html. It's the ultimate reference. Much better than the O'Reilly article IMHO.
there's no place like ~
The 390 machines use this not for performance, but actually for security. Each transaction uses a fresh JVM heap, so there is no possibility that errant code might mistakenly (who, me? hehe) read something is shouldn't, like the previous transaction's cleartext user info.
nick (i believe this post is past the SAT, the Slashdot Attention Threshold, hehe, lesse if anyone reads it)Of Elliotte's laundry list, only the IO and threads issues really resonate with me. But I would like to add my own:
All Java-platform packages shall be specified as interfaces, and come with reference implementations (set of concrete classes). The reference implementations are pluggable.
Many packages are already implemented that way (JDBC and JDBC drivers, servlet API and server containers, etc). Restructuring UI, logging, messaging, etc, to follow the same approach would be useful, IMO.
just as a side note, it's note the same as telling the GC to explicitly collect, but you can often assign an object to null to 'help' the GC along. Again, it's not the same, I know, but it can help the GC finish faster and maybe the act of doing so on a large enough object could kick off the GC.
just a thought
I am a pretty experienced Java developer, this is my own list:
Garbage Collection: When it takes place and how long it takes is very nebulous. I have heard MANY people say that Garbage Collection CAN be done well, but it isn't done well in Java now. Try running a webserver with a lot of threads, when you get low on memory force a garbage collect - be prepared to wait. You need more control over garbage collection, the ability to run it in the background, the ability to set time limits, do partial cleanups, etc.
Replace BOTH AWT and Swing: Swing is broken. In each new version something stops working in Swing, it is overcomplicated and buggy. If you want to have some fun get the 1.3 source and read JInternalPane, you can find about 20 obvious bugs with ease. AWT and Swing are very inneficient. Whenever you add something to the AWT Hierarchy it generates all sorts of events, updates the cursor, etc etc. The layout managers are a mess, about 3 people on earth understand how BoxLayout works. Why isn't there a vertical equivalent of flow layout? The XUL Box container is easier to understand AND does more than most of the AWT/Swing layout managers. The way they interpret alignment, pref/min/max size and other variables changes with each layout. Things like KeyEvents are also a disaster. Swing is over-engineered, its too complex to understand and to make work properly.
Meanwhile AWT is buggy as well, and full of deprecated and just plain odd methods. There are obvious bugs in things like targeting mouse events, focus management, etc. (Which changed in 1.4 and is not compatible with 1.3!)
Classloader: This is one that many people may not have experience with, but is a big problem when you are running say a webserver. The same class loaded by two different class loaders is considered 2 separate classes, just with the same name. They don't share static variables, for example. There are also a lot of conflicts when the webserver uses a package and your program attempts to use a newer/older version of the same package.
I'm not an expert on the subject but it needs to be fixed or modified somehow.
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.
I've read the arguments against checked exceptions, but I must say that I find them very useful at development time. I like the fact that the compiler makes sure I'm not leaving any edge conditions unhandled.
Now, if it were just a flag passed to the compiler to enable this checking, I could live with that.
-----
Kvetch is Yiddish for "throw an exception" --Dr. Ron Cytron
I think Sun might want to take a look at incorporating aspects into java 3. AspectJ does okay as a preprocessor, but if it were a feature of the language, you could write aspects that affect library code as well.
-----
Kvetch is Yiddish for "throw an exception" --Dr. Ron Cytron
one is in the actual language, the other is simply in the compiler. If the desire is to forget about backwards compatability all together, then why not just call it a new language. Then it would be easier to justify a complete overhaul. After all, ifyou are going to redo something without compatability then you are free to fix all the problems known without the restrictions and hold backs of a least common denominator.
1) XML and serialization
....
.... he is not a programmer.
... yes, ask questions. But do not claim the classpath is wrong ... you expect a newbie to read a XML config file where pathes are configured? A classpath variable is definitly much easyer to get!
... why? ... but thats not a reason to ditch stuff.
... well ... probably they should be fixed.
... and the problem with threads is not having a suspend() or a resume() method. The problem is designing an application multithread save or better multithread friendly. Thats not a problem off some methods or not, its a problem of education for the developers.
... so you rely on runtime optimization.
.... there is a basic difference in concepts between primitive types and objects.
.... no one knows ... its a philosophical question wether they are IDENTICAL or only the same valus (do they reffer to the one and only 1 in the universe?)
... const and not const, identity versus equalness ... that all is to question.
.. not values). But then you have a different kind of language.
... never needed XML.
Why should the serialization format be XML?
Well, he is the author of "XML in a Nutshell", thats why.
When I serialize an object I only open a file and use an formatter(ObjectOutputWriter) to write an object into that file.
When I deserialize an object I open a file and use an ObjectInputReader to read it back.
I simply have no touch to the file format, nor do I care about the file format and even if it was carved in stone, I would not care. There is absolutely no reason to change the serialization format.
2) Class loading
No single topic is as confusing to new users as the class path. I get almost daily e-mail from novice readers asking me to explain the "Exception in thread 'main' java.lang.NoClassDefFoundError: HelloWorld"
What is so complicated in understanding how a path varibale works? All shells use PATH, even DOS use a varibale called: PATH
The CLASSPATH works exactly the same. If a so called programmer does not understand the fundamentals how a computer, a OS, a shell, a program and finaly a language is working
Read some books, learn something
3) Ditch AWT for Java 3
Oh my godness
No one uses it. Why to ditch it and rework the stuff relying on it? Sure its somewhat obsolet
4) Fix threads
A self called non thread expert says that. Yo
However I like them. I never did thread programming before I used Java
5. Eliminate primitive data types.
It definitly makes sence to automaticaly wrap ints and doubles etc. into their appropriated object type when needed.
But the claim a compiler allways can deside wether a "1" should be treated as an object or as a primitive type is wrong. A compiler can that only do with a gloable view on the class it is compiling, and not localy on a method base. Further more: this is only suitable for a class view. The gloabl view over all classes is not possible in java. Its far to easy to get a object of an unknown type via RMI into the JVM wich treats an int just in the opposite way
The solution (short sighted from my side) is to allways use objects and to rely on JIT compilation and HOTSPOT optimization.
However
Objects have an identity.
"1" and "1" are two different objects.
1 and 1 are
Its a hughe difference if you pass a 1 in a method call or an object which can be used as a 1.
Call by value versus call by reference
Yes, you can say: I like to have all numerical values to be objects(arg
Its far, far more important to include contracts on a language level (not only an assert keyword), templates and probably even range checkled pointers(I dissagree here but James Coplien is in favour for them) and probably even to include more
higher levle OO concepts directly into teh language. Like composition, mixins or even support for declarative design patterns.
angel'o'sphere
P.S. I use for all things I need property files
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Java 3 is here: download at http://www.python.org/
Code poet, espresso fiend, starter upper.
I completely disagree. GC is a helpful tool in some circumstances, but no more than that. It doesn't revolutionise programming, or cause some magic shift in coding style. It's just a tool, and only one tool in a very full toolbox.
How often do you think I actually write a manual delete in my C++ code? (Hint: I haven't written it more than once or twice in over a month, though I've refactored and extended about 2,000 lines of code in that time. I think I might have used new half a dozen times, though.)
Why not? It is basic programming technique in C++ to write in such a way that you don't have resource leaks. (NB: That's all resources, not just memory -- a big advantage over Java's GC approach, which only guarantees any protection against memory leaks.) The fact that probably 90% of C++ programmers don't do it doesn't mean it can't be done. This is where the experience tells.
I have several years of programming in C++, and hundreds of runs of PC-Lint, Purify and other similar tools, to support me on this. I don't think we write code without leaks, I know it for a fact, because I have magic tools that shout at me if I screw up.
So does correct programming technique. Why do people not understand that GC is almost irrelevant to C++'s memory/allocation model? You use basics like automatic variables, references, smart pointers, container classes and the RAII idiom, and that class of bugs just vanishes in C++, too. C++ programs simply do not need to be vulnerable to resource leaks, buffer overruns, etc. It's not rocket science, it requires reading and understanding one good book. As I said, the fact that probably 90% of C++ programmers haven't bothered to read that book doesn't make it wrong, it just makes them lazy. The other 10% of us routinely write code with no resource leaks.
And yes, it is true that when writing low level code, probably for a library, you would want to put diagnostics in to catch logic errors. It's also true that this costs a modest amount of development time. But then, you'd do that in Java, too. (You do put in checks that your class invariants aren't violated and so on, right?) Compared to the cost of prolonged debugging exercises, and given the tiny fraction of overall development time that is spent adding these diagnostics, the effect on developer productivity barely even registers on the scale.
Quality is free, or pays you back with interest. C++ provides the tools to write very robust code -- and far more of them than Java, at present -- and the more experienced the developer, the better able they are to take advantage of those tools. It's really as simple as that.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Elliot's scheme will only benefit underemployed tech writers and consultants (such as him).
He's wrong about one thing. Vector was designed to be thread-safe, but it isn't. Check out this method in Vector: See it? The method is not synchronized, yet creates a stack-based copy of Vector's elementCount member. So, after elementCount-1 is calculated and pushed on the stack, but before the method calls lastIndexOf, the current thread could get suspended and another thread could run and change elementCount. Ooops.
Of course, I agree with his solution. Get rid of Vector and use ArrayList instead and do your own synchronization if necessary.
I didn't know we needed Java 2!!!
Use Python - it rocks!
on that whole list.
good:
move jdbc to javax
bad:
remove primitive datatypes
pointless:
everything else. Like removing a whole 22 deprecIated classes will do anything. Like a few "improper" naming conventions affects anything at all. His only other gripe is "java runs too fast on modern computers."
try{ Once and for all. Two issues. Crime : My customer doesn't want to upgrade JVM version. Punishment : Well stick sharp pointy things into a voodoo doll of your customer. If you are lame enough to develop using M$ tools, then the installers would install hundreds of finicky dll's updated. And usually ask the user which one he wants. Verdict : If the damn user wants to damn well upgrade their damn software, they can damn well upgrade the code you wrote and the code others wrote, and damn well understand that the jvm is an integral part of your product. Crime : I don't want to break backwards compatibility. Punishment : Wake up idiot. Verdict : Firstly, The new components would not be written with backwards compatibility. They wouldn't stop people having older JVM installed, nor would they remove all ability to run the older classes (i.e. the existing classes would be in there, or perhaps an optional download). Your argument about borland 6 is pathetic. That is like saying, why would someone embrace Java, if their C programs won't compile. By definition, something new has no backwards version to be compatible with. What I would like : Java 3 (we could call it java 1.5 to really confuse people, because 3 is above 2, so its 3/2 = 1.5 =) Maintains the existing great core classes - adds the cool optionals, for instance, isn't it history that all version 3 of every game was 3d? Fade to Black (Another world 3) Prince Of Persian 3(D) Lemmings 3(D) ok you get the point, Java 3 would have the Java3D API within it. Yippee! (read below for why that is so cool!) Also, IBM's excellent work and support for java would be integrated as they work together to integrate a better AWT (using SWT concepts, but making it run at a useful level on something other than windows...*cough*cough*) And then!! Create a dazzling new foray into GUI design with the sweetest collection of lightweight components, truly extensible, with no serious design problems, perhaps they could make the classes easier to extend, as this would make Java not only a viable option for client development, which it already is, but make it the only one you should consider. In short: Java 3 Java3D libraries (all 3D web content via applets! finally one standard for the web!) Update core libraries Implement a new AWT/SWT (call it SET - Standard Environment Toolkit ?) Which runs on all major platforms. Using the latest thinking in HCI, build a set of lightweight components ala swing over this new toolkit, and make them easily extensible. This would be the major area of compatibility breakage, but as 1.2 broke away by including swing as standard, 1.3 will include the next phase. }catch(UserDisagreesException ude){ throw new InvalidArgumentException("Well what do you think?"); }finally{ System.out.println("Hooray for Java!! We love Java!!!"); }
I'm not a C++ coder, but there's one feature that does give me language envy - the ability to specify parameterized types.
.Net CLR at http://research.microsoft.com/projects/clrgen/ which suggests that the feature would have to be added to the runtime, not just the language.
As I understand it, just as I can have an array of foo objects, with compile time type-checking for any getting or setting, I should also be able to have hashMaps, vectors or any other collection and specify the collected type when I instantiate the collection.
There's an interesting article on adding generics to the
for (Int i=aObj.n-1;i>=0;i--) { aObj2.receives(a.Obj(i)); ... } is imperative, obsolete and deprecated.
... }
the new OO-stype would be:
Iterator it = aObj.iterator();
it.setDirection(Iterator.LEFT);
while (it.hasNext()) { aObj2.receives(it.next());
JCPM
C# is a serious competitor for Java. Its designers have looked at Java and tried to make something better. With the advantage of the latest technical insights they surely have a chance to replace Java.
So Java needs to be updated to the newest technical insights. For end users this will make no big difference: the new runtime will know a "compatibility mode" where you can run older versions. Their only problem will be that they hveto download that newest runtime. But I guess that the compiler will have an option to generate code for Java-2 as well.
The real pain will be on the programmers who will have to adapt parts of their program.
I just went through metamoderation, and I noticed this comment had not only been modded up, but had a lot of people arguing with him... the fact that it's an anonymous coward is irrelevant, but the fact that he linked to a non-existant study (actually it's a link to "From the Source: A Talk with Open Source Advocate Danese Cooper") and he specifically highlighted the words "ugly skank 4-eyes ho" in his comment.... man you guys should at least LOOK before you leap into the flamefest =)
Geoff "Mandrake" Harrison
Some Random UI Hacker
What is also annoying is that they're all bad names. They're all nouns, when methods should generally be named as actions. The correct naming should be getLength() or getSize() !
Like their own standard is stating...
I'd rather be sailing...
Java (as if a person) seems to want to avoid many mistakes of the past, like allowing too many problems... yet its solution is to NOT allow anything at all that could lead to this (within the context of memory pointers here and generalizing of course) Fix the framework, THEN add pointers. Provide a consistent and smooth abstracted method for use, then people can forget the option is ever there, but add optimization and tricks if they so choose.
Why not address this issue first before either saying "Yes, we will continue to not allow these things" or "Sure, lets just throw that schtuff back in!"
Like with physical activity... if you get hurt, then you should not just stay innactive for a long time, rather find other ways to stay in shape. Your exercise (i.e. physical therapy) could in fact help you heal even faster.
We could introduce new features with and create our own api's and library components and give it names like swing2 and keep the old ones for compatability. I think puting addons may be the only option or perhaps creating some free compiler extensions to get the jit to do other things like making native executables and adding .Net support. I believe the source code is available to sun's jit so applying custom patches is possible. I Hate to say it but java 1.4 is already incompatable with java 1.3 in many area's so this might not be a problem.
C++ and C evolved by aditional libraries and api's that were added by various vendors and users that eventually became standard by ansi after they were widly used. I know stl has been around in Borland and Microsoft as well as At&t's compilers years before the ansi commitee ever even standardized it.
I noticed that many developers think any components that do not belong to sun are proprietary. Even if they are free! Perl on the other hand has cpan which there are hundreds of add-ons that are available. This is why Perl is so popular. I believe Sun must free java in order to save it.
http://saveie6.com/
Right now, there are glaring problems with just about every language in existence. Mostly, they fail to combine both power in the underlying programming model and a clean and safe syntax to use that model. Thinking about all the languages I know, pretty much every one could be vastly improved in at least one such basic area.
OTOH, some languages Get Things Right(TM) spectacularly in a particular area. Perl's regular expression handling provides a powerful implementation of a widely useful feature in a pretty straightforward way. Pattern matching and enumerated types in ML provide an elegant solution to many common situations that would require reams of polymorphic twaddle in most languages. The sort of power and clarity exemplified here should be the standard, not the exception.
Programmers today are sufficiently familiar with the basics of common paradigms and idioms that they don't need to be held back by old syntax any more (hint for C# there!), nor should each iteration of a language forever be held back by the mistakes of its earlier incarnations (hint for Java 3 there!). Old code obviously needs to run, but then that should be run against a suitable compiler/JVM/whatever. Holding new development back for compatibility's sake is exactly the reason so many languages today are just syntactic sugar for the same weak underlying models.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
<?xml version="1.0" encoding="ISO-8859-1"?>o perties>
<!DOCTYPE properties
PUBLIC "-//Sun Microsystems, Inc.//DTD Properties File 1.0//EN"
"http://java.sun.com/dtd/properties1_0.dtd">
<pr
<generic-property property-name="foo" property-value="bar"/>
</properties>
<!- -
This supplants the legacy Java 2 properties file, the contents of which would be:
foo=bar
I should probably use a namespace, and although there is no hard and fast rule about capitalization of names in properties XML file elements (the W3C has a proposed formatting rulesheet to be incorporated in an XML schema that includes the entire DTD in CDATA sections, using xpointer to external entity references. We suggest using XPath an XSTLT to translate the document, we suggest mixing __camel-Hump with dashes and preceding underscores.
-->
(6.0).sin()
Why does the notation for a method call with no arguments (foo.bar()) remind me of Forth's postfix notation?
If the Java team introduces a way to call a method on two objects at the same time ({foo,bar}.baz() instead of "should it be foo.baz(bar) or bar.baz(foo)?"), watch out.
Will I retire or break 10K?
why not wait until 18 months from now when your code runs 200% faster?
Because I want to release my code before the United States Congress goes and (expletive) up federal law so that I can't release my code.
Will I retire or break 10K?
C++ (which I also program) isn't exactly portable.
C++ is portable. However, C++ does not specify a GUI layer.
You can use a GUI toolkit such as Qt, GTK+, or the one Netscape Communications developed for the Mozilla project. Any one of those will work on BSD, Linux, UNIX®, Mac OS X, and Windows systems, covering (100-epsilon) percent of workstations in home and business environments.
That is, unless you're talking about running on multiple embedded systems, with completely different video architectures, some of which run slower than 20 MHz and have less than 512 KB of RAM.
Will I retire or break 10K?
The biggest difference between the two languages is that Java manages some things for you (garbage collection, etc).
Thus forcing you to wait 18 months for hardware to catch up if you're writing a soft-real-time application such as a video game or a media player. And on some fixed platforms such as game consoles, you have to wait five years for the next platform.
Even worse, with the current legal climate in the United States of America, if you don't get your program out NOW, you may never be able to release it because the government might ban it as a terrorist tool, or Microsoft might refuse to sign it for use on Palladium PCs because it competes with a package Microsoft sells.
Will I retire or break 10K?
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.
But then you say...
If I was asked "what is the most harmful programming construct", I would choose type casts every time - yes, even over gotos and pointers.
Without typecasting, you can't have quick'n'dirty serialization. Without quick'n'dirty serialization, how can you write a device driver? Without a language that can express both application logic and device drivers, how can you write an application for an embedded system?
I guess you haven't written any real-time demos or games.
Will I retire or break 10K?
OO-ass
TIP: "Assembly" is abbreviated "asm" to avoid any sexual connotations.
This is asm.
This is ass.
There are too many developers out there who will read [some sarcasm about creating a programming language in XML] and say "That is such a cool idea - I'm going to do it right now!" ...
Except they've already done that. Witness XSLT.
<sarcasm> Heck, Scheme code is made of S-expressions, and XML markup is isosemantic to S-expressions, so why not make XScheme? </sarcasm>
Will I retire or break 10K?
I tend to disagree with claims that primitive types should be taken away.
and additional wrapper classes should be present:But regardless of that, integer (byte, int, etc.) types, both primitive and object-wrappers, should receive their unsigned versions - currently there are only signed ones. So e.g. C style following declarations should be possible:
When coding my own base64 encoder, I had to do lots of bit-juggling that wouldn't have been requred if I've had unsigned types in Java.
Come on, I just spent a full year developing
an java web application. Wouldn't be a
great idea to start all over again? People
need time to reap benefits from old stuff
before moving to new stuff. Backword
compatibility is must.