[The Java Posse] java rebel and glassfish v3

[Bjorn Monnens]

Hey,

On one of the last episode the Javaposse mentioned that glassfish v3
supports save and refresh (like you have in php and other
dynamic,scripting languages). Is this already available and did
anybody test it out yet? I played around with grails and that seemed
to work fine up to a certain point where I did have to do a stop
start.

regards

Bjorn

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: #215 Traits

[hlovatt]

I agree with Jess, non-public methods and static methods (with
implementations) would be handy. Also the Scala technique of allowing
fields that are replaced by methods, hence properties, would be great,
e.g.:

interface X { // Assuming keyword interface now meant trait!
  int x = 1; // Field
}

was a shorthand for:

interface X { // Field replaced by methods
  int getX();
  int setX( int x );
  int initX() { return 1; } // Note method body
}

which in turn was a shorthand for:

interface X { // Current Java
  int getX();
  int setX( int x );
  int initX();
  class Trait { // Method bodies from trait
static int initX( X self ) { return 1; }
  }
  class Default implements X { // Default X class for when no further
inheritance needed
public int x = initX();
public int getX() { return x; }
public int setX( int x ) {
  this.x = x;
  return x;
}
public int initX() { X.Trait.initX( this ); }
  }
}


and the compiler translated:

X x = new X();
x.x = 2;

into:

X x = new X.Default();
x.setX( 2 );


On Nov 5, 3:42 pm, Jess Holle <[EMAIL PROTECTED]> wrote:
> I concur.  Traits would be a hugely useful addition.
>
> To make them really sing, however, one needs non-public interface
> methods.  For instance:
>
>     public interface Foo
>     {
>       public void doIt()
>       {
>         // default implementation logic implemented in terms of
>     getXInternal() and/or setXInternal()
>       }
>
>       protected X  getXInternal();
>       protected void  setXInternal(X x);
>     }
>
> Either that or one needs to allow interfaces to have fields, which is
> much uglier.  Having non-public accessors allows one to have virtual
> fields used in the default logic which can then be mapped as appropriate
> as part of implementing the trait interface.
>
> --
> Jess Holle
>
> Mark Derricutt wrote:
> > Please please please bring on traits!  I'm somewhat on the fence of
> > rather seeing traits than closures in java sooner than the other.
>
> > I'm finding LOTS of places in my code where traits would just make
> > things cleaner.
>
> > More and more I think I just want scala :)
>
> > On Wed, Nov 5, 2008 at 12:15 PM, hlovatt <[EMAIL PROTECTED]
> > > wrote:
>
> >     I thinks that Traits are a great idea for Java and judging by #215 the
> >     posse, particularly Dick, like them. I wrote about them for Java 7 in:
>
> >    http://www.artima.com/weblogs/viewpost.jsp?thread=220916
>
> >     What do you think?
>
> > --
> > "It is easier to optimize correct code than to correct optimized
> > code." -- Bill Harlan
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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 technologiesconsequently, C# is the
preferred way forward.

On Nov 2, 9:56 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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 MyEvent;
>
>     // Or you can control access tot he event via add, and remove
> notation as is for
>     // Properties
>     private event EventHandler myEvent;
>     public event EventHandler 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(DoMyEventFired);
>     // Unsubscribing is the same, just with -=
>     MyEvent -= new EventHandler(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>();
>
>     // thus we can use this as:
>     foreach (var val in myComplex.entrySet()) {
>         // val is inferred to be of type `List', 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 actu

[The Java Posse] Re: #215 Traits

[Jess Holle]

I concur.  Traits would be a hugely useful addition.

To make them really sing, however, one needs non-public interface 
methods.  For instance:

public interface Foo
{
  public void doIt()
  {
// default implementation logic implemented in terms of
getXInternal() and/or setXInternal()
  }

  protected X  getXInternal();
  protected void  setXInternal(X x);
}

Either that or one needs to allow interfaces to have fields, which is 
much uglier.  Having non-public accessors allows one to have virtual 
fields used in the default logic which can then be mapped as appropriate 
as part of implementing the trait interface.

--
Jess Holle

Mark Derricutt wrote:
> Please please please bring on traits!  I'm somewhat on the fence of 
> rather seeing traits than closures in java sooner than the other.
>
> I'm finding LOTS of places in my code where traits would just make 
> things cleaner.
>
> More and more I think I just want scala :)
>
> On Wed, Nov 5, 2008 at 12:15 PM, hlovatt <[EMAIL PROTECTED] 
> > wrote:
>
>
> I thinks that Traits are a great idea for Java and judging by #215 the
> posse, particularly Dick, like them. I wrote about them for Java 7 in:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=220916
>
> What do you think?
>
>
>
>
> -- 
> "It is easier to optimize correct code than to correct optimized 
> code." -- Bill Harlan
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: episode 215: reflection and generics

[Jess Holle]

For the most part, Java 5 class files contain metadata indicating much 
of what the source file indicated as far as generics are concerned.  
This is certainly the case for field/method/class declarations.  I'm not 
sure about local variable declarations, though.

That said, once one has something like:

void  sort( List list ) { ... }

one can only determine that 'list' is parameterized by 'T', any 
extends/super constraints, etc.  The body of sort() here has no other 
notions about T -- either in the class file or at runtime.  That is 
erasure.  List.class == List.class == List.class.  This is 
necessary to keep the existing contracts and is a key benefit to erasure 
-- both in lack of class bloat and in preservation of existing contracts 
and compatibility.  One could potentially have a special 
Class.getGenericTypeInfos(Object) utility that could seperately lookup 
this info, e.g. by having each object refer to both its class and its 
generic typing info -- rather than to just the class.  When called by 
old, non-generic-savvy code the generic typing info would be null, of 
course.  One could have the compiler do nifty bits with such a 
getGenericTypeInfos() utility so that one could do things like "new T[]" 
in sort -- throwing a runtime exception if the typing info is not 
present.  This would be undoing erasure without blowing new/old code 
interoperability except where actually necessary.

--
Jess Holle

Christian Catchpole wrote:
> Here is my analysis of the situation.  I could be wrong.  But here
> goes..
>
> When I got my copy of Java 5 my first question was, do generics really
> take the cast out of the equation?  I disassembled the code to find
> the cast still exists.  This implies that when you compile this..
>
> HashMap map = new HashMap()
> String string = map.get("");
>
> The generated code actually equates to this..
>
> HashMap map = new HashMap()
> String string = (String)map.get("");
>
> The class returned by map.getClass() does not know the map only
> contains Strings.  It's actually the reference to the map which
> marshals the types.
>
> I did a quick test...
>
> HashMap map1 = new HashMap();
> HashMap map2 = new HashMap();
>
> System.out.println(map1.getClass() == map2.getClass());
>
> true
>
> They use the same class and can't therefore hold the type information
> for both declarations.
>
> I can only assume this re-compiler the posse were talking about, scans
> the code for the actual cast / type check to determine the types.
>
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: #214 and Halloween

[Christian Catchpole]

My friends and I had a Halloween party.  But we just like dressing up
like freaks.  It's the perfect opportunity for the ladies to dress
inappropriately but with unquestionable justification. (I could have
phrased that differently, but chose to be tactful).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[RogerV]

On Nov 4, 6:10 am, "Brett Ryan" <[EMAIL PROTECTED]> 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.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: #215 Traits

[Mark Derricutt]

Please please please bring on traits!  I'm somewhat on the fence of rather
seeing traits than closures in java sooner than the other.

I'm finding LOTS of places in my code where traits would just make things
cleaner.

More and more I think I just want scala :)

On Wed, Nov 5, 2008 at 12:15 PM, hlovatt <[EMAIL PROTECTED]> wrote:

>
> I thinks that Traits are a great idea for Java and judging by #215 the
> posse, particularly Dick, like them. I wrote about them for Java 7 in:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=220916
>
> What do you think?
> >
>


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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Dragable applets...

[sherod]

I'm using a few widgets to track that little election thing thats
going on in the States and I would dearly love to have dragged some of
these election map widgets off my browser and onto my desktop.

Sadly they are in Flash and refuse the budge from my browser :).

Maybe that's the dragable applet killer app, live event tracking?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] #215 Traits

[hlovatt]

I thinks that Traits are a great idea for Java and judging by #215 the
posse, particularly Dick, like them. I wrote about them for Java 7 in:

http://www.artima.com/weblogs/viewpost.jsp?thread=220916

What do you think?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: episode 215: reflection and generics

[Christian Catchpole]

Here is my analysis of the situation.  I could be wrong.  But here
goes..

When I got my copy of Java 5 my first question was, do generics really
take the cast out of the equation?  I disassembled the code to find
the cast still exists.  This implies that when you compile this..

HashMap map = new HashMap()
String string = map.get("");

The generated code actually equates to this..

HashMap map = new HashMap()
String string = (String)map.get("");

The class returned by map.getClass() does not know the map only
contains Strings.  It's actually the reference to the map which
marshals the types.

I did a quick test...

HashMap map1 = new HashMap();
HashMap map2 = new HashMap();

System.out.println(map1.getClass() == map2.getClass());

true

They use the same class and can't therefore hold the type information
for both declarations.

I can only assume this re-compiler the posse were talking about, scans
the code for the actual cast / type check to determine the types.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Flash 64 bit after version 10

[manfred]

On Tue, 4 Nov 2008 02:13:29 -0800 (PST), Kim Saabye Pedersen
<[EMAIL PROTECTED]> wrote:
> 
> Occording to the adobe knowledge base, flash player is coming in a 64-
> bit edition in an upcoming release:
> 
> "Adobe is working on Flash Player support for 64-bit platforms as part
> of our ongoing commitment to the cross-platform compatibility of Flash
> Player. We expect to provide native support for 64-bit platforms in an
> upcoming release of Flash Player following Flash Player 10."
> 
> Updated on 10-14-2008.
> http://kb.adobe.com/selfservice/viewContent.do?externalId=6b3af6c9
> 
> Can we actually expect adobe to provide 64-bit support for flash or do
> you think the "upcoming" is a carte blanche to do nothing for a very
> long time?
> 
> Do you know whether adobe has made such promises before?

According to some quote from some adobe guy I heard in a redmonk related
podcast recently that adobe is actively working on it.

manfred


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Flash 64 bit after version 10

[Kim Saabye Pedersen]

Occording to the adobe knowledge base, flash player is coming in a 64-
bit edition in an upcoming release:

"Adobe is working on Flash Player support for 64-bit platforms as part
of our ongoing commitment to the cross-platform compatibility of Flash
Player. We expect to provide native support for 64-bit platforms in an
upcoming release of Flash Player following Flash Player 10."

Updated on 10-14-2008.
http://kb.adobe.com/selfservice/viewContent.do?externalId=6b3af6c9

Can we actually expect adobe to provide 64-bit support for flash or do
you think the "upcoming" is a carte blanche to do nothing for a very
long time?

Do you know whether adobe has made such promises before?

Regards
Kim



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] #214 and Halloween

[kibitzer]

You asked the (I suppose rhetorical) question, is Halloween celebrated
everywhere?

Well it is in Australia (grinds teeth). It is now, anyway. Never used
to be in the "olden days" (when I was growing up). However it's grown
in popularity in the last decade. It's certainly not as entrenched
here as it is in the States but it's getting that way. More
opportunities to sell crap I suppose.

I always go out on October 31 now. I'm thinking of making a sign for
the door: "NO HALLOWEEN HERE."

Also, get off my lawn.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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?

-- 
Weiqi Gao
[EMAIL PROTECTED]
http://www.weiqigao.com/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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?


On Wed, Nov 5, 2008 at 4:57 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> 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 wrote:
>
> 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
>
> On Wed, Nov 5, 2008 at 4:44 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>
>
> 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
>
> On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>
>
> 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
> [EMAIL PROTECTED]
> http://www.weiqigao.com/blog/
>
>
>
>
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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 wrote:
> 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
>
> On Wed, Nov 5, 2008 at 4:44 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>   
>> 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
>>
>> On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>>
>>
>> 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
>> [EMAIL PROTECTED]
>> http://www.weiqigao.com/blog/
>>
>>
>>
>>
>>
>> 
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

Brett Ryan wrote:
> 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.
>
> On Wed, Nov 5, 2008 at 4:36 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>   
>> 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.
>>
>>
>> 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.
>>
>>
>> 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
>>
>>
>> 
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

On Wed, Nov 5, 2008 at 4:44 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> 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
>
> On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>
>
> 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
> [EMAIL PROTECTED]
> http://www.weiqigao.com/blog/
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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.

On Wed, Nov 5, 2008 at 4:36 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> 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.
>
>
> 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.
>
>
> 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
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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
> On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>   
>> 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
>> [EMAIL PROTECTED]
>> http://www.weiqigao.com/blog/
>>
>> 
>
> >
>
>   


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

On Wed, Nov 5, 2008 at 4:26 AM, Weiqi Gao <[EMAIL PROTECTED]> wrote:
>
> 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
> [EMAIL PROTECTED]
> http://www.weiqigao.com/blog/
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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.
>> 
>
> 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.
>   
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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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
[EMAIL PROTECTED]
http://www.weiqigao.com/blog/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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.
>
>
> 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.

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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[Brett Ryan]

>> 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  :-)

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.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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 ;-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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 
and a Collection.  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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: episode 215: reflection and generics

[[EMAIL PROTECTED]]

At runtime you can take class Foo and determine that it requires
generic type parameters, but you can take an instance of Foo and
find out what generic type parameter T is. For a decompiler (while I'm
just speculating) it shouldn't need to know what type an instance of
Foo is as it's just trying to determine if Foo requires a type
parameter.

thus, you can't do something like

if (String.class == foo.getClass().getGenericArguments().get(0)) {
  //
}

or...

class Foo {
void bar() {
if (T.class == String.class) {
//
}
}
}

In contrast, with C# you can do the former as

if (myList.GetType().GetGenericArguments()[0] == typeof(String)) {
//
}

and the latter as

class Foo {
public void Bar() {
if (typeof(T) == typeof(String)) {
//
}
}
}

-Brett


On Nov 4, 11:16 pm, "Frederic Simon" <[EMAIL PROTECTED]> wrote:
> What's funny, is that Joe was saying: If it's in the class file it should be
> in the reflection API as an extension... Well that's exactly how it goes.
> All the "erased by erasure" information is in the class file. So, you can
> query generics and annotations on a class file.
> The problem if you get a List object as a parameter here you lost the
> generics information (even if the class sending it to you knows). So, for
> framework that want to use generics information, you need the class object
> that contain the generic member, and of course to identify the member
> (Annotation or Ugly strings).
> That's where erasure hits and gets painful for framework.
>
> Keep up with good suppositions :)
>
>
>
> On Mon, Nov 3, 2008 at 4:45 PM, Alexey Zinger <[EMAIL PROTECTED]> wrote:
>
> > In the discussion of the new Java decompiler that recognizes generics, the
> > guys seemed to be surprised that class files can retain that information and
> > were wondering why it's not in the reflection API.  Without running a real
> > test to see what's actually available, the API are most certainly there:
>
> >http://java.sun.com/javase/6/docs/api/java/lang/reflect/GenericDeclar...
>
> > Alexey
> > 2001 Honda CBR600F4i (CCS)
> > 1992 Kawasaki EX500
> >http://azinger.blogspot.com
> >http://bsheet.sourceforge.net
> >http://wcollage.sourceforge.net
>
> --http://www.jfrog.org/http://freddy33.blogspot.com/http://nothingisinfinite.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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

On Wed, Nov 5, 2008 at 12:10 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> 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
>
>
> >
>

--~--~-~-

[The Java Posse] Re: Influential Java programmers should learn C#

[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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: episode 215: reflection and generics

[Frederic Simon]

What's funny, is that Joe was saying: If it's in the class file it should be
in the reflection API as an extension... Well that's exactly how it goes.
All the "erased by erasure" information is in the class file. So, you can
query generics and annotations on a class file.
The problem if you get a List object as a parameter here you lost the
generics information (even if the class sending it to you knows). So, for
framework that want to use generics information, you need the class object
that contain the generic member, and of course to identify the member
(Annotation or Ugly strings).
That's where erasure hits and gets painful for framework.

Keep up with good suppositions :)

On Mon, Nov 3, 2008 at 4:45 PM, Alexey Zinger <[EMAIL PROTECTED]> wrote:

>
> In the discussion of the new Java decompiler that recognizes generics, the
> guys seemed to be surprised that class files can retain that information and
> were wondering why it's not in the reflection API.  Without running a real
> test to see what's actually available, the API are most certainly there:
>
> http://java.sun.com/javase/6/docs/api/java/lang/reflect/GenericDeclaration.html
>
> Alexey
> 2001 Honda CBR600F4i (CCS)
> 1992 Kawasaki EX500
> http://azinger.blogspot.com
> http://bsheet.sourceforge.net
> http://wcollage.sourceforge.net
>
>
>
>
>
> >
>


-- 
http://www.jfrog.org/
http://freddy33.blogspot.com/
http://nothingisinfinite.blogspot.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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 myList = new List() {
"One", "Two", "Three", "Four"
);
List 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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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


On Tue, Nov 4, 2008 at 8:08 PM, RogerV <[EMAIL PROTECTED]> wrote:
>
> 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.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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)










--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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



Casper Bang wrote:
> 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
> 
> 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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
<[EMAIL PROTECTED]>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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Influential Java programmers should learn C#

[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.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---

[The Java Posse] Re: Any real Scala products and NetBeans 6.5 RC2 and Scala Support

[Viktor Klang]

Greetings Adam,

as mentioned before by Mike, Lift is a Scala product.
Also, I happen to know that there are a few companies out there who have
adopted Scala:
i.e. Sygneca in the UK, a company called Triental in Sweden (Jonas Bonér
(creator of AspektWerkz, Terracottatech guy)), there's a company in France
who are making computer games in Scala + lots of companies that haven't gone
out with their Scala use to the public and then we have all the enthusiasts
with their projects.

Cheers,
Viktor Klang
Lift committer

On Tue, Nov 4, 2008 at 5:43 AM, mikeb01 <[EMAIL PROTECTED]> wrote:

>
> Like every language today you have to have a web framework:
>
> http://liftweb.net/index.php/Main_Page
>
> On Nov 3, 10:47 pm, "Adam G." <[EMAIL PROTECTED]> wrote:
> > Hey all,
> >
> > after the Halloween podcast I downloaded the latest RC2 to try it out
> > with Scala. Unfortunately it was not working out of the box. Also
> > installing the plugin from the netbeans plugin page was not possible,
> > because the version there is not compatible with the latest 6.5 RC2
> > release. After some googleing I found a howto by the author of the
> > Scala plugin:
> >
> > http://blogtrader.org/page/dcaoyuan/entry/install_scala_plugin_for_ne...
> >
> > So all you need to do is to add "Last Development Builds" to the
> > plugins and then you can install Scala into NetBeans.
> >
> > After playing around a little bit with Scala I just wonder if there
> > are "real products" programmed in Scala of if it's still only some
> > academic stuff? Any examples?
> >
> > Cheers,
> >  Adam Giemza
> >
>


-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---