Influential Java programmers should learn C#

[brett...@gmail.com]

I'm not trying to set myself up for flaming here, so please read on.
The reason I started off with this topic is that I see a great deal of
`we need feature {x} implemented in Java' and then a whole host of
solutions to the problem and then large debates over them.

Again, not looking for flame wars, but I honestly think that C# is a
brilliant language, Anders Hejlsberg truely knows what he's doing in
this realm. There are three points to the C# language that they really
got right that Java needs to learn from, and why not just take the
exact same implementation?

1. Properties: Properties are so freaking simple in C# that it just
isn't funny any more. Take the following examples of C# properties.

// A traditional property
private String name;
public String Name {
get { return name; }
set { name = value; }
}

// This can be simplified since it's such a normal property not
performing
// any logic, the compiler will generate the field and accessors
for the field for us.
public String Name { get; set; }

// We can then make this a readonly property by applying a set
accessor.
public String Name {
get;
protected set;
}

2. Events: I don't want to elaborate too much here, but they're
similar to properties syntactically, they simply allow "subscribing/
unsubscribing" function pointers.

// Declare an event
public event EventHandler<MyEventArgs> MyEvent;

// Or you can control access tot he event via add, and remove
notation as is for
// Properties
private event EventHandler<MyEventArgs> myEvent;
public event EventHandler<MyEventArgs> MyEvent {
add { myEvent += value; }
remove { myEvent += value; }
}

// Subscribing a function pointer is very simple also,
`DoMyEventFired' is a
// function pointer matching the contract of `void (Object,
MyEventArgs)'
MyEvent += new EventHandler<MyEventArgs>(DoMyEventFired);
// Unsubscribing is the same, just with -=
MyEvent -= new EventHandler<MyEventArgs>(DoMyEventFired);

3. We all know that generics were not really implemented that well in
Java, but simply take a look at how they were solved in C#, we don't
have the problems of type erasure, they're also easier to understand.

I love Java, but we need the above, if we don't get the above we're
going to fall behind. There's many more that C# has like type
inference. Now with C# 3.0 and 3.5 we're starting to really fall
behind, take the following:

1. Use of the keyword `var' on the left hand side of a scoped field
declaration the compiler knows what the type is based on the right
hand side.

// In the following "myComplex" is still statically typed, the
beauty of it is in the
// compiler working out the type for us through implicit type
inference, var is inferred
// from the right hand side.
var myComplex = new Dictionary<String, List<String>>();

// thus we can use this as:
foreach (var val in myComplex.entrySet()) {
// val is inferred to be of type `List<String>', so the
following will throw a compiler error
foreach (String str in val) {
}
}

2. Extension methods, please don't implement the way suggested at
http://tech.puredanger.com/java7/, take a look at this instead. Please
not that because `you' get to control the behavior it makes it easier
to understand what's going on.

// Basically we need to explicitly declare an extension method to
be used by
// declaring a static class with a static method taking the `this'
keyword as a param.
public static class MyNumberExtension {
public static double Pow(this double x, double y) {
return Math.Pow(x, y);
}
}

// With this the following two are equal
double resStd = Math.Pow(2, 2);
double resExt = 2.Pow(2);

There are many more `features' of C# that I think we can learn from in
Java. Too many people I talk to have the attitude of "why look at C# I
never want to write programs for windows", well, I don't want to write
programs for windows either, but if they're standing on our shoulders
for the language perspective we need to have a rugby match with them
and actually compete.

Please don't dismiss this post as trying to start a flame war, I
really think Java can become so much more than it is. These abilities
make the component model in C# soooo easy to program against, you end
up with unexpected things like visual inheritance and a greater
flexibility for annotating that is accessible via reflection at
runtime making a vendor writers job as simplistic as it needs to be.

Please also forgive me for the length of this post.

[Jim Blackler]

2008/11/2 brett...@gmail.com <brett...@gmail.com>:
>
> ... some stuff about C# ..

I agree with all that. Having gone from C# to Java full time about six
months ago, I also miss the way C# gives you a choice between stack
and heap storage for objects, and the lack of obligatory checked
exceptions (now that really might start a flame war).

Jim

[Casper Bang]

Completely agree, my hat off to you for speaking frank even though you
obviously realize how unpopular that could make you. I'm rather hoping
Neal Gafter's change will perhaps open up the community a little to
stimuli from outside, for its own sake.

/Casper


On Nov 2, 12:56 pm, "brett.r...@gmail.com" <brett.r...@gmail.com>
wrote:

> 2. Extension methods, please don't implement the way suggested athttp://tech.puredanger.com/java7/, take a look at this instead. Please

[RogerV]

My current pain point is properties. Am working with Spring and iBATIS
and iBATIS wants to map to Java classes that follow JavaBean
properties convention of getters/setters.

It gets so old and tedious - and clutters up the code readability - to
toss all that getter/setter boilerplate in.

But I really prefer ActionScript3 properties over C#.

I can do data binding to these class properties (just use Bindable
annotation - no need to introduce explicit getter/setter syntax in
order to get databinding capability):

public class RestaurantProduct {
[Bindable]
public var idNo:int;
public var prodName:String;
[Bindable]
public var desc:String;
}

From some MXML code I'd just use declarative binding, like so:

<mx:Label text="{garlic.idNo}"/>
<mx:Label text="{garlic.desc}"/>

Or make all properties of the class bindable at once:

[Bindable]
public class RestaurantProduct {
public var idNo:int;
public var prodName:String;
public var desc:String;
}

<mx:Label text="{garlic.idNo}"/>
<mx:Label text="{garlic.prodName}"/>
<mx:Label text="{garlic.desc}"/>

But if I want to have explicit getter/setters, then ActionScript3 has
that too:

public class RestaurantProduct {
private var _idNo:int;
// constructor - property idNo can only be set at construction time
public function RestaurantProduct(idno:int) { _idNo = idno; }
[Bindable]
public function get idNo():int { return _idNo; } // getter for
property idNo
[Bindable]
public var prodName:String;
private var _desc:String;
[Bindable]
public function set desc(value:String):void { _desc = value; }
public function get desc():String { return _desc; }
}

The explicit getter/setters are useful when I want to have special
behavior or fine-grained control over bindable events:

public class RestaurantProduct {
[Bindable]
public var idNo:int;
[Bindable]
public var prodName:String;
private var _desc:String;
[Bindable(event="changeDescription")]
public function set description(value:String):void {
if (....) { // do something to see if should really change the
property
_desc = value;
dispatchEvent(new Event("changeDescription"));
}
}
public function get description():String { return _desc; }
}

[brett...@gmail.com]

RogerV, great, maybe we should learn flex/actionscript also. I haven't
done a lot of action-script so won't pretend to know how the flex/
flash VM works. What I am interested to know though is how all that is
handled inside the flex VM.

With C#, when you write code agains a field and compile that code you
end up with a field pointer, but when you compile against a property
you get a property pointer. These `look' identical from client code,
but are completely different when compiled. Consider the following:

// This is a field.
public String Name;

.. and then compile against the field, then later decide that I want
to control the field by changing it to a property wrapping the field:

// Field `Name' turned into a property (intention
// is to replace the previous `field' called `Name'
public String Name { get; private set; }

... anything previously compiled against the field but not recompiled
against the new library will be broken. This is due to the first being
a field pointer while the latter is a property pointer.

Think of this from a VM perspective, I can traverse the object graph
to locate it's properties and determin metadata of the properties
(permissions, bindability). From reflection the property and fields
are very different.

What I'm getting at in the end is, the syntax you've put forward looks
more like a field, but then you add accessors to the field and it gets
turned into a property; so, how is the VM handling this, if it's now a
property pointer you could be in trouble if you aren't compiling
everything against that code.

Let me ask this, with java properties and reflection, what would you
expect to see?

String.class.getDeclaredFields();
or
String.class.getDeclaredProperties();

We would also need a corresponding java.lang.reflect.Property class,
or with your suggestion would this mean that java.lang.reflect.Field
would be extended to support property specific metadata?

-Brett.

[Pete F]

Well yes, there is the argument that Java.next already exists -and is
called C# :-) (or is java.next called android?)

So why exactly is there not a C# compiler for the JVM already (maybe
using mono classes for the framework)?? -or is there ?? (there is
mainsoft but that is msil to java bytecode)

OR.... (and admittedly, this is a stretch -and may have been
discussed elsewhere)...

Is C# on the JVM what the good Dr Gafter has been hired for?? I know
I know -why would they? Well for starters, maybe Microsoft doing it
would be better (for Microsoft) than someone else doing it (eg would
there be better support for java on the clr if there hadn't been
J#??). Ok, its a long shot [ and I already have Dr gafter busy
implementing his closures in J# :-) ]

Much as I like C#, I would be kind of sorry to see it become the de-
facto better java -not so much from the evil empire angle, more
that it would feel like globalisation treading on culture.

nah -let C# do the hard yards handling manycore, then a real
java.next can learn from it like C# learned from java


Pete F

long bet -one day the jvm and the clr will be considered the same
thing

[Brett Ryan]

There was a time a couple of years ago when I said to myself "I would
love to write C# language support for the JVM", my idea was to take
.cs files and compile them down to byte code for the JVM.
Unfortunately I'm not a JVM export, but hell, I love a challenge and
would still give it a crack if I have some spare time. Mind you if
properties, events, delegates (function pointers), structs, closures
and lambda expressions were all in Java then I wouldn't care for C#
too much.

C# is doing and in many cases has already done the hard yards, IMHO
the way that these language features have been implemented in C# are
proven, easy to understand and very effective, let's not let them get
too far ahead and implement these features into Java. Scala is a good
example of being proactive about providing these feature sets.

C# is standing on Java's shoulders, let's learn from C# and stand on
theirs a little, there's no shame in this. I don't want Java to become
the new C.

-Brett

[Casper Bang]

> So why exactly is there not a C# compiler for the JVM already (maybe
> using mono classes for the framework)??  -or is there ?? (there is
> mainsoft but that is msil to java bytecode)

That is a darn good question and it's perhaps the greatest evidence to
the fact that the Java community prefers to imagine C# doesn't exist
(apart from a few mavericks like Ted Neward and Sarah Pa.. no strike
that). You can run all kind of weird languages on top of the JVM, but
not C# which for all intents and purposes is Java.next. The mindset
also shines through in this podcast, while the posse guys are of
course free to interview whom they want, it's sad (and in stark
contrast to i.e. .NET rocks) how they never once crossed over to the
other side to assert how green the grass is or isn't there - as if
nothing good could come out of it.

The merge of the JVM and the CLR has been proposed in the past, it
might happen with the Mono VM eventuall (which will quite happily run
Java code and whos designers plan to take full advantage of
interesting OpenJDK bits) and that's also why platform-hybrid
languages such as Fan is an interesting thing to follow.

/Casper

[Weiqi Gao]

Casper Bang wrote:
>> So why exactly is there not a C# compiler for the JVM already (maybe
>> using mono classes for the framework)?? -or is there ?? (there is
>> mainsoft but that is msil to java bytecode)
>
> That is a darn good question and it's perhaps the greatest evidence to
> the fact that the Java community prefers to imagine C# doesn't exist
> (apart from a few mavericks like Ted Neward and Sarah Pa.. no strike
> that).

I'm sorry Casper, that's not a darn good question. And the Java
community takes C# very seriously. Look at Java 5, and tell me which
new language feature is not inspired by C#?

> You can run all kind of weird languages on top of the JVM, but
> not C# which for all intents and purposes is Java.next.

You also can't run C++, nor Perl, nor Common Lisp, nor PL/I on top of
the JVM.

There are a lot of things that are theoretically possible but is not
being done in reality. They are not done because doing them helps no
one. Why don't people write cross-platform applications in the Windows
API? With WINE, it is theoretically possible.

> The mindset
> also shines through in this podcast, while the posse guys are of
> course free to interview whom they want, it's sad (and in stark
> contrast to i.e. .NET rocks) how they never once crossed over to the
> other side to assert how green the grass is or isn't there - as if
> nothing good could come out of it.

It's not like we (the Java Posse listeners) can't find DotNet Rocks or
Channel 9 ourselves if we want to hear interviews with Anders Hejlsberg.

> The merge of the JVM and the CLR has been proposed in the past, it
> might happen with the Mono VM eventuall (which will quite happily run
> Java code and whos designers plan to take full advantage of
> interesting OpenJDK bits) and that's also why platform-hybrid
> languages such as Fan is an interesting thing to follow.

Not all things in the world are meant to be abstracted away. As the
world stands now, JVM and CLR are the two dominant runtime platforms.
Others may come along later on. This is no different from other
dichotomies in the programming world:

vi vs. EMACS
UNIX vs. Windows
C++ vs. Smalltalk
System V vs. BSD
RPM vs. deb
GNOME vs. KDE
Spring IOC vs. Guice

The urge to unify similar things in computing is very strong, but any
attempt at doing them all ultimately fail.

--
Weiqi Gao
weiq...@gmail.com
http://www.weiqigao.com/blog/

[Lars Westergren]

> That is a darn good question and it's perhaps the greatest evidence to
> the fact that the Java community prefers to imagine C# doesn't exist
> (apart from a few mavericks like Ted Neward and Sarah Pa.. no strike
> that). You can run all kind of weird languages on top of the JVM, but
> not C# which for all intents and purposes is Java.next.

I can't speak for all java programmers, but for my everyday work, Java
does most things I need. If I need more flexibility, I'd use Groovy or
JRuby for those sections. I'm doing Scala on the weekends to learn
functional programming.

C# to me doesn't seem to offer enough that is different (from my
admittedly quick looks at feature bullet point lists) to sacrifice
even more of my spare time to learn it. The fact that I don't like
Microsoft's business practices and try to stay away from anything
associated with them for that reason is just icing on the cake.

Cheers,
Lars

[Brett Ryan]

We should definitely NOT merge C# and Java, competition is what helps
us grow and evolve, we just need to be smart about it.

A lot of these language features need to come to java and they need to
come soon. C# is gaining a lot of traction and is evolving pretty
quickly, it's got a healthy following and a thriving community of
content and control authors. I'm not saying java doesn't have this
sort of ecosystem, but the java ecosystem isn't expanding as fast as
the .NET ones are. Who knows what's to come now that Windows Azure has
been launched.

Your V's list is very true, and healthy; but wouldn't it be good for a
KDE developer to use Gnome, and a vi user to use EMACS once in a
while? Most .NET developers I know also know Java, but not as many
Java developers know C#, why is that? Would you think that MS
developers are using OSX? I could bet my house on it, I'd also bet
someone in Redmond is looking at whats going on in Java.

-Brett

[Casper Bang]

> I'm sorry Casper, that's not a darn good question.

Sure it is. I have met many (like obviously the OP) who would not mind
being able to use some of the benefits of C# (i.e. utilize LINQ or a
strong component model) on top of the JVM to be able to use the best
of both worlds. Without putting words in his mouth, I do believe our
own Joe Nuxoll testamented to something along similar lines in past
episodes. Take a look at the 10 most used languages from the Tiobe
index, is it such a dumb question after all considering what the JVM
and NetBeans now supports?

> You also can't run C++, nor Perl, nor Common Lisp, nor PL/I on top of
> the JVM.

That's a fallacy. We're talking about a corporate, strongly typed and
managed language here in the context of "improved java".

> There are a lot of things that are theoretically possible but is not
> being done in reality. They are not done because doing them helps no
> one. Why don't people write cross-platform applications in the Windows
> API? With WINE, it is theoretically possible.

Umm that's exactly what Google does, have you never used i.e. Picasa
or Google earth on Linux?

> The urge to unify similar things in computing is very strong, but any
> attempt at doing them all ultimately fail.

That's not unique to computing, Darwin, Einstein and people before
those all dreaming about "the grand unification". Also, the fact that
I am writing in English to you is a pretty good example of what
unification can provide when it comes to interoperability. But to
remain in the computing field, I think few people are sad about the
merge of Beryl and Compiz. I didn't mean competition is bad though, I
meant it's interesting to see what a 3'rd part can do with the best
bits and pieces from the two competitors.

/Casper

[mkpapp]

One question is why we want to run all these different languages on
the JVM. I think the most substantial reason is to have access to all
the marvelous libraries available in Java. We have those shipped with
the JRE, plus a veritable treasure trove of open source libraries and
frameworks to choose from. The downside is that the ubiquitous
interchange of objects from one language to the other, via the JVM, is
quite difficult. Whether it be for language semantics reasons, or
internal wrapper implementations that make objects "look/act" like a
standard object in the bridged language. The CLR was designed with
language interoperability in mind, while not so much for the JVM. The
point being, a C# to bytecode compiler and bridge library can be
created, but the result will likely be a language that is implicitly
different from the one that runs on .NET/Mono. That said, I still
support bringing various languages to the JVM, in that (with a given
set of caveats) it broadens the tools available to the Java community
- not to mention non-Java programmers who benefit from this symbiotic
relationship.

As to merging Java and C# in some fashion: while C# is an attempt to
build a "better Java," they diverge pretty quickly once one looks
beyond the pure syntactic similarities. Some aspects of C#, indeed,
address deficiencies as I perceive them in the Java language (structs,
standardized bridging to other languages, and various improvements
mentioned in this thread.). Others, IMHO, repeat the sins Java has
successfully cast aside in order to address shortcomings in C/C++. A
previous poster, Lars W., pointed out that "but for my everyday work,
Java does most things I need." I started out with Java pre-1.0
release, and the language provided a wonderful break from C++ that was
simple and just worked. The improvements and extensions to the core
libraries since then have only increased the language's value
proposition as a great platform for development. Using those original
language syntax and features, one has the tools to write at any level
of complexity. Maybe not as compactly or efficiently as we can with
Java 6 language features, but write it nonetheless. The problem being
addressed by java.next or the great search for the new "lord of the
ring" language is that Java, C#, what have you can be improved upon
and come up with a next generation language. One that I personally
hopes addresses parallelism inherently and leaves the broken notion of
threads, processes, and hacks we've used for thirty years behind.

I apologize for going off on a tangent, but there is a relevant motive
here. We need to ask ourselves if the effort to bend and mold other
languages to run on the JVM is a worthwhile effort, or just a delaying
tactic until the next great thing comes along. For my 2 cents, I
think we are learning a great deal from the efforts on JRuby, Scala,
Jython, JSqueak/Potato, and many, many other projects - my admiration
goes out to these individuals and their projects. I'm sure we would
learn a great deal from a similar effort for C#. But the choices are
clear: build a new language on the JVM, port an existing language to
the JVM, or go out and build a new language (and VM). You will get
what you seek - just decide what it is you are seeking.

[RogerV]

For my current employer I've written a lot C# .NET application code
and Java middle-tier code.

On balance, if I were to be tossed on a desert island and could have a
choice of only one of these 2 languages, I'd opt for Java (as long as
I get an Internet connection and Maven). In the end I find it more
powerful (except in the area of interfacing to non-managed C libraries
and OS APIs - C# shines in that department).

Sure C# has more language feature goodies, but Java surpasses in
certain other areas:

*) JMS messaging (all manner of implementations available, from
various hard-core and full featured enterprise versions, to various
free, open source, to interesting experimental designs)
*) Spring Framework - this has made dependency injection second nature
for Java programmers. Plus a lot of great helper and template class
stuff that makes short work of many routine things we deal with in the
middle-tier.
*) Concurrency Library introduced in Java 5
*) Java NIO (especially when coupled to Concurrency Library)
*) iBATIS data mapper. Much more sensible (pragmatic and real world
grounded) way to interface to relational databases than LINQ.
*) Maven build tool (much better way to build and manage large
software projects than Visual Studio)
*) Hudson CI - great ease of use factor and pretty fair versatility
*) More versatile applications servers, ranging from Tomcat, Jetty,
MINA, Grizzly, to JBoss, Glassfish, et al. I've done a lot of a-
typical development in app servers. Which was possible in environments
like JBoss or Tomcat, which are actually very open-ended (especially
when Spring Framework or EJB3 is in the picture). When I started doing
JBoss JMS MDBs, I was doing a load-balanced cluster with little fuss
or muss in no time. The .NET middle-tier stack wasn't comparable then
and still isn't now. Too damn web focused.
*) Just in general the vast eco system of libraries and frameworks,
where much (if not most) of the good stuff is free and open source -
and Maven is there to make it all easy to tap and incorporate with
controlled rationality.

I guess the point I'm making here is that it isn't so much Java the
language per se that is the strength of Java (and it is a pretty
decent language all in all) - it is the whole eco-system that
encompasses the experience of being a Java developer. There's an
immensity to that eco-system that levels down a whole ton of the
niffty language features of the seemingly more fashionable languages.

[Mark Derricutt]

I wonder if anyones looked at writing a C# compiler for the JVM?

On Mon, Nov 3, 2008 at 11:43 PM, Pete F <google_u...@spatialmedia.com> wrote:

Well yes, there is the argument that Java.next already exists  -and is
called C#  :-)   (or is java.next called android?)

--
"It is easier to optimize correct code than to correct optimized code." -- Bill Harlan

[BoD]

Seriously, there's no reason to think he would be "unpopular" by
suggesting to improve the Java language, and to look at other languages
to do so. The Java community, and this group in particular, are not THAT
close-minded.
Now I suspect YOU're trying to start a flamewar, Casper, with your
comment ;)
(ok I admit I just put oil on it by replying...;)

BoD

[Pete F]

> I'm sorry Casper, that's not a darn good question.

i think it is a gosh darn good question Casper ;-), because it goes to
the rather obvious similarities between the two languages and
runtimes -and more importantly to the fantasy that they are
radically different


Weiqi Gao's list of languages that are NOT statically typed,
pointerless, object oriented, with single inheritance and single
dispatch -rather does highlight the similarities between java and
c# -thanks :-)

>>We should definitely NOT merge C# and Java,<<

i'm not suggesting anyone *should* merge them -but rather that
perhaps they inevitably *will* merge, like a couple of big
corporations that duke it out, until one day when the market has moved
on and competition is biting -people realise that well, we really are
on the same page after all

-maybe not even merge, but just one day be regarded as pepsi and
coke -or just cola- in a world that has moved on to drinking
designer prune juice

the force that keeps java and c# apart is interesting -partly
corporate, partly philiofossical, but largely tribalism -and no,
perhaps not a bad thing (hence my reservations about mixing the two
environments because the very existence of separate cultures is rather
nice)

again -take a long view -C# is doing the heavy lifting right now,
implementing experimental stuff like linq that will take its toll on
the language, and inevitably cripple c# with backwards compatibility
restrictions, -about then would be a good time for son-of-java
(literally in many cases! -hopefully daughter of java in others which
might do more for language wars than anything technical)

Pete F

microsoft kool-aid drinker, sometimes user of WINE, and longtime posse
listener who just can't bring himself to listen to a podcast with a
name like Dot Net Rocks (look out!, i'm pushing your tribalism
buttons)

[Brett Ryan]

@RoverV

I very much agree with you that the java ecosystem has a vast plethora
of frameworks to help us along, mind you C# is starting to pick up the
pace with codeplex and IoC/DI frameworks like Unity. They also didn't
really need a NIO because they got IO right from the beginning. The
build system also got replaced in .NET 2.0 to behave more like ant
(though IMHO it still sucks), and there's always nant.

I must point out though that in your list of benefits to the Java
language there aren't really any rich client benefits, they're biased
towards backends.

Properties, Events and Delegates are the three things that really go
hand in hand with rich client development. For someone who might be a
server side developer where most tasks are stateless they may seem a
little useless. I haven't used JavaFX yet, but if it's statefull then
it could definately benefit from these three components.

Take the following swing snippet

myButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
// Handle action event
}
}

Does it look neater to see this instead?

myButton.ActionPerformed += new EventHandler(doMyButtonAction);
// And have the event handler elsewhere.
private void doMyButtonAction(Object sender, ActionEvent args) {
// Handle action event.
}

The real pain though is trying to fire an event in Java, you need to
hold a collection of listeners, then traverse over them fireing events
one after the other.

Firing an event in C# is as simple as calling it, just like a method,
it will traverse the function pointer graph for you.

MyEvent(Object, MyEventArgs);

-Brett

[Brett Ryan]

@Pete F

> again -take a long view -C# is doing the heavy lifting right now,
> implementing experimental stuff like linq that will take its toll on
> the language, and inevitably cripple c# with backwards compatibility
> restrictions, -about then would be a good time for son-of-java
> (literally in many cases! -hopefully daughter of java in others which
> might do more for language wars than anything technical)

LINQ is basically some syntactic sugar over Lambda expressions that
have been in the language since 2.0. The current closures spec is
supposed to cover lambda expressions right?

Up until now I didn't give it much thought on HOW lambda will be
implemented in Java, but now I'm confused how it's going to be done,
Lambda expressions `depend' on function pointers since they are
anonymous functions. I don't think we should have LINQ type language
embedded into Java just yet, but we could definately benefit from
Lambda expressions.

// The following C# snippet demonstrates lambda expressions,
// note that the FineAll method accepts a delegate/function
// pointer.
List<String> myList = new List<String>() {
"One", "Two", "Three", "Four"
);
List<String> filteredList = myList.FindAll(s => s.StartsWith("T"));

Properties, Events and Delegates were in C# since 1.0 so what's that,
8 years, nearly 9 that they've been able to prove that it works?

They also got Generics right because they were't concerned with going
over the existing class libraries and retrofitting generic support to
them, they rightfully left the whole lot alone and created new classes
with generic support and deprecated the old ones. I didn't see the
light when they first did that, but I learnt to understand the meaning
behind their madness.

So hey, now we have PEDL, the four language features required to power
Java ahead of C#.

Properties, Events, Delegates and Lambda expressions :)

-Brett

[Jess Holle]

Brett Ryan wrote:

So hey, now we have PEDL, the four language features required to power
Java ahead of C#.

Properties, Events, Delegates and Lambda expressions :)
  

I won't say these aren't much better in C# than in Java.

I will say the examples given in posts thus far haven't really proven this to me.  += syntax for event listeners and shorthand for getter/setter accessors?  Yawn -- not bad but nothing I'd get excited about.  Syntactic sugar that saves a little typing doesn't quite wow me (most especially since many developers would not know how to place a breakpoint in a gettter/setter for a while after such an improvement).

Now more type-safe compile-time treatment of properties and event listeners than that possible with Java, that could be a little more interesting.  For instance having "->" be interpreted as a one-time per-class lookup at runtime for the corresponding bean property accesser or field with efficient access thereafter.  The type would be that expected based on accessers/fields found during compilation.  Or something to this effect...

Overall I'm pretty happy with Java generics as well.  They're not perfect, but type erasure rarely causes me issues and while handling primitive type parameters would be nice, the lack thereof isn't causing me much pain either.

Delegates are generally somewhat of a yawn in my book as well, though I see the point to function pointer like semantics for function programming.

Closures seem like a good addition, including FCM-like semantics.  They're still not a univerally good addition, though.  They bring with them enormous complexity or enormous limitations -- depending on the proposal.  For instance, BGGA's non-local return semantics are very discordant and inconsistent with the inner class semantics.  It's control structure features are great for ease of writing and one level of readability, while a possible bane to any deeper comprehension.  You get cool looking stuff like forEachFoo(...), but it seems likely that many developers will have serious issues distinguishing what's a language control structure and what's a library one -- and how to follow/debug such control structures.  BGGA also has a thousand wrinkly corner cases to explain.  All that said, BGGA would also reasonably succinct type-safe expression of software concepts like LINQ.  Also it's exception transparency concepts are long overdue and would simplify things beyond closures themselves.

In the end, syntactic sugar bits are okay, but I can't see how everyone can get so excited about their presence -- or absence.  Major features like closures, particularly those that allow type safety to be maintained over a broader portion of the software, are grounds for getting excited, but also often have downsides that have to be considered.  More is not always better when you deal with large groups of developers -- as some may feel the need to use the craziest, most complex features they can, and produce code that is intractable to most the organization while others may have serious difficulty grasping complex language features period.  I believe closures make the cut -- they help more than they hurt, but it is a close thing...

--
Jess Holle

[Brett Ryan]

I don't think they are syntactic sugar, like I've mentioned previously
a Property isn't simply a wrapper around getFoo/setFoo methods, they
are a separate construct that does allow for type safety of some
state. If you're a component designer and you come across a class with
String getFoo(); void setFoo(Integer val) what do you do? Do you treat
Foo as a single read-only property of String or do you not show it at
all?

Properties are a 1-to-1 relationship of a classes member and the state
it's representing, currently we don't have this support in Java.
Trying to traverse the object graph to find what members are
properties is currently painful, I wrote an example the other day to
explain to a friend this fact (attached), if you never have to write
this sort of code then you're extremely lucky.

Registering a listener in Java isn't the main problem, it's a real
problem for a component author where you have to maintain a list of
listeners, then call them when the event occurs. You end up with at
least 15 lines of code, take a look at
javax.swing.AbstractButton.fireActionPerformed(ActionEvent) as a
classic example of this.

To properly get closures, you need function pointers, and that's why
we need them in Java, and with function pointers we can implement
proper events fairly easily.

I don't want to assume, but are most people who couldn't care for
events/properties server side developers? The real benefit to these
features is with statefull code, not so much with stateless, since
stateless code can't really listen to events in the first place.

-Brett

[kirk]

>
> Properties are a 1-to-1 relationship of a classes member and the state
> it's representing,

which is a violation of encapsulation and promotes unnecessary couplings.

> To properly get closures, you need function pointers, and that's why
> we need them in Java, and with function pointers we can implement
> proper events fairly easily.
>

You need to make methods first class citizens and then you can implement
closures properly. Exposing pointer is something we want to avoid IMHO.

> since
> stateless code can't really listen to events in the first place.
>

Why not?

Regards,
Kirk

[Brett Ryan]

@kirk

>> Properties are a 1-to-1 relationship of a classes member and the state
>> it's representing,
> which is a violation of encapsulation and promotes unnecessary couplings.

That 1-to-1 relationship is the encapsulation, and it's actually
promoting the point.

>> To properly get closures, you need function pointers, and that's why
>> we need them in Java, and with function pointers we can implement
>> proper events fairly easily.

> You need to make methods first class citizens and then you can implement
> closures properly. Exposing pointer is something we want to avoid IMHO.

To the casual C# programmer they wouldn't even know they were actually
using function pointers. The language takes care of

>> since
>> stateless code can't really listen to events in the first place.
>>
> Why not?

Well you can, but more so why would you? Events are more suited to
something that is going to hang around for a while in a state-full
fashion.

-Brett

[kirk]

Brett Ryan wrote:
> @kirk
>
>
>>> Properties are a 1-to-1 relationship of a classes member and the state
>>> it's representing,
>>>
>> which is a violation of encapsulation and promotes unnecessary couplings.
>>
>
> That 1-to-1 relationship is the encapsulation, and it's actually
> promoting the point.
>

Encapsulation is about information hiding. If you directly expose the
type, you've violated encapsulation. Properties are good at the edge of
a system where you are forced to expose internal state. it my my humble
opinion that properties have little business away from the edges.

>
>
>>> To properly get closures, you need function pointers, and that's why
>>> we need them in Java, and with function pointers we can implement
>>> proper events fairly easily.
>>>
>
>
>> You need to make methods first class citizens and then you can implement
>> closures properly. Exposing pointer is something we want to avoid IMHO.
>>
>
> To the casual C# programmer they wouldn't even know they were actually
> using function pointers. The language takes care of
>

I'm all for making methods a first class citizen in the language. A
method should be an object. For that matter, a class should be an object.

>
>>> since
>>> stateless code can't really listen to events in the first place.
>>>
>>>
>> Why not?
>>
>
> Well you can, but more so why would you? Events are more suited to
> something that is going to hang around for a while in a state-full
> fashion.
>

I can think of a number of architectures that was both stateless and
event driven and I've even implemented a few of them. Some of the
EIPatterns are both event centric and stateless. This is how they are
able to scale.

Regards,
Kirk

[Jess Holle]

Brett Ryan wrote:

I don't think they are syntactic sugar, like I've mentioned previously
a Property isn't simply a wrapper around getFoo/setFoo methods, they
are a separate construct that does allow for type safety of some
state. If you're a component designer and you come across a class with
String getFoo(); void setFoo(Integer val) what do you do? Do you treat
Foo as a single read-only property of String or do you not show it at
all?
  

I believe that's well defined by the JavaBeans spec.  If not, it should be.

There's no reason that the getter/setter conventions from the JavaBeans spec cannot be interpreted in just as type-safe a manner as some official "Property" construct.

I will not argue that the current state of affairs is anywhere near perfect here in Java.  For starters:

1. One should be able to use properties more directly in a type-safe manner (e.g. via an -> operator)
• The Java compiler would understand JavaBeans as components and do type-safe usage thereof -- rather than forcing one to go through reflective APIs.
  
2. One should be able to communicate details to JavaBeans metadata more easily, e.g. via annotations

Properties are a 1-to-1 relationship of a classes member and the state
it's representing, currently we don't have this support in Java.
  

Ack! 1-to-1 relationship with members?!?  I have lots of classes where this would be hugely inappropriate.

Trying to traverse the object graph to find what members are
properties is currently painful, I wrote an example the other day to
explain to a friend this fact (attached), if you never have to write
this sort of code then you're extremely lucky.
  

Why did you do this mess rather than just using the JavaBeans Introspector?  Generally if it does not answer the question I've found that I don't need the answer -- but again I'm not claiming it is perfect.  Rather it should simply be improved as/where needed.

Registering a listener in Java isn't the main problem, it's a real
problem for a component author where you have to maintain a list of
listeners, then call them when the event occurs. You end up with at
least 15 lines of code, take a look at
javax.swing.AbstractButton.fireActionPerformed(ActionEvent) as a
classic example of this.
  

There should certainly be a better utility class than EventListenerList at this point, yes, I'll agree 100%.  This API is clumsy and obnoxious, but that really argues for an API improvement in my book -- there's no need for a language change to solve this problem.

To properly get closures, you need function pointers, and that's why
we need them in Java, and with function pointers we can implement
proper events fairly easily.
  

Hmmm.... I don't actually see anything wrong with listener interfaces.

I see plenty of use cases for function pointers elsewhere, though -- albeit mostly in domains that overlap with closures.

I don't want to assume, but are most people who couldn't care for
events/properties server side developers? The real benefit to these
features is with statefull code, not so much with stateless, since
stateless code can't really listen to events in the first place.
  

I've done client, server, beans, mbeans -- a little of everything.  I understand that immutability is a great goal, but is utterly unrealistic in some domains, e.g. client/bean/mbean code.

--
Jess Holle

[Jess Holle]

Brett Ryan wrote:

@kir

Properties are a 1-to-1 relationship of a classes member and the state
it's representing,
      

which is a violation of encapsulation and promotes unnecessary couplings.
    

That 1-to-1 relationship is the encapsulation, and it's actually
promoting the point.
  

Not really...  For instance, just yesterday I had a String property exposed in my bean/mbean that for internal efficiency I ended up keeping the original string (for the getter) but also producing a Set<String> and a Collection<String>.  I certainly did not want all this exposed in my bean/mbean's interface!  This is an internal implementation detail that is currently the best performance balance, but may change over time.

You need to make methods first class citizens and then you can implement
closures properly. Exposing pointer is something we want to avoid IMHO.
    

To the casual C# programmer they wouldn't even know they were actually
using function pointers. The language takes care of
  

First class methods are roughly the same as delegates which are essentially the Java/C# equivalent of function pointers.

since stateless code can't really listen to events in the first place.
      

Why not?
    

Well you can, but more so why would you? Events are more suited to
something that is going to hang around for a while in a state-full
fashion.
  

There are plenty of good use cases for a stateless listener, but clearly UI's involve state no matter how you try to avoid it :-)

--
Jess Holle

[Brett Ryan]

>>>> Properties are a 1-to-1 relationship of a classes member and the state
>>>> it's representing,
>>>>
>>> which is a violation of encapsulation and promotes unnecessary couplings.
>>>
>>
>> That 1-to-1 relationship is the encapsulation, and it's actually
>> promoting the point.
>>
> Encapsulation is about information hiding. If you directly expose the
> type, you've violated encapsulation. Properties are good at the edge of
> a system where you are forced to expose internal state. it my my humble
> opinion that properties have little business away from the edges.

Encapsulation is exactly what properties provide. Take the following
encapsulation of member variable foo:

private int foo;
public int Foo {
get { return foo; }
set {
if (value < 0)
ArgumentOutOfRangeException("Value for property Foo must be >= 0");
foo = value;
}
}

-Brett

[Brett Ryan]

@Jess Holle

> There are plenty of good use cases for a stateless listener, but clearly
> UI's involve state no matter how you try to avoid it :-)

Point taken ;-)

[kirk]

>>
> First class methods are roughly the same as delegates which are
> essentially the Java/C# equivalent of function pointers.

Sure and the point is roughly. So pardon my language nit but I'd much
rather talk about methods as first class objects than function pointers. ;-)

Regards,
Kirk

[kirk]

>
> private int foo;
> public int Foo {
> get { return foo; }
> set {
> if (value < 0)
> ArgumentOutOfRangeException("Value for property Foo must be >= 0");
> foo = value;
> }
> }
>

private int foo;

public int getFoo() { return foo; }
public void setFoo( int value) {

if (value < 0)
ArgumentOutOfRangeException("Value for property Foo must be >= 0");
foo = value;
}

Maybe I've missed the point but.... :-)

Regards,
Kirk

[Brett Ryan]

Yes, these two are vastly different, as I've expressed earlier you
can't simply identify a property on a Class, take my attached example
a few posts ago and you'll see what I mean.

When you traverse Foo.class.getDeclaredMethods() that match a pattern
of set|get.* and then pair the two up as a property. as also
mentioned, what if getFoo returned a String, while syntactically
correct, this is not type safe.

get/set methods hide the implementation, but they don't enforce the
fact. A property enforces this by exposing the get/set as one.

-Brett

+ Correction, I forgot the "throw" statement on the exception above.

[Jess Holle]

Brett Ryan wrote:

Yes, these two are vastly different, as I've expressed earlier you
can't simply identify a property on a Class, take my attached example
a few posts ago and you'll see what I mean.

When you traverse Foo.class.getDeclaredMethods() that match a pattern
of set|get.* and then pair the two up as a property. as also
mentioned, what if getFoo returned a String, while syntactically
correct, this is not type safe.

get/set methods hide the implementation, but they don't enforce the
fact. A property enforces this by exposing the get/set as one.
  

Er, you might not like the JavaBeans APIs, etc, but they do all of this.

I won't claim the JavaBeans area does not need improvement (as per my previous posts on this thread), but it is disingenuous to claim that we don't already have properties today that unify getters and setters appropriately.  Just because the means of attaining them are not the same syntactic sugar you see in another language does not mean that (a) they're not there and (b) that they're not usable.

--
Jess Holle

[Jess Holle]

Jess Holle wrote:

There's no reason that the getter/setter conventions from the JavaBeans spec cannot be interpreted in just as type-safe a manner as some official "Property" construct.

I will not argue that the current state of affairs is anywhere near perfect here in Java.  For starters:

1. One should be able to use properties more directly in a type-safe manner (e.g. via an -> operator)
• The Java compiler would understand JavaBeans as components and do type-safe usage thereof -- rather than forcing one to go through reflective APIs.
  
2. One should be able to communicate details to JavaBeans metadata more easily, e.g. via annotations

Note that JMX 2.0 (targeted for Java 7) introduces annotations along the lines of (2) for MBeans.  What's missing is such annotations for JavaBeans.

--
Jess Holle

[Brett Ryan]

But it's not baked into swing and other areas where a component model
is needed, there maybe API's out there, but they aren't something I
can discover. If I'm given a component from some component author who
has quite simply developed some swing control, how do I place that
control on a designer and be able to expose the properties of that
component? Exposing events aren't as bad although not as easy as if we
had true events.

In the end we do something like the attached example I posted a few
posts ago that iterates over the classes declared methods. Even still,
I've just realised my example doesn't take the Boolean `is' into
account.

http://bean-properties.dev.java.net may be one solution, but whatever
the solution is the actual components need to be unified to support
property discovery.

If you do have a way to unify getters/setters into a property without
having to try and discover them I'd be interested to see.

-Brett

[kirk]

>>
>> Maybe I've missed the point but.... :-)
>>
>
> Yes, these two are vastly different, as I've expressed earlier you
> can't simply identify a property on a Class, take my attached example
> a few posts ago and you'll see what I mean.
>
> When you traverse Foo.class.getDeclaredMethods() that match a pattern
> of set|get.* and then pair the two up as a property. as also
> mentioned, what if getFoo returned a String, while syntactically
> correct, this is not type safe.
>
> get/set methods hide the implementation, but they don't enforce the
> fact. A property enforces this by exposing the get/set as one.
>

Sorry, but I just can't see what you are trying to achieve with this
that I can't already achieve.

Regards,
Kirk

[kirk]

>
> If you do have a way to unify getters/setters into a property without
> having to try and discover them I'd be interested to see.
>

First, I don't necessarily want to expose get/set methods. Second I
don't necessarily want clients to discover them. That said, Swing is at
the edge of the system as is JPA, distributed system calls. As I
mentioned, things at the edge of a system need to have access to
internal state and representation. That said you still need to be
careful not to invert your lines of dependency. Using set/get or even
properties for that matter is a great way to invert lines of dependency.
Better to use a system of double dispatch such as is used with
serialization.

IMHO, events and listeners should have been baked into the class
hierarchy as they are in Smalltalk. This simplifies things enormously.

Regards,
Kirk

[Weiqi Gao]

Brett Ryan wrote:
>
> But it's not baked into swing and other areas where a component model
> is needed, there maybe API's out there, but they aren't something I
> can discover. If I'm given a component from some component author who
> has quite simply developed some swing control, how do I place that
> control on a designer and be able to expose the properties of that
> component? Exposing events aren't as bad although not as easy as if we
> had true events.
>
> In the end we do something like the attached example I posted a few
> posts ago that iterates over the classes declared methods. Even still,
> I've just realised my example doesn't take the Boolean `is' into
> account.
>
> http://bean-properties.dev.java.net may be one solution, but whatever
> the solution is the actual components need to be unified to support
> property discovery.
>
> If you do have a way to unify getters/setters into a property without
> having to try and discover them I'd be interested to see.

The call

Introspector.getBeanInfo(Foo.class).getPropertyDescriptors()

will give you all the properties on the class Foo, their name, type,
getter, setter, bound-ness, constrained-ness, PropertyEditor, etc.

And according to it, your earlier example

class Bar {
public String getFoo() { return ""; }
public void setFoo(int val) {}
}

has a read only property named "foo" of type String.

The JavaBeans spec was written when AWT was still being hyped heavily,
and Java people were dreaming of a drag-and-drop type of GUI painting
paradigm. Anyone remember Bongo? I'm sure it would qualify as a Java
app of the week had the JavaPosse been on the air then.

Java did not dominate in GUI development. Looking back, that's when a
nice developer box have 16MB, maybe 32MB RAM, and production servers
have 64MB RAM. My VB5 developer colleagues were laughing their heads
off when I downloaded Swing 0.3 (or 0.4) and the SwingSet demo started
up in 20 minutes!

--
Weiqi Gao
weiq...@gmail.com
http://www.weiqigao.com/blog/

[Jess Holle]

The JavaBeans Introspector and BeanInfo APIs do all of this.  If you're not using them yet dealing with Java components then you're missing the boat.

http://bean-properties.dev.java.net may be one solution, but whatever
the solution is the actual components need to be unified to support
property discovery.

If you do have a way to unify getters/setters into a property without
having to try and discover them I'd be interested to see.
  

Again, just use the JavaBeans APIs -- that's what they're there for.

--
Jess Holle

[Brett Ryan]

@Weiqi

Do you like using Introspector? ;) Okay it might be a tongue in cheek
question, but I'd still much prefer being able to do
foo.getDeclaredProperties() and have a PropertyDescriptor array
returned without the penalty of the Introspector having to go and
discover them.

-Brett

[Brett Ryan]

What I'm trying to get at is we don't have type safety in properties.
Introspector is simply a convenience to find our assumed properties
for us. It's not part of the language but part of the class libraries
that come with the language.

I think we've gone off on a tangent ;)

-Brett.

[Jess Holle]

Brett Ryan wrote:

@Weiqi

Do you like using Introspector? ;) Okay it might be a tongue in cheek
question, but I'd still much prefer being able to do
foo.getDeclaredProperties() and have a PropertyDescriptor array
returned without the penalty of the Introspector having to go and
discover them.
  

Performance of discovery is perhaps grounds for improvement.  I can't say -- if it is, then that can be fixed without changing the API.

The difference between

Introspector.getBeanInfo( Foo.class ).getPropertyDescriptors();

and

Foo.class.getBeanInfo().getPropertyDescriptors();

and

foo.getBeanInfo().getPropertyDescriptors();

is immaterial in my book.

Actually I'm rather glad it is not the last of these.  java.lang.Object clutter up the method namespace enough without something like this that could be better provided via a method on java.lang.Class or via a separate factory class ala Introspector.

I won't say Introspector is perfect, but it works, does better than ad hoc scraps of code like that you attached, and has been built into the core Java libraries for many years.

--
Jess Holle

[Brett Ryan]

Okay, so wheres the answer for compile time safety?

My attached ad-hoc code was not meant to be used, it was to
demonstrate what Introspector or any other inspector needs to do to
discover properties. What you get back are `assumed' properties (if
BeanInfo classes haven't been defined).

-Brett

[Jess Holle]

The difference between Introspector and the language really is irrelevant to a degree.

If the Introspector and JavaBeans APIs provide suitable capabilities and type-safety, then we're set in my book.  If not, then add them -- don't invent something else entirely.

If we want type-safe usage thereof from the language or compiler (e.g. a "->" operator), then add that as needed.

Personally I think the "->" operator is just kind of silly syntactic sugar that's not worth chasing much (and having "." do some magic in the area is pure insanity).

I'd really like to see annotations on methods that automatically clue in Introspector, though -- rather than having to mess with BeanInfo directly, which is not fun in my book.  [For instance, telling JavaBeans persistence that a property is transient should only require an @Transient or some such on the getter or setter, not silly BeanInfo mucking.]  I suppose one of the benefits of Introspector being a factory method is that one can create one's own my.new.improved.Introspector that does understand such annotations, though.

--
Jess Holle

[Jess Holle]

The examples given for C# showed shorthand for expressing properties but showed nothing in the way of actually improving type safety.

Moreover, being able to use foo->bar rather foo.getBar()/foo.setBar() is also just sugar -- the latter are perfectly type safe.

[Brett Ryan]

Sure there's type safety there... The compiler will ensure the get and
set are both of the same type, otherwise you get a compile time error.
How much more type safety could you get than that?

[Weiqi Gao]

Brett Ryan wrote:
> @Weiqi
>
> Do you like using Introspector? ;) Okay it might be a tongue in cheek
> question, but I'd still much prefer being able to do
> foo.getDeclaredProperties() and have a PropertyDescriptor array
> returned without the penalty of the Introspector having to go and
> discover them.

I don't disagree with you.

Like I said, the JavaBeans API was written in another era for a
destination that Java eventually did not go. The hype was that in a
couple years, you could buy ready made components on the commercial
market and plug them into your Visual Cafe's GUI painter palette.

I will welcome properties and events support in the language level in
Java. And I will use those features if and when they become available
and their usage appropriate to the task at hand.

Before then, the JavaBeans framework is the closest approximation.

It's one thing to be enthusiastic about adding your favorite features
into the language. It is entirely a different thing to carry out your
daily work with the language and tools as they exist now.

Are we done with discussing properties? Can we move on to

+ closures: BGGA, CICE, FSM, anyone?

+ generics: The Wall of Erasure? Reifications?

+ XML literals

+ Regular expression literals

+ Multi-line strings

+ Removing wait(), notify(), notifyAll() from java.lang.Object

+ Putting Groovy into the JDK

+ Putting Google Guice into the JDK

+ Removing AWT Widgets from the JDK

+ Removing the HTML 3 parser/renderer from the JDK

+ Adding all 694 Apache Commons jars into the JDK, I'm tired of
getting them one by one by one by one by one....

+ Heck, why don't we put Ant into the JDK? Maven?

+ And ANTLR. And don't forget to rewrite javac to use ANTLR

now?

[Jess Holle]

Weiqi Gao wrote:

Are we done with discussing properties?

Well, it might be interesting if anyone had proposals that were more than skin deep syntactic sugar.

I haven't seen anything that really improves substantively over what one would have by some sprucing up of JavaBeans APIs and some BeanInfo-driving annotations.

Can we move on to

   + closures: BGGA, CICE, FSM, anyone?
  

BGGA is fine by me.  I think it will hurt almost as much as it helps, but let the hurting -- and helping -- begin :-)  It will keep life interesting.

   + generics: The Wall of Erasure?  Reifications?
  

I thought the recent Posse episode was most curious here.  They couldn't speak specifically to the implications of erasure.  I wonder how many people are actually greatly impacted by erasure.

I use and produce a fair number of generic APIs and have to say erasure does not hurt me most of the time.  I'd certainly rather have the ability to mix and match old and new code than reification if it is an either/or choice.  If there was a way to allow runtime access to generic types of instances without unnecessarily breaking the ability to mix and match old code (e.g. getting at the generic types might simply return 'null' when old code created the instance and gave no types), I'd be all for it, though.

   + XML literals
  

Just say no!  Next it will be literals for CSS, and my favorite non-Java niche grammar du jour.  XML isn't that holy or special.

   + Regular expression literals
  

These would be kind of nice, but are not a huge deal either.

   + Multi-line strings
  

Yawn.  The + trick works fine in my book.

   + Removing wait(), notify(), notifyAll() from java.lang.Object
  

Yeah, right.  What strange "I want to break most software of size ever written in Java" language are you living on?

   + Putting Groovy into the JDK

   + Putting Google Guice into the JDK
  

Why?  The JDK is intrinsically slow moving due to the standards process, platform porting (you have to wait years for a new JDK on the Mac or on AIX), etc.  Keeping things outside the JDK keeps them faster and gives more freedom.

   + Removing AWT Widgets from the JDK
  

Again, you just want to break software for no reason, right?  Putting these in a separate lazily loaded jar, marking these as deprecated, hiding them in the default Javadoc view, etc, would be good.  Removing them outright has no upside and serves only to break software.

   + Removing the HTML 3 parser/renderer from the JDK
  

Sure, if replacing it with an HTML 4 one :-)

   + Adding all 694 Apache Commons jars into the JDK, I'm tired of 
getting them one by one by one by one by one....

   + Heck, why don't we put Ant into the JDK?  Maven?
  

No!  People complain about the core Java API set being bloated and now you want to include your arbitrary set of bloat?  Where things are already separate and can remain so without harm, they should be.

   + And ANTLR.  And don't forget to rewrite javac to use ANTLR
  

I can't speak to the wonders of ANTLR, but I'd generally think javac's implementation details should be hidden to allow for future flexibility of implementation.

--
Jess Holle

[Patrick Wright]

I think that, in principle, Java could be extended in interesting ways
and could take cues from other languages (including, sure, C#), but
lately I'm tending to agree with Josh Bloch that Java's complexity
budget is used up. Every change at this point seems to imply a great
risk to instability (or unexpected side-effects) somewhere else in the
language or the library ecosystem.

Another issue--and I'm not sure how MS addresses this--is that it's
becoming very hard for any new proposal for changes to the language to
gain much traction at this point; there's too much disagreement on
each proposal (including, in the last year+, both properties and
closures) and that makes it hard to build any real consensus. A lot of
anger comes up in these discussions, and there are certainly those who
would like to roll the releases back to 1.4, as well as those who
would like Java the language to move forward aggressively. These
people simply aren't finding common ground. So my guess is, Sun would
have to try and "pull a JCP" and just dictate what the changes would
be. But then, look at how much controversy Java 5 caused, for example;
I think they just don't want to go through that again.

It may be more realistic to freeze Java-the-language in the near
future, and see what other language (perhaps on the JVM, for those of
us who like the ecology around it) can build out in new directions
without a lot of baggage to answer for. Java will continue to be used
for a long time, and people will just continue to live with its
limitations, methinks.


Regards
Patrick

[RogerV]

On Nov 4, 6:10 am, "Brett Ryan" <brett.r...@gmail.com> wrote:
> I don't want to assume, but are most people who couldn't care for
> events/properties server side developers? The real benefit to these

> features is with statefull code, not so much with stateless, since

> stateless code can't really listen to events in the first place.
>

> -Brett

Even on the server-side I'd enjoy having the ability to class
properties that are JavaBean compliant to getter/setter/is convention.

Why?

Because iBATIS maps parameterMap and resultMap data values using the
JavaBean convention for Java class properties.

So even on the server-side, nice support of properties in Java
matters. It's not solely a client-side GUI component thing.

[djvoracious]

Good overview Brett,

Personally, being a MS fan, I have to put my hat down to Java
developers for a while now. MS saw that Java was such a good language,
but saw that there were things about the language that could have been
better. Thats what Sun sadi about C++.

Like with many evolutions of a product, it constantly undergoes
refinements. Maybe before you know it, Sun will be ripping off some
concepts from MS and will put them into a new version.

Personally, I like C# and Java, but most of the work that I get is for
large companies with many MS technologies....consequently, C# is the
preferred way forward.

On Nov 2, 9:56 pm, "brett.r...@gmail.com" <brett.r...@gmail.com>
wrote:
> I'm not trying to set myself up for flaming here, so please read on.
> The reason I started off with this topic is that I see a great deal of
> `we need feature {x} implemented in Java' and then a whole host of
> solutions to the problem and then large debates over them.
>
> Again, not looking for flame wars, but I honestly think that C# is a
> brilliant language, Anders Hejlsberg truely knows what he's doing in
> this realm. There are three points to the C# language that they really
> got right that Java needs to learn from, and why not just take the
> exact same implementation?
>
> 1. Properties: Properties are so freaking simple in C# that it just
> isn't funny any more. Take the following examples of C# properties.
>
>     // A traditional property
>     private String name;
>     public String Name {
>         get { return name; }
>         set { name = value; }
>     }
>
>     // This can be simplified since it's such a normal property not
> performing
>     // any logic, the compiler will generate the field and accessors
> for the field for us.
>     public String Name { get; set; }
>
>     // We can then make this a readonly property by applying a set
> accessor.
>     public String Name {
>         get;
>         protected set;
>     }
>
> 2. Events: I don't want to elaborate too much here, but they're
> similar to properties syntactically, they simply allow "subscribing/
> unsubscribing" function pointers.
>
>     // Declare an event
>     public event EventHandler<MyEventArgs> MyEvent;
>
>     // Or you can control access tot he event via add, and remove
> notation as is for
>     // Properties
>     private event EventHandler<MyEventArgs> myEvent;
>     public event EventHandler<MyEventArgs> MyEvent {
>         add { myEvent += value; }
>         remove { myEvent += value; }
>     }
>
>     // Subscribing a function pointer is very simple also,
> `DoMyEventFired' is a
>     // function pointer matching the contract of `void (Object,
> MyEventArgs)'
>     MyEvent += new EventHandler<MyEventArgs>(DoMyEventFired);
>     // Unsubscribing is the same, just with -=
>     MyEvent -= new EventHandler<MyEventArgs>(DoMyEventFired);
>
> 3. We all know that generics were not really implemented that well in
> Java, but simply take a look at how they were solved in C#, we don't
> have the problems of type erasure, they're also easier to understand.
>
> I love Java, but we need the above, if we don't get the above we're
> going to fall behind. There's many more that C# has like type
> inference. Now with C# 3.0 and 3.5 we're starting to really fall
> behind, take the following:
>
> 1. Use of the keyword `var' on the left hand side of a scoped field
> declaration the compiler knows what the type is based on the right
> hand side.
>
>     // In the following "myComplex" is still statically typed, the
> beauty of it is in the
>     // compiler working out the type for us through implicit type
> inference, var is inferred
>     // from the right hand side.
>     var myComplex = new Dictionary<String, List<String>>();
>
>     // thus we can use this as:
>     foreach (var val in myComplex.entrySet()) {
>         // val is inferred to be of type `List<String>', so the
> following will throw a compiler error
>         foreach (String str in val) {
>         }
>     }
>
> 2. Extension methods, please don't implement the way suggested athttp://tech.puredanger.com/java7/, take a look at this instead. Please
> not that because `you' get to control the behavior it makes it easier
> to understand what's going on.
>
>     // Basically we need to explicitly declare an extension method to
> be used by
>     // declaring a static class with a static method taking the `this'
> keyword as a param.
>     public static class MyNumberExtension {
>         public static double Pow(this double x, double y) {
>             return Math.Pow(x, y);
>         }
>     }
>
>     // With this the following two are equal
>     double resStd = Math.Pow(2, 2);
>     double resExt = 2.Pow(2);
>
> There are many more `features' of C# that I think we can learn from in
> Java. Too many people I talk to have the attitude of "why look at C# I
> never want to write programs for windows", well, I don't want to write
> programs for windows either, but if they're standing on our shoulders
> for the language perspective we need to have a rugby match with them
> and actually compete.
>
> Please don't dismiss this post as trying to start a flame war, I
> really think Java can become so much more than it is. These abilities
> make the component model in C# soooo easy to program against, you end
> up with unexpected things like visual inheritance and a greater
> flexibility for annotating that is accessible via reflection at
> runtime making a vendor writers job as simplistic as it needs to be.
>
> Please also forgive me for the length of this post.

[BoD]

Nice list.
I'd add language-level support for maps.

Isn't there a site somewhere with a list of suggested improvements for
the language, where people can vote for the ones they want?

BoD

[Pete F]

tee hee

infoq has a new video of Microsoft's Mads Torgersen, at *of all
places* the JVM language summit, quipping *of all things* about them
"not having c# running on the jvm yet"

for people allergic to microsoft, the video is a good place to see
what their take on java next is, without leaving home

Brett writes

>>
LINQ is basically some syntactic sugar over Lambda expressions that
have been in the language since 2.0
<<

No No No No, yes

-but not really

linq is a lot more than that, but it required the lambda expressions
yes

it is a while bunch of things under one name, but is a serious attempt
to unify oo programming and query -whilst nudging the formaer towards
a more functional style

watch the Mads Torgersen presentation rather than accept my mangled
description (there is also an interview with erik meijer on se-radio
(bad audio, great guest))

i would add that what linq is *really* about -is microsoft FREAKING
OUT over many-core, realising that they have to solve the problem
before other, more server centric platforms (where the users helpfully
tend to come to the processors), hiring Haskell heads like Meijer, to
sit in a bar and have ideas about monadic programming in VB -and
putting the results in the languages


if you like Mads (he is one of the more likeable ms people imo) grit
your teeth, go to ms channel 9, and find an interview from jaoo with
Gilad Bracha, Erik Meijer and Mads -he comes across as the straight
guy (who wouldn't with Bracha and Meijer sparring away) but makes some
refreshing candid comments, which gives me some hope for the evil
empire

Pete F

[RogerV]

I invited Mads Torgersen a couple of years ago to come speak about
LINQ to the Seattle Java Users Group. He told us that his background
prior to working for Microsoft was as an academic researching computer
language ideas with Java.

[Casper Bang]

I went to a few of his lectures, he was dabbling on use-site co-
variance for Java at the time which eventually made it into Tiger. I
therefore suspect he might have had something to do with providing
definition-site co-variance in C# 4.

/Casper

[Reinier Zwitserloot]

I can't speak for anyone else but myself, I know about most of those
C#isms.

I just don't agree with them, -especially- considering that the
history of java and the 'feel' of java is different from C#. Even
though C# started as a java rip-off, what works for C# doesn't
necessarily work for Java.

For example:

A. Properties/event listeners: Seems overkill to me; if I actually
need special setter/getter code, beyond the simple stuff, I'll just
write an explicit 'set'/'get' method. Once there's no need for the
ability to add code blocks, you can come up with cleaner and simpler
syntax. A way to specify that any given variable needs one or more of
the following set; {getter, setter, event listener hooks}, is all
that's needed.

B. C# does not have generics erasure. Do you really think that the
java5 engineers tossed erasure in there for kicks? Its there because
sun has an unhealthy obsession with compatibility. We all -know- about
erasure - any discussions about solutions involve how to make it
compatible and/or solutions for making transitions easy. If you say
you're not trying to set up for a flame war, then why the heck do you
include such a stupid 'suggestion' about C# having a 'solution'?

C. val and var. var is a dumb idea. val is a fine idea, but there's no
reason to add another keyword when 'final' would do just as easily.

On Nov 2, 3:56 am, "brett.r...@gmail.com" <brett.r...@gmail.com>

[gafter]

On Nov 4, 3:40 pm, Patrick Wright <pdoubl...@gmail.com> wrote:
> I think that, in principle, Java could be extended in interesting ways
> and could take cues from other languages (including, sure, C#), but
> lately I'm tending to agree with Josh Bloch that Java's complexity
> budget is used up. Every change at this point seems to imply a great
> risk to instability (or unexpected side-effects) somewhere else in the
> language or the library ecosystem.
>
> Another issue--and I'm not sure how MS addresses this--is that it's
> becoming very hard for any new proposal for changes to the language to
> gain much traction at this point; there's too much disagreement on
> each proposal (including, in the last year+, both properties and
> closures) and that makes it hard to build any real consensus. A lot of
> anger comes up in these discussions, and there are certainly those who
> would like to roll the releases back to 1.4, as well as those who
> would like Java the language to move forward aggressively. These
> people simply aren't finding common ground. So my guess is, Sun would
> have to try and "pull a JCP" and just dictate what the changes would
> be. But then, look at how much controversy Java 5 caused, for example;
> I think they just don't want to go through that again.

I'm a Java programmer, and I'm learning C#. I was also a designer and
implementer of language features for Java, and now I'm doing that for
C# as a member of MS's language design team. C# is not more suited to
further evolution than Java, but it continues to evolve quite
successfully. So I can tell you exactly how MS addresses this.

The perception that Java's complexity budget is used up, and that the
language is too brittle to undergo further evolution, arises commonly
among people who think themselves capable of language design but who
don't really have the background, training, or skills to do it. If
they attempt to draft or implement language proposals, when the
feedback arrives they realize there were many interactions that they
didn't consider, and that the task is far more difficult than they
thought. From this they come to the incorrect conclusion that the
language has become too complex and further evolution is impossible.
A related effect is that nonprofessionals sometimes mistake a formal
specification for a user guide, concluding that properly proposed
changes would be too difficult to use. Language design is not easy,
and like many other fields requires a great deal of work by
professionals. The ideal end product seems intuitive and easy to use,
but that hides the effort that went into creating it, resulting in the
false impression that language design is easy.

The Java language is well suited to further evolution, provided that
the language design is done by professionals with the appropriate
skills. Most important is to have a single individual or a small like-
minded team responsible for the decisions to ensure consistency of the
whole. Language design is not a community exercise suitable for a
large-scale democratic process. Unfortunately, Sun doesn't seem
willing to invest in the resources to make it happen. That, more than
anything else, is the obstacle to the language's evolution.

Regards,
Neal

[Peter Becker]

Hear hear.

--
What happened to Schroedinger's cat? My invisible saddled white dragon ate it.

[Reinier Zwitserloot]

Java the platform is also evolving by way of having a JVM common
ground and introducing multiple languages that compile down to it.
Replacing a language with another is slightly less nuts if both
languages compile to the same intermediary and are easily
interoperable. But, going back to java-the-language for a moment:

What java really needs is a magic backwards compatibility.

I know of no language that even tried, and java in general tries to
avoid new territory, but clearly, that seems to be where java needs to
go if everyone thinks the complexity budget is used up. A way to be
backwards compatible while being able to change just about everything
in the language.

This doesn't even seem completely ridiculous to create, either. I
haven't thought it all the way through, but, here's an overview:

1. You split the problem into 'language' and 'library' backwards
compatibility.

2. You solve language compatibility by introducing a mandatory
'source' keyword (only legal before the first package/import
statement). Anything lacking a source parameter is assumed to be
targetted first at the supplied -source parameter to the compiler, and
if that isn't there, the most recent version of java that didn't have
the source keyword (let's say java7). Want to make '==' be syntax
sugar for .equals, and relegate actual object reference identity to
some library call, because, lets be honest here, you hardly ever use
that - go right ahead. We have this, very lightly, in the form of the -
source parameter today, but it could do with some more improvement,
and with a 'source' keyword you could make a few breaking changes.

3. Then you worry about solving this problem in library space.
Currently java doesn't try to solve this problem at all; you can
compile against an older standard (-source) and produce older-format
class files (-target), but you'll be using the libraries of the java
version you start the program with, regardless of the -source or -
target parameter. If something works differently now, or has been
removed, all java classes, past and present, compiled against whatever
you specified, won't work if they depended on that. Hence the golden
rule in java core libraries today: You can't mess things up. You can
only add. We can't 'fix' naming mistakes like renaming 'plus' to 'add'
in BigInteger and BigDecimal. We can't spin corba out to a separate
library (you can solve removal by detecting usage and live-downloading
the dependencies, but that still doesn't allow us fine grained control
of fixing things). We can't even remove Vector and Hashtable, and we
can't even make the simple change of rewiring java.util.Property's
getMap() method to return a Map of <String, String>, which properties
clearly are, just in case some idiot decided to take that map and
stuff non-strings in it in some misguided attempt at brevity. Sun
takes this backwards compatibility -that- seriously.

I can envision a library system that can make it work, though: Any
library ships as the 'canonical' representation, which is usually the
latest and greatest version, along with wrappers. A wrapper wraps FROM
a version TO a version. The system is smart enough to wrap wrappers to
make longer jumps - if your canonical API version is v3, you've got
your v3 to v2 wrapper, and you still have your old v2 to v1 wrapper,
the system will wrap v3 through v2 to v1 if some code expects v1. The
wrapper must handle every possible manipulation - if one particular
class file is expecting v1 of the library and creates a new instance,
it will call the wrapper's special 'constructor' factory method, which
will eventually construct a canonical (v3), and return it. Anything
the class tries to do with this canonical is always run through the
wrapper - the wrapper dictates what API it has, not the canonical, and
is even able to tack on an extra shadow object for extra attribute
storage if need be.

You can't just ship a different version of the library the way OSGi
does - because if you do that, you can't interoperate old code with
new code. The beauty of wrappers is that the v1-expecting code can
create an object using the v1 API, then pass this object off to a
library which is far more recent and expects the v3 API, and it would
just work, because the moment the object is manipulated by the newer
class, a different wrapper is used. The only burden is specifying
which API you want. IDEs can lock it down for you as you type. Library
updates can even ship with jackpot-like refactor rules which attempt
to automatically update vX expecting code to vX+1 expecting code, with
all IDEs being able to run these rules because they are standard.
Wrappers can even have different @Deprecated markings. If you
deprecated something because its fundamentally dumb (security leak,
could cause deadlocks like Thread.stop, etc), you can stick the
@Deprecated in the wrapper to the old API, so people recompiling old
code still get the warning, but if you deprecated it because you're
evolving the API, but a certain way of working is still so popular you
don't want to immediately force everyone that can't change this easily
to use a wrapper, you leave it out, because, obviously, if someone
wants to change the code, they'd set up their code to expect a newer
version.

Libraries aren't required to provide wrappers, but it gives an out for
libraries which have become so entrenched that making breaking changes
pisses off more people than its worth. First and foremost are of
course the java core libraries.

I would introduce the source keyword, this library system, and a bunch
of not-very-breaking language-level changes, without changing the
library much except for very obvious edge cases, first. Let's say this
is java 8. Let the kinks be worked out, and then the only thing you do
for java 9 is a massive retooling of some of the most offending
libraries. If the community accepts that, you've got carte blanche to
take the language to where-ever you think it needs to go, and adding
things to the language that are made difficult primarily because of
library code (non-nullness, reifiable generics) becomes a breeze as
well. Even worrying about developer mindset (the third concern in
breaking APIs and languages is that people need to learn the new ways)
is now mostly moot, because those that don't want to change will
simply be told to stick with the old version - no harm, no foul, they
can interop with newer code perfectly, they can upgrade their library
usage on a case-by-case basis. You don't even need to spend much time
on maintaining old versions: After all, they are really using the
newer version (or can, anyway) - as long as your wrapper works, their
code never notices.

It would also posit java as having a unique position - it would be the
only language that offers tools to transparently evolve code while
staying 100% compatible with whatever is out there, where old and new
code is 100% interoperable.

[Casper Bang]

Something like that would be much more interesting and beneficial than
the JavaFX Sun is current betting on. It would also set them apart
again from competition which frankly we haven't seen since the 90's.
If getting it right the first time is so difficult (and obviously it
is), there should be mechanisms in place to rectify this and not just
a paralyzing commitment to backwards compatibility.

On a related note, let me just point out the code transformation stuff
proposed by Jaroslav Tulach and Jan Lahoda (NetBeans core ppl) which I
think could deserve mentioning by The Java Posse:
http://netbeans.dzone.com/news/transformation-code-transforma

/Casper

> ...
>
> read more »

[phil.s...@gmail.com]

yes. I've noticed the best/most successful projects are usually a
small team of really smart people. Not design by committee. The JCP
isn't appropriate for language design.