Java Community News - What Features Would You Remove from Java?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
What Features Would You Remove from Java?

63 replies on 5 pages. Most recent reply: Jun 12, 2007 12:07 PM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 63 replies on 5 pages [ « | 1 2 3 4 5 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 5:21 AM

> Autoboxing would indeed be a candidate for removal as well
> as it's a source of obscure errors and serves no purpose
> except to save on a few keystrokes in places while making
> source more obscure by hiding what's really going on (one
> more NPE in code that LOOKS to be assigning an int or long
> and I may scream).

The really sad thing about this is that there were a lot (and I mean a lot) of people making a lot of noise about how this was going to cause a lot of problems but they were ignored. Maybe next time it will be different.

> Removal of library classes like StringTokenizer

Are you saying that StringTokenizer is superceded by regex or something else? There are somethings that are very difficult and/or inefficient with regex that StringTokenizer can be used for.

Weiqi Gao

Posts: 1808
Nickname: weiqigao
Registered: Jun, 2003

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 6:00 AM

> > I would like to drop the requirement that in order for
> a
> > field or local variable to be accessible in nested
> classes
> > or local classes, it has to be declared final.
>
> That won't happen. It will confuse too many people when
> the method's variable doesn't change.

Then let the method's variable change. I think the restriction was there to ease the implementation of inner classes. There were no benefits to the user the inner class feature.

Now that they are talking about supporting closures in the language, surely they can make inner classes more powerful at the same time.

> I think the some (or all) of the closures proposals will
> satisfy your concern.

The way the competing proposals are still being debated, I'm not expecting closures to show up in Java 7 early next year.

Removing the final requirement might be easier to do because no new syntax is introduced.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 6:43 AM

> > > I would like to drop the requirement that in order
> for
> > a
> > > field or local variable to be accessible in nested
> > classes
> > > or local classes, it has to be declared final.
> >
> > That won't happen. It will confuse too many people
> when
> > the method's variable doesn't change.
>
> Then let the method's variable change. I think the
> restriction was there to ease the implementation of inner
> classes. There were no benefits to the user the inner
> class feature.

Yes it was to ease the implementation of the inner class. I read that they considered this but it would require allocating the methods variable on the heap and that was rejected, I believe because of performance concerns. Maybe those concerns are no longer applicable.

> Now that they are talking about supporting closures in the
> language, surely they can make inner classes more powerful
> at the same time.
>
> > I think the some (or all) of the closures proposals
> will
> > satisfy your concern.
>
> The way the competing proposals are still being debated,
> I'm not expecting closures to show up in Java 7 early next
> year.
>
> Removing the final requirement might be easier to do
> because no new syntax is introduced.

Maybe you are right. Actually, it just hit me that if final was used on the variable, they can still avoid a heap allocation. So they could allow this and existing code would not be changed at all.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 8:19 AM

> > Autoboxing would indeed be a candidate for removal as
> well
> > as it's a source of obscure errors and serves no
> purpose
> > except to save on a few keystrokes in places while
> making
> > source more obscure by hiding what's really going on
> (one
> > more NPE in code that LOOKS to be assigning an int or
> long
> > and I may scream).
>
> The really sad thing about this is that there were a lot
> (and I mean a lot) of people making a lot of noise about
> how this was going to cause a lot of problems but they
> were ignored. Maybe next time it will be different.
>

Is the problem auto-boxing or that nulls are so prolific in Java code?

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 8:50 AM

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 8:58 AM

> > > Autoboxing would indeed be a candidate for removal as
> > well
> > > as it's a source of obscure errors and serves no
> > purpose
> > > except to save on a few keystrokes in places while
> > making
> > > source more obscure by hiding what's really going on
> > (one
> > > more NPE in code that LOOKS to be assigning an int or
> > long
> > > and I may scream).
> >
> > The really sad thing about this is that there were a
> lot
> > (and I mean a lot) of people making a lot of noise
> about
> > how this was going to cause a lot of problems but they
> > were ignored. Maybe next time it will be different.
> >
>
> Is the problem auto-boxing or that nulls are so prolific
> in Java code?

It could be that nulls are prolific. But that's not going to change anytime soon.

My concern was that this adds an opaqueness to code that would be very hard for those new to Java to understand. If you worked with Java for a long time, you understand what the code actually does and why you were getting a NPE from a line of code that doesn't seem able to produce one. This is really confusing because usually when that happens, the source and compiled code are not in sync.

I think the way primitives were designed in Java was a huge mistake in the first place but trying to mask it with autoboxing is just compounding the problem IMO.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 10:19 AM

James - I like your idea to make final default on arguments, and private the default on fields and methods, if they add my idea of a package keyword for fields and methods.

Too bad it would break 99% of the code out there. :-)

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 10:23 AM

I find it interesting that nobody has complained about Generics. A few years ago that was de rigeur. :-)

For the most part, I like Java's generics. For simple uses, and even moderately complex uses, they document code and catch bugs. My only real complain is that I would like to save typing and go

List<Foo> fooList = new ArrayList();

without getting a meaningless and useless warning.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 11:36 AM

> I find it interesting that nobody has complained about
> Generics. A few years ago that was de rigeur. :-)
>
> For the most part, I like Java's generics. For simple
> uses, and even moderately complex uses, they document code
> and catch bugs.

I think they are fine if you don't try to get too fancy. The biggest problem isn't even with generics, it's with arrays that have been broken since the beginning.

> My only real complain is that I would
> like to save typing and go
>
> List<Foo> fooList = new ArrayList();
>
> without getting a meaningless and useless warning.

The only way I know to come close is to create a trivial factory method that takes an implied argument.

I asked the current compiler engineer to explain why this couldn't be done for constructors and there is some really esoteric reason that I don't remember but I do recall made me feel even more ambivalent about generics. It had something with raw types I think. Generics should be baked in from the beginning of a static language. They are a lot better in Scala and it uses erasure too.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 6:22 PM

> Yes it was to ease the implementation of the inner class.
> I read that they considered this but it would require
> e allocating the methods variable on the heap and that was
> rejected, I believe because of performance concerns.
> Maybe those concerns are no longer applicable.

The closure proposals, C3S, CICE, FCM, and BGGA, allow write access to local variables. With CICE the variable is marked public, with the others no new syntax. All the proposals box the variables that you write to, much like autoboxing of primitives.

Sun did consider autoboxing; but there was a strong negative reaction to autoboxing at the time, so they didn't do it. I don't think it is hard to do so it wasn't to make their life easier, it was considered that people would prefer the no autoboxing and explicit declaration option. They have a reasonable point, look at the reaction against autoboxing of primitives.

Personally I declare almost all variables final, I write in a functional style, therefore I don't have a problem with the restriction. However many people want this feature and this is the dilemma in introducing new features. You have:

1. People who want autoboxing removed

2. People who want more autoboxing

3. People who want the autoboxing they currently have removed and a new form added

It is therefore hard to satisfy everyone.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 6:39 PM

> List<Foo> fooList = new ArrayList();
>
> without getting a meaningless and useless warning.

The above code allocates a raw ArrayList that is necessary for backwards compatibility. The solution proposed in C3S is:

declare fooList = ArrayList< Foo >.new;
final finalFooList = ArrayList< Foo >.new;

Which uses changed syntax to allow the declaration and because the syntax changed it is not ambigouous. The original line is ambigous, is it meant to be a raw type or a generic type? Another option might be to declare the original example an error but allow:

List<> fooList = new ArrayList< Foo >();
final List<> finalFooList = new ArrayList< Foo >();

Larry Bugbee

Posts: 13
Nickname: bugbee
Registered: Dec, 2004

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 8:35 PM

Perhaps not popular and certainly not meant as flame-bait, but *I* would like to see classes and abstract classes with multiple inheritance, and have interfaces, per se, go bye-bye. Over the years I have found interfaces to be the single most complex aspect of the language, and IMHO, unnecessary. ...my opinion.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 8:42 PM

List<Foo> list = new ArrayList()

is clearly (to my mind) henceforth a List of Foos. I cannot call any ArrayList specific methods on list, only methods in List. If it isn't the right side, it's gotta be the left side. IMO, not ambiguous.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 9:26 PM

> List<Foo> list = new ArrayList()

As implied above, you could have the rule that if the generic arguments aren't on the right hand side of the equals then use the ones on the left and if they aren't on either side then use a raw type.

But then you would be in the habit of typing constructor calls without generic arguments. So if you weren't making an assignment then you might make a mistake, e.g.:

fooMethod( new ArrayList(), barInteger );
[java]
 
instead of:
 
[java]
fooMethod( new ArrayList< Integer >(), barInteger );
[java]
 
It would then depend on whether the saved typing is worth the extra mistakes. I guess Sun's call was that it wasn't.
 
Also some cases are hard to do without types on the right, e.g.:
 
[java]
static List< Integer > factory( boolean sync ) {
  return sync ? synchronizedList( new ArrayList() ) : new ArrayList();
}

The above example is in effect an assignment. Maybe the rule of inferring the right hand side from the left would work, but then again maybe it would be more trouble than it is worth.

Niclas Hedhman

Posts: 3
Nickname: niclash
Registered: Jun, 2007

Re: What Features Would You Remove from Java?

Posted: Jun 7, 2007 11:21 PM

> I think that the "final" keyword could be deprecated. As
> far as I'm concerned, it's just a flag to the compiler,
> which is equivalent to premature optimization in my book.
> As for its semantic significance on methods, I consider it
> arrogant for a class designer to determine, a priori, what
> I can override and what I cannot.

I totally disagree. One of the most important concerns to be able to support future compatibility is to limit the permutations of the usages of that code.
By not limiting the override, it is impossible to evolve a codebase and remain compatible.
In these days of open source, download the source and remove the 'final' yourself, but beware, you are on your own, and that you don't want either, right?

Flat View: This topic has 63 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic