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!
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
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
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).
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.
Well, tell them to get fucked and go and read the Java tutorial then!
Hey, it's hard to figure out the classpath! You need to take the dots and change them into slashes, for crying out loud! And never forget the classpath is relative to the base directory! my head hurts... *sob*
Beware: In C++, your friends can see your privates!
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
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
One point he mentions is making the class loader better -- but he doesn't know how. Amen! I hate the fscking class loader!! :-)
So much for proof reading. :)
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
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
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 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#.
10. Get rid of deprecated methods - don't be an arse, ruins past compatability with no benefits.
people shouldn't be using deprecated methods anyway...that's why they're deprecated, becuase they may not be supported in future releases...this makes perfect sense...
Eliminate primitive data types - oh yeah, please let me do x = new Int(1) + new Int(3);
did you even read his explanation??? from the article: "The new byte, int, long, double, float, and char classes would still have the literal forms they have today. Just as the statement String s ="Hello" creates a new String object, so too would int i = 23 create a new int object."...the way you use them wouldn't change at all...in fact this would totally eliminate the need to create new Integers, Doubles, Booleans, etc, when you wanted to put primitive things in lists, hashmaps, etc...that's a big pain now...
"Facts are meaningless. You could use facts to prove anything that's even remotely true." - Homer Simpson
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
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
>>Really there's no overwhelming reason the primitives can't remain as built-ins. They just need to behave in the same way as objects.
What do you mean in they have to behave like objects? So do they become garbage collected like regular objects? Can I serialize them? How about extend them? How does the equals() work?
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.
RTFS (statement):
There is a domain of usage suitable for any given language. To a lot of people, Java is far better than C++ in the domain in which they work. You even acknowledge this.
Java cannot be applied to operating systems because it does not have the syntax or functionality to control hardware with the required precision. Java recognises that by providing JNI.
Office suites and web browsers represent a huge amount of code investment - something only one company (Corel) has been willing to risk given the infancy of Java at the time. Were MS, Corel, Lotus etc to start on a level playing field right now, with all their knowledge, and expertise in the language of their choice, but no existing code base, the choice of technology (out of C++ or Java) would be a very interesting question; but my bets would be on Java to deliver a robust solution in a shorter time. The primary factors holding Java back for these applications are the performance issues in Swing, and the poor integration with the platform look and feel.
Actually, this is CONTRARY to a basic rule of software engineering, which is that the best tool for the job is the one you know. No team can deliver a robust, quality solution based on a platform with which it is not familiar.
That said, I am an experienced C++ and Java programmer (amongst others), and work extensively with cross-platform products in both languages. Each has their place, but for every application where the requirement for stability has outweighed the requirement for speed, I have found Java the correct solution.
Even where speed has been a tantramount consideration, there has been a cost benefit in using a Java implementation (shorter development cycle and quicker time to market versus more expensive hardware).
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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
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
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.
You must not have done much work in C++ or C. The K&R C to ANSI C transition broke many of my programs, and C++, well, all I can say is that I remember having to make changes to my C++ code almost every time a new compiler version was introduced in the early 90's.
"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.
Waltz, nymph, for quick jigs vex Bud.
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.
Please read the SOAP specification. It was born out of XML-RPC, and developed (amongst others) by the same author. Its initial and primary focus was remote method call, which is merely RPC in an object environment.
While it can be used for asynchronous notification, the specification deals mostly with the request and response case, where an identified function is invokved on a server and the invocation is provided with supplementary data (arguments), while the client waits for a responses which can contain arbitrary data (return value, possibly an object or structure) or out of band return data (and exception).
SOAP was intended to kill XML-RPC, and to add functionality over and above XML-RPC (such as callbacks / notification). It is still an RPC mechanism at its core.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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?
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.
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.
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.
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.
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.
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
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
... 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.
...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.
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"..
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
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
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.
> The K&R C to ANSI C transition broke many of my programs
Uh? Many compilers had a switch which allows you to stay in compatibility mode in K&R.
-> No need to modify the programs.
As for the C++, there are some compatibility modes but I'm not surprise that you still had to make modifications: this language is really messy.
C++ is not a Microsoft product, and hasn't changed a bit with the release of Visual Studio.NET. Microsoft's implementation of same, which they now called "unmanaged C++", also hasn't much changed (but can't use most of the useful bits of .NET, either). Microsoft's .NET-friendly version, "managed C++", is just another syntax for the C#/VB.NET combined entity, with all the same limitations (no generics, MI, etc).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Think Linus: All the unices were unfree or could be incorperated into unfree products without giving anything back to the community. Linux created his own unix kernal from scratch and distributed it under the GPL.
Microsoft created a Java work alike in C#. Someone will eventually create a Java worK alike and GPL it.
If voting were effective, it would be illegal by now.
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.
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.
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.
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...
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 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)Microsoft's browser support running the JVM of your choice. I've been running Sun's on I.E. for years now. You do the same things with your Java apps that sites did for years when they posted Acrobat "to use this site you'll need...".
Floats are easy.
You can only have one period in a floating point number, so you consider every number with a period in it as a double, and treats the second period as a serperator.
The following compiles perfectly on C#:
5.5f.ToString();//Float to string
5.5.ToString();//Doublt to string
As for the reverse, it's not String's place to have convertors in its interfaces.
Each and every type should supply its own.
On C#, it's as easy as:
int a = Int.Parse(some_string);
--
Two witches watched two watches.
Which witch watched which watch?
Java has no assembler level instructions to do port IO. It also doesn't provide you with direct memory access - which goes beyond alloc/free as you need to control the descriptor tables which define memory protection. Then you have the problem of handling interrupts (not only hooking them, but masking and unmasking, which on most architectures as CPU instructions), etc.
Without JNI, you can't hope to achieve any of this. C/C++ allows you to "drop down" to asm at any point, in such a way that the asm is compiled into the final object code. Java has no such functionality.
It *may* be theoretically possible to create a Java kernel on a system built specifically for that purpose - by allowing hardware control (IO, memory protection, interrupts) via memory mapping; but I still think you'll find you need to run a microcode interpretter on the CPU to handle garbage collection (amongst others), and a class to provide direct memory access to the mapped regions -- neither of which could be expressed in "pure" Java.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
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.
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.
Under Java it's even easier that that:
Just remember to catch the NumberFormatException.
FWIW, String isn't the right place to do data conversion -- you'll have to change the String class everytime you want to add another data conversion for another type. Java already does this the way it should (and so does C#). Sure, the code isn't as 'pretty' that way, but you keep the information where it's supposed to be: with the data class, not with a representational storage class.
We call it art because we have names for the things we understand.
The difference is this: do you want to create an object and throw it away, or not? Your way creates a new object and then immediately throws it away; my way doesn't. That's a pretty expensive operation ... much more expensive than try/catch. If you want to parse numbers from strings without having to worry about catching exceptions, write a static method in a utility class.
>>but you keep the information where it's supposed to be: with the data class, not with a representational storage class.I do not understand your terminology. Please give a definition of what you call "data" classes and "storage" classes.
String has been overloaded as a class: it serves two purposes. The first is to store strings, and the second is to store string representations of other types of data (numbers, XML, whatever). When used in the first sense, it's a data class; when used in the second sense it's a representational storage class - it's storing a representation of the data, not a directly useable instance of the data. It's the difference between 5+4 (9) and "5" + "5" (55).
My point was that the String class should know how to manipulate strings, but it shouldn't know about manipulating numbers stored in string format.
We call it art because we have names for the things we understand.
> String.valueOf(5.5f);
.NET/C#.
>What interfaces? String already has valueOf() functions for all primitive types.
That is bad coding practice. It's nice and easy, but it's not good to do so.
The reasoning? Simple.
Why you have String.valueOf(Int) and not String.valueOf(SomeCustomClass) ?
Using this method puts the responability for translating the object to string representation in the hands of the String class. It should be the responsability of the objects to supply it.
String.valueOf() shouldn't exist.
Or should exist in this form:
string string.valueOf(object Obj)
{
return Obj.ToString();
}
The above won't work on Java, because of the primitive system it uses, but it would work just fine on
You are going to argue that this is (probably) possible in Java, with one method for object, and overloads for all the primitive types.
The problem here is when you want to add a new primitive type, say Complex.
You *can't* do that without adding a new method to String, and to any other class that wants to be able to handle all types in Java.
> If my String idea was used you could write it:
> int a = some_string.intValue();
This is even worse, mind you.
There is no justification for such an abomination in the interface.
This has *no* place here, it should be, as it is, in the Integer class.
--
Two witches watched two watches.
Which witch watched which watch?
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.
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?