I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Do You Really Need Java 7?

10.17.2008
| 27324 views |
  • submit to reddit

It's a long wait for Java 7 and there's a lot of speculation about what we can expect once the final JSR is out. I took a look through the what's coming up to find out if there's anything I actually needed.

One thing that struck me about the whole thing is that maybe there's less demand for a new Java version because of the following reasons:

  1. The advancements made in both Java 5 and 6 have satisfied most of our development needs from the JDK.
  2. One of the main things I was looking forward to in future versions was the reduced footprint from the JRE. Once again, that's already cleared with with Java 6 Update 10. 
  3. We've got so many frameworks out there, that we are no longer so dependent on JRE changes
  4. There's a whole lot of focus on JavaFX releases from Sun. Maybe this has taken over from old fashioned excitement about the next major version of Java.

Either way, from reading various breakdowns and predictions about Java 7, I decided to put together my own list of what I'd like to see happen.

No Closures

Neal Gafter has a closures prototype completed, but I'm still not convinced that it should be part of Java 7. When I interviewed Joshua Bloch a few months back I asked him for his opinion on the closures debate. 

As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.

I agree 100% with this. Simplicity is key and the thought of having closures in there just muddies the waters.  This feature has caused so much of a split in the Java camp, that it just doesn't feel right to include. Not for now at least. For those of you unfamiliar with closures, there's a good introduction here.

Better I/O

This is definitely something I'm looking forward to. The introduction of NIO was great a few years back. JSR 203  will include much better filesystem APIs. There's a good overview of the JSR over at David Linsin's blog, and on this article from Java.net. 

Making Swing Easier

I'm not saying it's too complicated right now or anything, but JSR296 would be a welcome addition. It has the aim of making desktop applications easier to create in Swing - which is something that's needed. The Eclipse RCP has raised the bar for desktop applications, and Swing needs to be able to compete. This specification will make it easier, and faster,  to get your Swing applications off the ground.

There's an excellent article on the Sun Developer Network outline how the new Swing Application Framework can be used. Geertjan has also written a nice account of what it actually means. 


If you want to keep track of what's going on in Java 7 discussions, the best place to go is Alex Miller's linkblog on the topic. It's been a great basis for me to get some insight into what may be coming up.

You've read what I'd like included, but what do you think is most important? And do you actually need Java 7?

Comments

Mark Thornton replied on Tue, 2008/10/21 - 5:30am

Full variance seems to hard for most people to work with (though this only really applies to those designing API and not users of those API). No variance is rather annoying. Covariance as with arrays does not cause much trouble or annoyance in practice. The ArrayStoreException is one of the rarest exceptions in my experience (I can't remember the last time I saw one). While the covariance of arrays was heavily criticised in the early years, I think most people now think it was the right compromise. Microsoft had the opportunity to do something different with arrays in C# and all the advantages of hindsight through the Java experience.

Yardena Why replied on Tue, 2008/10/21 - 5:54am in response to: Ricky Clarkson

Hi Ricky

Regarding properties, here's an example from "Introduction To LINQ" that uses properties in query conditions and initialization of (in this case - anonymous) types:

var query = from c in customers
where c.Discount > 0
select new { c.Name, Perc = c.Discount/100 };

Scala has properties and structural types too, and it's good at DSLs, so as far as I can tell it gets pretty close to what is needed for LINQ. The binding of "c" looks tricky to me, but then again I am not that good at Scala. In general, I wonder why there's no LINQ for Scala yet, or is there?  

Regarding wildcards - the paper is authored by Bracha and Torgersen, so I suppose they were responsible for the idea. I prefer variance annotations in Scala over wildcards, once you understand what variance is, they are really easy; and then Scala has existential types, for the rare complex cases. I don't know if that was one of the options on the table when they made the call for Java 5, or maybe javac has constraints that made it impossible or hard to implement, or maybe they thought it will be to hard to explain to Java programmers - e.g. all Generics tutorials manage to avoid the word "variance" almost completely. So as Mark pointed out, default co-variance might have been a better option for Java, in retrospect. But there had to be a way to address variance, that was my point, and wildcards are better than nothing at all. But that's history anyway. 

J Szy replied on Tue, 2008/10/21 - 7:42am in response to: Ricky Clarkson

[quote=rickyclarkson]Guido dislikes lambdas, and has a philosophy that says there should be one way to do everything. [/quote]

Wise guy, he is.

[quote]Here's one for you, from Scala:

println(for (i <- 1 to 10 if i % 2 == 0) yield i * 10) // this will print 10, 30, 50, 70, 90.[/quote]

Wow! One of the oldest SLDJ weenies' tricks: quote a oneliner that shows their SLDJ's conciseness at its best and demand an exact expression-to-expression Java translation. And all that in 2008, priceless! Did you really think I was gonna fall for it?

But I must admit, you brought  a new quality to the old trick! Your example doesn't even work:

scala> println(for (i <- 1 to 10 if i % 2 == 0) yield i * 10)
RangeFM(20, 40, 60, 80, 100)

scala>

[quote]Please port either or both of those to Java, and then with a straight face say that the result is more readable.[/quote]

I could even say with a straight face that my example worked as expected, but it's not my kind of fun, sorry.

[quote]Often I name my anonymous instances, e.g. public static final Function<Integer, String> intToString = ...

With an expressive type like Function it would be easy to search the code for something similar to what you wanted.[/quote]

Not really. If I want to check if someone had, for example, already written a FileFilter that checks a filename against a regexp (nevermind Commons IO already has one) with named types I'd start with listing types matching Reg*FileFilter - and that's how I found Commons' RegexFileFilter for the first time by the way; with anonymous classes I'd have to look inside every class implementing FileFilter - and, believe me, nobody will. Either it is possible to find a similar piece of code first shot, in a few seconds or it will get duplicated.

[quote]An anonymous class is not hard to make into a nested class.  It takes me, an emacs user, a minute for a reasonably large class.  It takes an Eclipse user three clicks (then a bit of editing to compensate for Eclipse's mistakes).

 I have to wonder why you are making it into a nested class though.  I do it because we have a coding standard that I disagree with; that anonymous classes should not be larger than 20 lines.[/quote]

Nested or toplevel, whichever is appropriate; usually toplevel. I refactor them because during a code review I found yet another load of duplicated anonymous classes. Is refactoring code to get rid of duplication foreign to you?

[quote]"it's even harder to promote to a named class: captured variables are writable"

Again, this is a mechanical translation that is trivial to do in an IDE,[/quote]

Both Eclipse and Netbeans usually need manual corrections after automated conversion of an anonymous class to nested, I don't see how they could convert closures seamlessly.

Ricky Clarkson replied on Tue, 2008/10/21 - 8:34am in response to: Claus Luethje

Let's suppose Java has import aliases, and consider that you have to work with John, who renames everything to Monty Python-related identifiers using them, e.g., import java.util.ArrayList as DeadParrot; and with your cousin, who renames everything to acronyms, e.g., import java.util.ArrayList as AL;

You should agree on a general style to use (which might be no import aliases) and then use that.  If you can't agree, then don't worry, because you're not actually working together.

For reference, I use import aliases in Scala to rename java.util.List to JavaList (this helps because I sometimes have to deal with both scala.List and java.util.List).  Also, as Scala allows imports to be within methods, I sometimes use import aliases to improve the lines of code immediately following them.  For example, from my unit tests:

"Parsing a line of domain crap with a negative timestamp" should {
"cause an IllegalArgumentException" in {
import java.lang.{IllegalArgumentException => IAE}
DomainCrapResult.fromDomainCrap("1, 1, Y, -111488075, 1") must throwA(new IAE)
}
}

Mark Thornton replied on Tue, 2008/10/21 - 8:39am in response to: Ricky Clarkson

And if a third party uses aliasses in the public interface of their API? Then you have the following options

  • Live with it
  • Maintain stacks of patches which remove them
  • Wait for an enhanced IDE or JavaDoc which removes them from view if not from the original source.

 As with most language additions it is usually impractical to pretend that they don't exist indefinitely. One way or another they tend to force their way in.

Ricky Clarkson replied on Tue, 2008/10/21 - 9:16am in response to: J Szy

I had to look up SLDJ - scripting language du jour.  Scala is a statically typed programming language; I'm not sure what you mean by scripting language, but Scala probably isn't it.  Nor is C#.

I didn't ask you for an expression-to-expression translation.  I asked for a translation that is readable.

Well done on spotting my typo.  Where's your code?

Regarding your search for types, consider that Google Collections exists.  There you will find Functions.identity, a method that returns a Function.  But you won't find it by searching only on types.  I suggest you search on all identifiers.

"I refactor them because during a code review I found yet another load of duplicated anonymous classes. Is refactoring code to get rid of duplication foreign to you?"

No, but it is possible to refactor to reduce duplication without introducing named types.  Suppose I spot a common Comparator<Integer, Integer> implementation in 3 methods.  It does the same comparison as Integer's own implementation of Comparable, but negated.  I have a choice between writing a type named ReversedIntegerComparator, and writing a method named reversedIntegerComparator() (that returns a Comparator<Integer, Integer>) or even a public static final field.  I always go for the field or method, because the concrete type is of no relevance to the caller, and can even be a distraction.

In general to find code duplication you might want to use CPD (part of PMD) or IDEA's truly amazing code duplication detector. (if only it would remove the duplications for you..)

Eclipse's translation of anonymous class to nested is particularly bad with generics, but like I said, it doesn't take long to manually sort out.  Ismael Juma informs me that Eclipse's codebase is moving to Java 5 (from 1.4) now, so things like that might change (dogfooding).  I don't know Netbeans.  IDEA does it right.

Ricky Clarkson replied on Tue, 2008/10/21 - 9:17am in response to: Mark Thornton

The discussion was about import aliases, not type aliases.  In Java, imports within a source file are not visible to an API user.

Claus Luethje replied on Tue, 2008/10/21 - 9:22am in response to: Ricky Clarkson

Ricky, I see your point with the List name and I guess in combination with other languages it may help (as we're working 'only' with Java, we differ in development environments).

As far as Java is concerned: nobody writes imports anyway and code completition while coding does the rest, so 'alias imports' aren't needed. 

Claus

Mark Thornton replied on Tue, 2008/10/21 - 9:38am

Strictly parameter names aren't visible either, but many IDE still show them when doing code completion. As Java doesn't yet have import aliasses the degree of visibility is unknown. I can see that they could be useful, but I wouldn't put them very high on my list of priorities.

Paul Stevens replied on Tue, 2008/10/21 - 11:07am in response to: James Sugrue

[quote=jsugrue]

You're right Jacek - it is probably difficult for corporations to turn around to using Groovy or Ruby.


So really, it sounds like we should be pushing to get Java7 on the road as soon as possible.

[/quote]

 

It depends how you phrase it. Most companies probably have different .NET languages all running on the same VM. That's exactly what Scala is to the JVM. Don't call it Scala to your boss, call it Java7 or Scala.java and they will never be the wiser :o)

J Szy replied on Tue, 2008/10/21 - 4:53pm in response to: Ricky Clarkson

[quote=rickyclarkson]I had to look up SLDJ - scripting language du jour.  Scala is a statically [/quote]

If you hadn't noticed I didn't write about those languages but about your oneliner challenge.

[quote]I didn't ask you for an expression-to-expression translation.  I asked for a translation that is readable.

Well done on spotting my typo.  Where's your code?[/quote]

Want my code? Though I'm not into grahamesque contests, I'll take your C# oneliner, here is equivalent Java code:

System.out.println("System.Int32[]");

More readable, isn't it? Shorter and cleaner I would say.

I don't know what you wanted to prove with that silly oneliner challenge, but if you have proved anything, it is that you don't know the languages you're bragging about and you don't care to check what the code you write actually does. 

[quote]No, but it is possible to refactor to reduce duplication without introducing named types. [/quote]

Why should I avoid naming types? To use closures, maybe? If a type serves sone purpose and can be reused (which in case of duplication is obvious) then it deserves a name. Mostly toplevel, sometimes nested, often I wish I had "internal" access, adapted to Java.

JeffS replied on Thu, 2008/10/23 - 12:39pm

A lot of the pro-closures arguments in this thread are pretty good.  They almost have me convinced.

 But in the end, I'm just not seeing enough ROI ...

Benefit - new ways of doing things, ways of making code more concise, make Java more expressive, make Java seem more "cool" or modern, make cutting edge devs more excited about Java

vs

Cost - complexity in the language, more things for developers to learn and apply/maintain (i.e. it's one thing to learn a concept, it's quite another to usefully apply it, or maintain someone else's code using that concept), language  feature bloat, become like C++ where devs get good at subset of features out of necessity, and the potential for the "dark corners" to bite people in the @ss.

 

Besides, for me, there are much, much higher priorities for improving Java, than there is for adding closures, such as:

1.  JVM start times improved

2.  Swing framework (not JavaFX), to make it easier to code GUIs.  It has started, but has a ways to go.

3.  Shared JVM and/or Java API in memory, among different running Java applications.  It's pretty wastefull to have a separate JVM running for every application, when different apps could share resources.

4.  Java kernel, with rest of JVM/platform incrementally downloaded.  This is coming soon, but will be a huge improvement.

5.  Nimbus (very nice, slick, modern) to be the default look and feel for Swing apps, over Ocean (somewhat primative and outdated).  This is coming, but it can't come soon enough.

6.  A standard component based web framework that does not suck like JSF.  Make it Wicket or Tapestry based (or similar).

7.  Stack allocated objects, like C# structures.  Sometimes, you just need a local object to do some basic chores, and have it discarded completely from the memory stack when you're out of scope or don't need it anymore.  Having (almost) everything an object in Java, and all objects are allocated dynamically on the heap, causes excess memory consumption, and extra work for the Garbage Collector (which, in turn, uses it's own cpu and memory).

8.  Apple to work with Sun to mutually keep the Mac JVM current.

9.  Linux distros to ship the JRE/JDK (Suns standard, or OpenJDK) always by default.

 

After all of this stuff, then maybe I'd like to see closures. ;-)

Mark Thornton replied on Thu, 2008/10/23 - 1:20pm in response to: JeffS

Re 7: I think we might reasonably hope for more work on escape analysis in Java 7. This should allow objects which have strictly local scope to be stack allocated automatically.

Jeroen Wenting replied on Tue, 2008/10/28 - 7:46am

And once again the only argument the closures addicts have is "Java needs it BECAUSE XXXXX has it".

As that's not a valid argument, there's thus no need for closures (aka function pointers, to use the proper name of the beast, which has existed for decades before anyone came up with a funky marketing term to make the concept sound more OO-like).

I full agree with James and Josh Bloch that we don't need to make the language more complex by adding things for the sake of adding things (which adding closures/function pointers would do, add things for the sake of adding things).

As it is, we're happily using 1.4.2 and 1.5 with no plans to use even 1.6 which is already a disaster of instability and Me2! features. 1.7 looks to be even worse, causing the total stagnation of the professional users (rather than the academic crowd which is the one screaming for closures and other rubbish noone needs) on old versions, which will lead to the eventual death of the platform as it becomes impossible to find JVMs for new operating system and hardware platforms that have a commercially acceptable (read NO GPL) license.

Ricky Clarkson replied on Tue, 2008/10/28 - 8:40am

And once again, surely at some point in the past some other language must have added closures because of some other reason than because another language has it.  I expect most add closures because they're useful.

Function pointers are not closures.

Who in the academic community is asking for closures for Java?  I haven't noticed anyone.

Also note that Java is not GPL.

Karl Peterbauer replied on Tue, 2008/10/28 - 9:46am in response to: Jeroen Wenting

Jeroen, you ignore that also many non-academic, "blue-collar" developers are simply tired and bored of writing tons of boilerplate inner classes just for wiring up a button and a handler method, or for displaying a property in table column, or for sorting a list of bjects by a simple criterion etc.

George Jiang replied on Tue, 2008/10/28 - 6:41pm in response to: Karl Peterbauer

The problem with adding closure to Java is that you have to add delegate to Java first. 

In the days of JDK 1.1 (no C# or .NET yet), Microsoft did request to add delegate to Java but was rejected by Sun spectacularly,

 http://java.sun.com/docs/white/delegates.html

 The arguments in this white paper still stand today. What changed? The perceived threat from C#/.NET?

Jeroen Wenting replied on Wed, 2008/10/29 - 7:50am

most common case will be 3) we have to fix the code our colleagues wrote that makes use of closures in such a way that it becomes a buggy, impossible to maintain or debug mess.

With closures allowing concurrent modification of method-local variables, all hell is bound to break loose as soon as they're used inside a JEE environment, especially a servlet.

And that's just one problem that won't crop up on some intern's personal Tomcat instance where there's only ever one client at a time.

Johan Compagner replied on Thu, 2008/10/30 - 4:28am

My personal view:

 i want properties support and method pointers

So that i can get rid of reflection based on strings (no refatoring support)

 things like

 

MyObject myObject = new MyObject()

AnotherObject anotherObject = new AnotherObject();

myObject.call( anotherObjec#method)

and in myObject i can then call that method

method.call(args) (just like reflection)

 

same for properties.

Ricky Clarkson replied on Thu, 2008/10/30 - 4:45am in response to: Johan Compagner

You'll probably be pleased to learn that the BGGA proposal supports the method pointer syntax you showed, roughly.  You do need to give the method parameter types too though.

Interestingly, in C# you don't need to give the method parameter types; the overload is chosen based on the type you assign the method to.  E.g., Action a = Console.WriteLine; a() invokes Console.WriteLine();  Action<string> a = Console.WriteLine; a("hello") invokes Console.WriteLine("hello");

Regarding properties support, what exactly do you need?  I sometimes wish that x.y would compile to x.getY() if there was no visible field named y, and that x.y = z would compile to x.setY(z) if there was no visible field named y, but I don't really care that much.  I think the usual getX/setX approach is inferior to functional reactive programming, as is in JavaFX, whereby a variable has dependencies and automatically gets updated when one of its dependencies is updated.. without even the possibility of seeing an inconsistent state.  A lot like how Excel updates cells when you change values.

Johan Compagner replied on Thu, 2008/10/30 - 5:30am in response to: Ricky Clarkson

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

 

class MyObject

{

 public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

 

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have 

class AnotherObject

{

   public String myMethod(String name, Number number)

   {

       return name + number;

   }

}

 

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

 

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

 

what i want is:

 

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

 

and this has to work throughout a complete path ofcourse:

 

Person#address#country#name

 

Those are just class properties so a direct replacement of refletion but then without the string. 

what also could be made possible is like above with the methods:

 

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

 

so directly of an instance the name property (not the value but the property to get the value)

 

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

 

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

 

HashMap<Stirng,String> map = new HashMap();

or 

 HashMap map = new HashMap<Stirng,String>();

 

both should be valid and just seen as it was declared on once side.

 

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket  generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

 now we have

 

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

 

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

Ricky Clarkson replied on Thu, 2008/10/30 - 5:48am in response to: Johan Compagner

Your method idea isn't a bad one, and is quite close to what C# delegates looked like in C# 1.0.  But having to name a method can be prohibitive; it would seem a bastardisation to return a method from a method, and sometimes it would cause a lack of encapsulation (single use private methods).  There are reasons why the C# guys didn't stick with what they had in C# 1.0.

HashMap<String, String> map = new HashMap() is already valid Java code.

Your idea about type parameter defaults breaks existing code that uses raw types.  Specifically, if List gained List<T default String>, then List list = new ArrayList(); list.add(new MyObject()); would fail to compile, because MyObject is not String.

Johan Compagner replied on Thu, 2008/10/30 - 6:26am in response to: Ricky Clarkson

[quote=rickyclarkson]HashMap<String, String> map = new HashMap() is already valid Java code.[/quote]

 yeah its "valid" code but it generates a warning and that shouldnt be. It should just be valid generic code. 

 

[quote=rickyclarkson]

Your idea about type parameter defaults breaks existing code that uses raw types.  Specifically, if List gained List<T default String>, then List list = new ArrayList(); list.add(new MyObject()); would fail to compile, because MyObject is not String.

[/quote]

 Ofcourse if you want backward compartibility dont add the default.. But for example in wicket.

version 1.4  requires java 5 and sun pretty much wants us to use generics everywhere or you get loads of warnings..  So yes you need to fix the warnings or errors when you used raw types and we say we now add a default and if tha default doesnt work for you you have to generify it (what suns wants us to do anyway....)

The problem is that generics arent that smart.. for example this class:

class Foo<T>

{

     Foo(Bar<T>) {}

     Foo()

}

you see 2 constructors but if you dont use the first constructor then why do i still have to type it? Else i get a big warning.. 

 Thats why i want to have defaults so that i can say class Foo<T default Void> because normally if somebody used the constructor with Bar it would have to type Foo correctly also if it doesnt it is just Void

Better would even be that generics was way smarter, the above class again, this must be done:

Foo<String> foo = new Foo<String>(new Bar<String>());

why is that? I just want to do this:

Foo foo = new Foo(new Bar<String>());

And foo is typed as a <String> because thats what the constructor does.

and then if i dont call the constructor with Bar then i have to type it myself or fall back on the default.

currently generics code outside of the collection classes are just plain ugly and full of warnigns otherwise.

 

Ricky Clarkson replied on Thu, 2008/10/30 - 6:52am

"It should just be valid generic code."

I'd rather have C#'s var dict = new Dictionary<String, String>(); or Scala's val map = new Map[String, String]

Note that neither are dynamically typed.

"Ofcourse if you want backward compartibility dont add the default."

How can you know how your class is being used?

"sun pretty much wants us to use generics everywhere or you get loads of warnings."

I think it is pretty poor form to make old code start to give new warnings.

I don't understand your point about 2 constructors.  If you don't want the constructor that takes a Bar<T>, delete it.

"And foo is typed as a <String> because thats what the constructor does."

You're talking about type parameter inference, which Java does a little of.  It does it for static methods; if you make the Foo constructor a factory method instead, the correct type of Foo will be returned.  I'm all for improving this.

I think the wicket team's experience is the same one lots of us had years ago.  You probably do generics wrong before you do them right.  I know I did.

Johan Compagner replied on Thu, 2008/10/30 - 1:32pm in response to: Ricky Clarkson

[quote=rickyclarkson]

"Ofcourse if you want backward compartibility dont add the default."

How can you know how your class is being used?

[/quote] 

No it is the other side around. We know if somebody uses Wicket 1.4+ we know they are targeting 1.5

So thats not legacy code, and we dont mind that we break then compartibilty. Yes you need to recompile anyway and yes if you then use a class of us that then have a default and you do  use it thats not the default then yes you have to fix that. But you have to go over your code anyway because yes we know that we break api that way. But thats not a problem because we are only binairy compartible in the x.x.y release not the x.y.

[quote=rickyclarkson]

"sun pretty much wants us to use generics everywhere or you get loads of warnings."

I think it is pretty poor form to make old code start to give new warnings.

[/quote] 

 

But it does! thats what java 5 does all over the place!

If you get old code now and compile against a java 5 compiler you get Tons of warnings!

 

[quote=rickyclarkson]

 

I don't understand your point about 2 constructors.  If you don't want the constructor that takes a Bar<T>, delete it.

[/quote] 

 

No thats not possible, I want that object, that object is in the api and that object i want type generify. If you want real life examples just go to wicket.apache.org and look at the api things like this:

TextField textfield = new TextField("person", new Model(person))

textfield.getModelObject() ==> should return person or

textfield.getModel().getObject() --> should return person

so what we want is this:

 TextField textfield = new TextField("person", new Model<Person>(person))

but what we must do because of generics:

  TextField<Person> textfield = new TextField<Person>("person", new Model<Person>(person))

 and thats just horrible.

We also have a component Link but for a link some uses the model so the same constructor as the TextField above. But others never use a model(object) for link so they use this:

Link link = new Link("mylink") { onclick(){stuff without model}}

again errors all over the place because link is Generified. now the Default will come in handy because i will make the default map to Void which is what the user also wants here. If the user does want to use a model object then he just needs to type it.

 

[quote=rickyclarkson]

I think the wicket team's experience is the same one lots of us had years ago.  You probably do generics wrong before you do them right.  I know I did.

[/quote]

 

Nope there isnt. There is no right way currently in our code setup that we want to have there just isnt we have had many tryouts. I have generified the wicket code base twice. then redone and again stripped and redone again. Now we removed a lot of generics we had before and we have we less but still users complain because of the warnings and the ugly code.

default keyword and better  inference is the only way to fix it. It is currently impossible to do it right.

Ricky Clarkson replied on Fri, 2008/10/31 - 3:18am in response to: Johan Compagner

> > I think it is pretty poor form to make old code start to give new warnings.

> But it does! thats what java 5 does all over the place!

Yes, that's what's poor form.

Regarding your type parameter default idea, you have an unusual case, because most classes don't control their callers.  In general it would be a backward-incompatible change to introduce a type parameter default to an existing generic type.

Incidentally, C# offers a solution to this.  A class Foo with no type parameters is a different class to a class Foo with one type parameter, so you can have Foo be a subtype of Foo<string>, achieving what you want but with the usual annoyance that inheritance brings.

Ricky Clarkson replied on Fri, 2008/10/31 - 3:26am

"TextField<Person> textfield = new TextField<Person>("person", new Model<Person>(person))"

You can improve that if you make a factory method to create TextFields and another to create Models.

TextField<Person> textField = textField("person",  model(person));

The reason is that Java does type parameter inference based on the parameter types and the immediate context, for methods, but not for constructors.

I think you should have the user use Void in the Link case, or use a separate type instead of Link.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.