> I would ask James whether the lack of Multiple Inheritance > in Java was because it was hard to implement, or because > he wanted to protect programmers from themselves.
I kind of touched on that in this interview a couple of years ago:
He doesn't quite answer your question, but the impression I've gotten is that leaving out full-blown multiple inheritance was an Occam's Razor decision. He tried to keep things as simple as possible, leaving out features that many people felt were already mainstream -- such as enums, operator overloading, full blown multiple inheritance -- unless a sufficient noise was raised from the masses about implementing it. I myself would have preferred to see a well-designed enum and operator overloading, but I have been able to live without full-blown multiple inheritance without missing it at all. Truth is, I've been able to live without enums and operator overloading too now that I think about it.
Other things, such as design by contract, he left out because there wasn't a clear well-agreed upon way to do it. He had a design by contract kind of thing in there for a while, but stripped it out before a release deadline. He had a properties thing in there, like C# now has, but he stripped that out because his users turned their noses up, and we ended up with JavaBeans naming conventions for setting and getting. In one of the interviews he expressed regret at having taken that out.
That's the funny thing about design. You need to be humble enough to listen to users and be very receptive to their needs, but you need to be strong enough to say no a lot, and arrogant enough from time to time to say yes even when the users turn up their noses. Design is a kind of leadership.
I'd ask him if he thought Java could have done more to support Component Oriented Programming in J2SE. We have EJB on the server-side, why not something equivalent for J2SE. Some people dislike EJB, so imagine whatever kind of API pleases you :-) Avalon might be a guide, but it would probably involve something like the explicit notion of a component, a component manager, means to configure environment, means of packaging, the notion of "component scope" for source files etc etc.
And once you ask him if Java _could_ have done more, ask him if Java still can or will :-)
Programmers seem to lack a "literature", a collection of open source example applications serving as widely-used models worthy of imitation. Do you agree? If so, what could be done about it? Could Sun provide a means for evaluating and publishing such applications created by others?
I would ask James what he thinks about having Sun lead so many of the core API changes, such as NIO and JMX. Many in the community are not asking for many changes to these APIs. Should Sun include more outsiders to help make these APIs appear at a more complete level?
And, related, what part of java.io does he like the least?
There is no doubt that the Java team has tremendously improved java over the years.
Java team is great in creating a marketplace, creating great specifications that could envy even Microsoft. Even after 8 years of Java's existence in the market there is always a feeling that Java is far behind in the desktop arena. Java is still not preferred for developing rich client applications.
Yes iam talking about <b>SWING</b>. On should accept the fact that Java is lacking in the performance of rich client applications.
Swing may be a technically superior API but practically <b>SUN</b> engineers could do very little to make java as the desired language for Rich Client applications. There is a ready example in the form of Sun's <b>Net Beans</b> where the performance of the IDE is not upto the mark.
There may be several reasons for the lack of Swing's performance but let us not discuss that.
So my questions are :
1. What is SUN doing to improve the performance of the swing, so that it can match the performance of the Native UI?
2. Will the <b>SWING</b> technology succeed at all in future or it will be an another wasteful effort from SUN to catch hold of the desktop.
3. Why is SUN not able to bring Java to the mainfold of Desktop based Client applications.Even after 8 years of existence why no one in this world is choosing java for creating Rich client applications or to create an Office like package or to create a Utility tool like WINZIP or to create an EMAIL client like MS outlook .
Last but not the least <b> why in Java there is no one KILLER CLIENT APPLICATION</b>
I met with James Gosling this morning for 45 minutes in his office. When I arrived, he was typing happily into his Mac PowerBook laptop. I decided to this time to talk to him mostly about languages. We only had 45 minutes because he had to run off to a meeting, so I'll be going back to complete the discusion in a few weeks.
Thanks to everyone for their great ideas. 80% of your ideas make up about 80% of my questions for James, so most of you should get some answers.
There is one more question I'd ask him. I've read in interviews and articles that seem to suggest J2SE 1.5 will be the last release with major changes to the language itself.
* Is this true * If so, is it not signing Java's death warrant * Isn't there plenty that can still be improved in Java * If this is true, should we read into it that Sun have a replacement language brewing in the labs?
I would ask James if the plethora of language level changes proposed for 1.5 (JSR14, 175, 201 etc), is a big step up onto a plateau, or a step into a new watershed, unleashing a whole new range of possibilities for things we can do with the language which weren't previously possible or feasible.
If the answer is something like the latter, what does James see as some of the possible applications of these new features. I am not particulary interested in the obvious things, like Generics makes working with the Collections classes Type safe, but more how can these features can be used for something completely new (allowing for the fact that if it is completely new, James won't know about it yet anymore than you or I will!)
Another question (or maybe just another way of asking the same question). What concept can you not (practically) express in the(proposed 1.5 version) Java language, that you would really like to be able to express?
Previous Topic
