John D. Mitchell's Blog: If you could get rid of one thing from Java...?

In the spirit of If I could add one thing to Java, I'd like to know what one thing you would take out of Java, if you had the chance. Not add, extend, tweak, exchange, or change but just what you would get rid of completely.

"You know you've achieved perfection in design,
not when you have nothing more to add,
but when you have nothing more to take away." --Antoine de Saint-Exupery

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Entity Beans
I know this is really J2EE rather then Java, but I'd still like to see them gone.

Posted by: johnreynolds on August 26, 2004 at 10:24 AM

Entity Beans
Yeah, who needs a component architecture that allows persistence of data? Worthless rubbish, it is. I think it's far wiser to move persistence out to every layer of the application that might possibly need it, because that uses up much more resources and makes debugging of synchronization issues a lot harder.

And that keeps us, as programmers, employed.

So that's a good thing. Down with anything that might help us do our jobs well, especially if we blame it without really understanding what it's for!

Posted by: epesh on August 26, 2004 at 11:20 AM

What about trade-ins?
For example, I would gladly exchange static methods for proper class methods...

As far as getting rid of something... the evil constructors no doubt!

Posted by: zoe_info on August 26, 2004 at 11:21 AM

What about trade-ins?
Re: Trade-ins

Dang! You got me on that one. I've updated the post to cover that case. :-)

Re: Evil constructors

What particularly don't you like about constructors? Or do you just want to get rid of them completely? What about things like (static) initializers?

Posted by: johnm on August 26, 2004 at 11:39 AM

Entity Beans
Hmm... To be clear, you want to get rid of just entity beans and not the entire pile EJB?

Posted by: johnm on August 26, 2004 at 11:41 AM

Entity Beans
So, what would you like to get rid of from Java?

Posted by: johnm on August 26, 2004 at 11:42 AM

CLASSPATH variable
Axe the use of the global CLASSPATH environment variable. To avoid conflicts, the classpath should be set on a per-application basis. Java make this relatively easy (through the -cp switch or Jar manifests), though there is room for improvement.

Then installers will quit mucking with my classpath, which they have no right to do anyway!

Posted by: jimothy on August 26, 2004 at 12:30 PM

restrictions on constructors
Subclasses should be able to inherit constructors.

I should be able to call super() and this() wherever I want in the constructor.

There is no reason to have these pointless restrictions.

Posted by: davetron5000 on August 26, 2004 at 12:40 PM

CORBA
The built-in CORBA installation was 1) way the hell too large for a component that only shows up in an extremely small number of java apps, and 2) was usually incompatible with other versions of CORBA because the Java embedded version was often a later version than the other vendor's stuff was.

Posted by: acroyear on August 26, 2004 at 01:29 PM

CORBA
Also, they have things of the same name as core java components, including "Object" making javadoc searches and references a pain, much less extremely confusing for novice programmers.

Posted by: acroyear on August 26, 2004 at 01:30 PM

Just nuke Entity Beans
Session Beans are fine, Message Beans are fine... use JDO for persistence behind a session fascade.

Posted by: johnreynolds on August 26, 2004 at 01:38 PM

What's your Vector, Victor?
I'd yank Vector and Hashtable, as they've been replaced by List and Map implementations, respectively.

Anybody else getting a sense of deja vu?

Posted by: jimothy on August 26, 2004 at 01:51 PM

Deja vu?
Thanks for adding the link.

I'm hoping that people will think broader than just stripping down J2SE.

Posted by: johnm on August 26, 2004 at 01:58 PM

What about trade-ins?
What particularly don't you like about constructors?

They are the odd guy out there. They don't follow regular message dispatching convention (e.g. target -> action). They are needlessly inflexible (method call ordering, no control over what is returned, weird initialization order). They don't respect inheritance. They just don't fit in. And they are a pain in the, er, neck to use...

Or do you just want to get rid of them completely?

Yes! Get rid of them! As well as the 'new' keyword. Ideally, java.lang.Object should just have a new() class method instead... but... there is no class method in Java... oh, well...

What about things like (static) initializers?

Ditto. They should be gone. No place for obscurantism.

Posted by: zoe_info on August 26, 2004 at 04:13 PM

What about trade-ins?
Having a Class-based instantiation method sounds very appealing to me, because it'd be so easy to declare factory methods. The question is, how do I enforce finality of certain fields? Passing a closure to the newInstance()?

Posted by: diprey on August 26, 2004 at 05:35 PM

What about trade-ins?
100% agreed. Constructors are one of those 'special cases' that obscure the overall elegance of the language.

I'd purely use factory methods for object instantiation if only static methods could be bound dynamically...

Posted by: el_barto on August 27, 2004 at 12:12 AM

Entity Beans
Umm... Willful misunderstanding of the reasons for wanting to get rid of Entity Beans or what?

Entity Beans are not the only component architecture for dealing with persistence of data, in their current incarnation they have many, many problems. The problems may go away with EJB 3.

Aside from EJBs you may want to look at JDO, Hibernate, Toplink and all the other persistence solutions in java.

Posted by: bob_boothby on August 27, 2004 at 02:43 AM

Swing and AWT
I know Swing quite well and can craft perfectly decent Swing applications, however the sweat and toil involved is far higher than any other GUI API I've ever used.

I'd hope that the vacuum of it's absence would cause a more robust and user-friendly API to take its place.

Bob B.

Posted by: bob_boothby on August 27, 2004 at 03:02 AM

Java? The language? The platform? The libraries?
Perhaps the term Java would benefits from some qualificatives as there seems to be a lot of confusion between its different meanings...

Posted by: zoe_info on August 27, 2004 at 03:37 AM

Drop Generics - No Question
I think that the addition of generics will be the downfall of Java. If you don't like things such as entity beans or vectors, you don't have to use them. But generics will complicate your programming life, and you can't ignore this new feature of Java.

I realize that it is impossible now to halt the addition of generics to Java, but I want to go on record as being completely opposed to this change. I have extensive experience with Java, and I have extensive experience with two other languages that support similar concepts, templates in C++ and generics in Ada. I consider myself to be an expert in all three languages as well as software development in general.

For Java, I believe that the addition of generics does not solve a problem, at least not a problem that I have encountered on any of the projects that I have worked on, but that its addition needlessly complicates the syntax and semantics of the language. I understand that it moves some run-time checks into compile-time checks, and in general that is a good thing, but the benefits in this particular case do not make up for the drawbacks.

In my professional career, I have moved from Ada to C++ to Java (ignoring other languages before Ada), and I found the simplicity and elegance of Java to be a welcome relief. Learning -- and teaching -- the Java language is straightforward. Additional work is required to master the extensive library and related technologies (JDBC, servlets, etc.), but that is exactly where the effort belongs. No other language has such comprehensive support in a standardized way.

I am afraid that they have ruined a great language.

Posted by: jmoore on August 27, 2004 at 04:43 AM

default implementations of clone(), hashCode() and equals()
I'd like to see the default implementations of equals(), hashCode(), and clone() dropped. Interfaces Hashable and Cloneable should be created to handle this.

Posted by: sbrandt on August 27, 2004 at 05:56 AM

RemoteException
Actually, I would make it inherit from RuntimeException. In other words, I would make it an unchecked exception.

Posted by: robbyn on August 27, 2004 at 06:21 AM

Foreach to his own
The new 'Foreach' construct. Its just yet another syntax variation which adds little but the hiding of one operation. Perhaps if it had been made more scannable/readable, like it is in other languages (FOR this IN that) ... but that obviously wasn't possible.

Although having read other comments, I have to admit I'm very tempted by the idea of no more CORBA!

Posted by: javakiddy on August 27, 2004 at 06:23 AM

Drop Generics - No Question
> For Java, I believe that the addition of generics does not solve a problem

i share your unhappiness at the language losing some of its simplicity, but in the current project I work on there is a lot of code like

Set /*File*/ files;

or

Map /*String, Set of File */ name2files;

where the only type checking I get is dynamic, replacing this with

Set files;

and

Map> name2files;

will be a glorious luxury..

oh, i just can't use it because its we're targeting 1.4 and its too risky to start making sweeping changes to the codebase and using retroweaver at the moment.. :)

Posted by: asjf on August 27, 2004 at 06:33 AM

complicated name resolution rules in inner classes
not sure how this would work.. but if you ever accidentally step into this territory you'll find yourself deep in the language spec. in no time, and a few days later at home with a wet towel around your head..

Posted by: asjf on August 27, 2004 at 06:35 AM

Foreach to his own
gah no! no! no!

its extremely useful - if only to replace the number of times I have to write

for(Iterator i = myCollection.iterator(); i.hasNext(); ) {
Thing t = (Thing) i.next();
...
}

Posted by: asjf on August 27, 2004 at 06:36 AM

RemoteException
i think one of the RMI people said in one of the online chats that RemoteException should probably have been unchecked in hindsight :)

Posted by: asjf on August 27, 2004 at 06:37 AM

What about trade-ins?
ignoring how this would break a lot of existing code..

i'd have "protected" mean "visible to subclasses only" - ie not to other members of the same package..

Posted by: asjf on August 27, 2004 at 06:39 AM

Entity Beans
Ok... If you won't let us just get rid of entity beans, let's drop EJBs completely. Don't push me, I'll get rid of the whole mess! :)

Posted by: tlaurenzo on August 27, 2004 at 07:15 AM

deprecated API
delete em all (after a major version upgrade)

Posted by: mreasy on August 27, 2004 at 07:44 AM

What about trade-ins?
Once upon a time, the Java language spec supported the "private protected" modifier, that did just that. But its been removed.

Posted by: jimothy on August 27, 2004 at 08:06 AM

Java? The language? The platform? The libraries?
Hmm... I'm not sure that "drop the confusing terminology" quite fits the question but what the heck. :-)

Do you have something else that you'd like to see removed from "Java"?

Posted by: johnm on August 27, 2004 at 08:28 AM

Clearly Date & Calendar
The whole Date-Calendar-Mess should be thrown away and be replaced with something that is more intuitive (see http://joda-time.sourceforge.net).
I mean if it's deprecated to call getYear() on a Date object then the API missed the point completely; and when you call getTime() on a Calendar, what do you get ? No, not a Time object, it's a Date ... just silly.

Posted by: sentinel101 on August 27, 2004 at 09:09 AM

Clearly Date & Calendar
I'll second that.

Although, if we're to play by the rules of this blog, we're only supposed to get ride of things, not replace or exchange them. So I say, get rid of Date, even though Calendar does have a horrific interface (were the developers just too lazy to write proper getters and setters?).

Posted by: jimothy on August 27, 2004 at 10:00 AM

Clearly Date & Calendar
Personally, I count this request as part of the "nuke all deprecated things" request. :-)

Posted by: johnm on August 27, 2004 at 10:04 AM

Java? The language!
... well... while we are at it...

I would really like to get rid of the artificial distinction between classes and interfaces... let's drop this class nonsense altogether... after all, a class is simply an interface which happen to have an implementation.

No reason to arbitrarily discriminate between interfaces with or without a concrete implementation.

Posted by: zoe_info on August 27, 2004 at 10:57 AM

restrictions on constructors
Well you don't want this leaking before the super has been called, or if the super throws an exception. That makes for a less restrictive but more complex set of restrictions.

Posted by: tackline on August 27, 2004 at 11:23 AM

String.substring
substring(startindex, endindex)
startindex - zero based index
endindex - one based index !!!!
who came up with ?

Posted by: zzc098 on August 27, 2004 at 11:29 AM

Miscellaneous language deletions
Restricting myself to interpreting the question as the removing parts of the Java Language without substitution, there's not many nasty features that can be removed sensibly without something going in their place. It's easier to slightly widen the question as which code that is legal shouldn't be, instead of which parts of the spec should be struck out (excluding cases of the word not).

The very rarely used % operator applied to floating point numbers would simplify the spec by the best part of a page. Octal literals went out with the 70's. The C-style array declarations (int x[] instead of int[] x) is an unhelpful legacy.

The fall through behaviour of the switch statement I've never liked. Only very occasionally is it useful, and even then I feel compelled to write big danger comments around it. It should be illegal for switch statements to have an execution path from a statement through a label (multiple labels okay).

I'd like to modify if/else, while, do/while to take statement blocks instead of statements, i.e. braces should not be optional. As try/catch/finally, IIRC.

It's a little bit controversial as to where redundant parentheses should be put into expressions to emphasise precedence. To make it clear, remove total ordering of precedence, for instance && and ||. Force expressions such as x && y || z to be bracketed. Similarly, expressions with associativity dependent conversions such as "" + 1+2 or myInt*myInt*myLong should be illegal. Boolean & and | are unusual and don't stand out as such.

Assignments within other expressions is a nasty hack. =, +=, etc., should form statements not expressions. Although I write buff[off++] often, I'm not keen on the increment and decrement operators returning values.

Compound assignments go to far, IMO. += and -= fine. *= even. But no more. And += with Strings isn't helpful.

Declaring multiple variables in a single declaration (int x, y;) is a cheap way of reducing the number of lines. Ban it.

Default constructors make some simple classes fractionally shorter, but are a pain if you explicitly don't want any constructors. Certainly you need a private constructor. Making the class abstract shows that there aren't any factory methods within the class, but theoretically a nested class could extend the outer class. A mess. Remove default constructors and/or remove the prohibition on classes being both abstract and final.

Implicit conversion from char to int can be a tad misleading (new StringBuffer('?')). Also from int to float and long to double, but I would like to keep/add int to double which doesn't lose precision.

Variables shouldn't be valid for specifying the containing class in field accesses and method invocations of statics. If System s = null; then s.out should be illegal. Or think yourThread.sleep(1000);.

I like that inner classes can touch the private member variables of their outers, but not vice versa. All sorts of weird stuff is allowed with nested classes. It ought to be pegged back. For instance, you shouldn't be able to extend an inner class and create an inner class with an outer class other than this.

Protected members are accessible by classes in the same package. They're practically public. Protect the protected. While I'm about it, non-private, non-constant member variables are almost always abuses. Disallow them.

import * has its uses, but is mostly abused. Unnamed packages are a pain after Hello World. Remove them.

Moving on to the new 5.0 features. I'm not keen at all on auto-unboxing. In particular there's the null/NPE issue and Integer <= Integer acts very differently from Integer == Integer. That is so very wrong. Actually I'd like to go as far as removing == and != as applied to references. For the relatively rare occasions where it is necessary, add in a new method System.identityEquals. On that theme, with generics, dynamic casting shouldn't have such a short syntax. Again a new method, an unchecked Class.cast needs to be introduced for odd cases. Alternatively make it illegal to cast without first checking with instanceof.

I'm not keen on .... I'd prefer to be able to write array initialisers outside of declarations where array type can be determined by context.

With the enhanced for (each) statement, does the old for still buy its way other than as a way of writing two or three statements on one line?

Now that there's @Deprecated, @deprecated should be deprecated.

Almost finally, some people would like to see the back of finalisers, but constructing elaborate java.lang.ref structures is no better.

But if I could only remove one thing, obviously it would have to be any code which doesn't obey my conventions on indentation and brace positioning. That kind of behaviour should halt the compiler and give the coder a small electric shock.

Posted by: tackline on August 27, 2004 at 11:33 AM

Brace Wars and the Time Machine
Where do you put your braces?

Posted by: zoe_info on August 27, 2004 at 12:30 PM

What about trade-ins?
I don't get this sentiment. You would do away with this perfectly usable, perfectly understandable construct just because it gnaws at your sense of "purity"? Is purity an end in itself? Why not attack the presence of primitives first?

Posted by: sumitkishore on August 27, 2004 at 12:38 PM

Type erasure
The adherence to backward compatibility which leads to Generics being implemented with type erasure.

Posted by: sumitkishore on August 27, 2004 at 12:40 PM

Swing and AWT
Swing is difficult because:
- built-in layout managers are painful
- multi-threading must be handled manually

Once you add JGoodies Forms & SwingWorker, Swing is a great graphics toolkit. It suffers severely because it is missing very helpful add-ons like these.

Posted by: jessewilson on August 27, 2004 at 12:45 PM

Miscellaneous language deletions
Octal literals went out with the 70's

There was just a blog where someone was complaining about getting a compiler error for the value '09'. :-)

How many of your complaints are directly due to the fact that the Java language was purposefully designed to be very familiar to C/C++ programmers? Next, given that a big help in Java's rise to fame was the fact that it felt familiar to a huge number of programmers, how could many of your ideas be implemented without destroying that? Of course, given that Java is now popular, would a serious refactoring of Java be palatable to people?

Finally, it seems like a large number of the items in your list are arguably based upon style preferences. In a general purpose programming language like Java, where is the line to be drawn between giving a wide latitude to things such as different usage subsets, style preferences, etc.?

Posted by: johnm on August 27, 2004 at 01:36 PM

Zero vs. 1-based indexing
Indeed, why continue with zero-based indexing when humans think in 1-based indexes?

Yes, I'm a old-school C and assembly language hacker so I'm quite comfortable with zero-based indexing. I'd be quite satisfied if people stuck with using only zero-based indexing. But, I think that there's a long way to go in the world of popular programming languages w.r.t. focusing on the needs of the developers rather than the compiler writers and CPUs. Also, it goes without saying that the mixture of zero- and one-based indexing is Pure Evil.

Posted by: johnm on August 27, 2004 at 01:42 PM

Swing L&F
I would want to just get rid of custom L&F for Swing and hopefully make it so a swing app will look and feel like the native applications by default.

Posted by: atrajano on August 27, 2004 at 03:30 PM

Type erasure
To an extent I agree. However do we really want to throw away what has already been developed? Throw away Java specific hardware even. Erasure's not so bad. To me it makes more sense than C# v2.0 dual approach. Having a single class object where class-wide statics can live is nice.

Posted by: tackline on August 27, 2004 at 03:45 PM

Zero vs. 1-based indexing
1-based indexing is fine until arithmetic is involved. Then it starts to become messy with +1s all over the place. Or should they be -1s. Difficult to say.

Back to the original imaginative interpretation of substring. It's a bog standard [closed, open) range.endIndex is zero based (and may be zero) pointing to the character after the substring. This makes the arithmetic, such as finding the substring before/after and the length much easier. OTOH, I would have thought it closer to the normal to specify the substring in terms of startIndex and endIndex-startIndex.

Posted by: tackline on August 27, 2004 at 03:49 PM

Miscellaneous language deletions
Yup, that was the weblog that reminded me. Not as bad as ye olde K&R C accepting 8 and 9 as octal digits (but I'm not old enough to remember that, quite).

As far as I can see, parts of Java (notably syntax) should seem familiar to C programmers, but there's little in common with C++ which isn't part of C.

One of the many things I like about Java is that you can just write down code without having to worry about which way to express it. There's one obvious way to write it, and one obvious way to read it. Compare against the repeating nightmare that is Perl. But style still comes into it. That can be tightened up, and obscurities removed.

These changes are at a very low level. It's not as if they affect paradigms as discussed in Jim Coplien Multi-Paradigm Design for C++ (note to most people who quote him: as far as I can tell he doesn't talk about functional programming, and the paradigms apply to Java (5.0) about as well).

Posted by: tackline on August 27, 2004 at 04:02 PM

Primitive types
Autoboxing is nice, but it would have been even nicer to kill primitive types altogether. Leave it to the JIT to optimize Integer to int. (The same for the other primitive types, of course...)

We are actually tantalizingly close. A single language change would make wrappers and primitives indistinguishable, namely to make == and != check wrappers by content rather than by identity. Then you could not tell the difference between 0 and "new Integer(0)".

Apparently, this was seriously considered, but some dufus somewhere may use distinct "new Integer(0)" objects and relies on them being != to another. Now we wouldn't want to break code like that, would we?

Posted by: cayhorstmann on August 29, 2004 at 11:50 AM

16-bit char
Ok, it's cheating to vote for two different things when it comes to getting rid of ONE THING in Java. But here goes...

Look at the abject pain that is caused by Unicode 4.0 support in Tiger.

A char is no longer a character. It is a "code unit in the UTF-16 encoding of Unicode". Some characters have two code units.

The API for all this is unbelievably wretched. For example, here is how you get the number of characters in a string:

int length = str.codePointCount(0, str.length());

Here is how you get the ith character:

int ch = str.codePointAt(str.offsetByCodePoints(0, i));

Or, of course, you can ignore the issue and write code that will work just fine for a year until one of your Far Eastern customers complains, and then you are hosed.

To fix this would require courage. char would need to be 32 bit. It would be up to the VM how to store String values, as UTF-32 or UTF-16 or some discriminated union or whatever.

To make this workable would require compassion instead of wretched API additions. For starters, why not allow

for (int ch : str)

to iterate through all characters (not code units) of a string?

Posted by: cayhorstmann on August 29, 2004 at 12:04 PM

16-bit char
+1

I felt the same way so I filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072130 a few months back and Sun closed it with an explanation. If enough people voted to have this changed hopefully they will revisit their decision. I too believe that as painful as 32-bit chars are for backwards compatibility, fudging up a basic type such as String in all future software is a far more expensive proposition.

Posted by: cowwoc on August 29, 2004 at 01:18 PM

Primitive types
Differences are not just in comparation. What about synchronization, for example? What should do synchronized(123) ? Will 123 be some kind of global constant/lock for this purpose? And what if i synchronize on i + 1, where i = 122? And what synchronization on element of array of (non-primitive) int?

Posted by: jarouch on August 30, 2004 at 01:36 AM

Drop Generics - No Question
Set /*File*/ files;

is kinda dumb.. I've very rarely made a mistake where I add the wrong thing to a collection.

I think generics is like killing a fly with a 20 000 ton truck. Too much cost, too little benefit.

Posted by: dog on August 30, 2004 at 05:53 AM

RemoteException
Sad.. some one beat me to this. :-)

Making RemoteException checked was one of the most horrible design mistakes in RMI . Even a programmer of basic to intermediate skill will scream that it fits into the category of unchecked.

All of one's interfaces get polluted. If one has a contact - take a PageIterator for example, one needs to add a bloody RemoteException to all the methods for remote pagination... one simply can't use the same interface for representing the same concept. Transparent programming is lost....

RemoteException being checked is the reason for existence for some non-sensical J2EE patterns like Business Delegate . On studying this pattern, one can clearly see that the fancy-sounding Business Delegate is nothing more than a type unsafe decorator. :-) .

Business delegates merely delegate to their contained object without implementing the interface of the contained object...and why is this so ? So that the clients of the delegate don't need to suffer by needing to handle RemoteException.... so lets make it unsafe! Well, they wouldn't have needed to suffer in the first place, while maintaining type-safety, if RemoteException wasn't checked....

Yeah.. rant for the day done... but one can't help feeling strongly about something so evident.

Posted by: lenkite on August 30, 2004 at 06:07 AM

RemoteException
Apologize... messed up with the tags there... it's a pity one can't preview/edit our posts..

Posted by: lenkite on August 30, 2004 at 06:09 AM

Primitive types
Hmm...interesting. I guess I'd start with not synchronizing on 123. (-:

Posted by: jimothy on August 30, 2004 at 06:35 AM

indirect comment
imho, all of these problems that people mention with java all stem from one larger problem: that java does not evolve orgnically. coders/designers at sun decided that class x should have feature y, regardless of whether feature y is needed by developer or has any roots in the real world. when people discover that feature y is not needed, feature y is not removed from the api. that's basically the issue with swing. i have come to believe that swing as it exists could use many improvements in design, some small, some large. yet swing remains substantially unchanged since its release. many suggestions have been made by the community to make both small and large changes of one kind or another to swing. but you never see that feedback getting integrated back into the swing api. the day java api development adopts the linux style of project management is the day java will begin to improve.

Posted by: eitan on August 30, 2004 at 07:39 AM

Drop Generics - No Question
Lets repeat the great mantra now:

Comments are NOT for the original coder's benefit. They are for the benefit of those who have to read and maintain the code after its deployed and LONG after the original developer has moved on and/or forgotten what they hell he wrote. And heck, "LONG after" could just be as recent as 3 months later.

I inherited code that is moving Maps around like fedex shipments from amazon, and I have to constantly dig through eclipse's "find all references" in order to figure out what the hell they're actually carrying.

I didn't write this stuff, but I inherited it from developers who at the time they wrote it had no plans to leave the company and stop maintaining the codebase.

Well guess what: they left the company and now I have to keep this stuff working.

I use /* type */ in my collections CONSTANTLY in order to save my descendents that unnecessary hassle.

Posted by: acroyear on August 30, 2004 at 10:51 AM

indirect comment
+1 Completely agree.
A couple of folks at Sun get it and are using mailing lists for feedback. The rest are alone and anonymous in their white towers building stuff no one wants.

Posted by: markswanson on August 30, 2004 at 12:21 PM

C-Style array declarations
To eliminate the possibility of something like:

int[] i[];

Posted by: seanreilly on August 30, 2004 at 03:59 PM

Get rid of ... clone and signed byte primitives
1. get rid of clone. I know its too hard but clone is a major wart, cut it out, the benefit will live on long after the pain.

2. Why Why Why is the byte primitive signed?
We never ever use it for a numeric value (does anybody?). We only use it to represent some on-the-wire/file data, and that sort of data has values 0x00 thru 0xFF ( and not even 0 thru 255 unless you are specifying IP addresses).
Try putting 0x80 into a byte primitive. Its UGLY.
Our code is bloated with ugly tricks to get around the fact that byte is signed. Get rid of it. (the sign, not the byte primitive).

Posted by: brucechapman on August 30, 2004 at 06:58 PM

Whingers
If I could get rid of one thing from Java, it would be all the people who whinge about it all the time!

This is mostly the people who want Java to have every language feature of C++ or who go on about Sun not open-sourcing Java or not implementing this feature or not removing that old API or Swing being slow and ugly (if it is, you're doing something wrong).

I personally think Sun have done a wonderful job with Java over the past decade and I hope they'll keep doing it for a few more. I rarely (it's relative) find myself banging my head over a J2SE API, and I think they've been making a true effort to listen to developers and move the platform in the directions that are needed.

I think about what I would be doing if Java did not exist and I shudder. People who whinge about Java don't know how good they've got it and should be terminated before they ruin it for us all! : )

(PS - No, I don't work for Sun.)

Posted by: grlea on August 30, 2004 at 06:58 PM

Whingers
Mu.

Posted by: johnm on August 30, 2004 at 07:33 PM

deprecated API
Check out the new Java Bug Database entry about finally yanking out the deprecated APIs.

Posted by: johnm on August 31, 2004 at 09:15 AM

Get rid of ... clone and signed byte primitives
Unsigned bytes... THIS is a great idea!

Posted by: erickson on August 31, 2004 at 02:37 PM

Entity Beans
As was mentioned in the rather fine critique to the EJB 3.0 spec, "New Life for EJB", Hibernate and JDO know "how to persist" but not "when to persist".

IMHO, (and I quote) allowing the container to manage the transation boundaries and persistence issues leaving the programmer to concentrate on the business logic is a spanking good idea.

The EJB spec (and v2.x does do a fine job) is unduly complex. This makes the above article worth reading (if you have not done so already).

Avaialbe at:
http://www.the serverside.com

Cheers
-raj

Posted by: rajs1 on August 31, 2004 at 03:36 PM

I would like to get RID of NULL POINTER EXCEPTION
I am sure most of the developers in the Java Communtiy are frustrated enough with this :)

Posted by: goldylukka on August 31, 2004 at 10:55 PM

Primitive types
More seriously what would happen to code like this:

Object a = new Integer(1066);
Object b = new Integer(1066);
...
a == b

Does all == on Object (and Number) test the class of the instances instead of compiling down to a single compare instruction? That could make by-standing code really slow. The alternative is to set a nasty, auto-unboxing-like trap.

Really the wrapper classses shouldn't extend Object, but that would make them useless. Perhaps a super for Object that doesn't define == and !=, and possibly isn't assignable from null.

Posted by: tackline on September 01, 2004 at 04:32 PM

I would like to get RID of NULL POINTER EXCEPTION
Really ? And what would you suggest if someone called a method on a null reference ? Crash the VM ? Log "Duh. What's that ?" to standard output. :-)

Posted by: lenkite on September 02, 2004 at 07:10 AM

Drop Generics!

Posted by: saintjohn on October 25, 2004 at 08:17 AM

Generic again for me. Big waste of time.

Posted by: paulbrickell on January 17, 2005 at 08:37 AM

Powered by
Movable Type 3.01D

java.net RSS Feeds