Showing messages 1 through 47 of 47.

• I think that the property problem is a more generic problem
  2007-03-18 07:56:55 nicarran [Reply | View]
  
  And why not a macro preprocessor instead of adding new core keywords (like "property") every time we "all" need to generate repetitive code?

• I think that the property problem is a more generic problem
  2007-03-18 07:54:38 nicarran [Reply | View]
  
  And why not a macro preprocessor instead of adding new core keywords (like "property") every time we "all" need to generate repetitive code?

• Wrong Direction
  2007-02-06 14:25:53 zero [Reply | View]
  
  why the hell does everybody want to ease the defintion of a property (get/set methods)? This is a one time effort and can be auto-genrated by the IDE.
  
  Far more useful would be to improve using them. I'm more annoyed about:
  
  <br/><br/>
  

  vec.setX(++vec.getX());

  <br/>
  instead of simply doing: <br/>
  

  ++vec.x;

  <br/>
  <br/><br/>
  
  I mean using JavaScript via the JavaScriptingFramework does a great job by allowing to access property as if they were fields.
  
  Of course, if there is a field with the same name, it would have higher precedency:<br/><br/>
  
  
  E.g.

  vec.x

  always references the field in following case, not the property:
  <br/><br/>
  

  
  
  class Vec {
  
    public float x;
  
  
  
    public float getX() { .. }
  
    pulic void setX(float x) { .. }
  
  }
  
  

  <br/>

• Against all change?
  2007-01-18 06:04:42 scolebourne [Reply | View]
  
  I blogged a reply to those of you who seem to be against all Java language change.

• Why new syntax? We have (almost) all we want already!
  2007-01-17 14:39:59 jezuch [Reply | View]
  
  public final Property<String> someProperty=...;
  
  ...
  
  String value=someObject.someProperty.get();
  someObject.someProperty.set("is it that difficult?");

• only changes that add value
  2007-01-17 13:44:38 ramsinb [Reply | View]
  
  Why can't there be more thought placed in features that add value or add to the langauge as opposed to features that might make things VERY slightly convienent.
  
  My IDE can generate getters/setters, it can also refactor getters/setters, it handles auto completion of getters/setters and finds where in code the getter/setter is used. When i implement a property all i have to do is type: private String name; and then generate the getters/setters. How much development time is property support going to save me? Note much, hence my vote for not important!
  
  6 ways to do the same thing will only confuse new developers why would I possibly want that?

• only changes that add value
  2007-01-17 13:44:05 ramsinb [Reply | View]
  
  Why can't there be more thought placed in features that add value or add to the langauge as opposed to features that might make things VERY slightly convienent.
  
  My IDE can generate getters/setters, it can also refactor getters/setters, it handles auto completion of getters/setters and finds where in code the getter/setter is used. When i implement a property all i have to do is type: private String name; and then generate the getters/setters. How much development time is property support going to save me? Note much, hence my vote for not important!
  
  6 ways to do the same thing will only confuse new developers why would I possibly want that?

• Explicit Safety
  2007-01-17 00:11:02 evanx [Reply | View]
  
  I would like to see a poll that is more specific, eg. do developers want "property literals."

  Because that's what i want, eg. so i can bind components to properties eg. in a Presentation Model, in a safe IDE-assisted way, eg. enjoying autocompletion, verification and refactorability.

  Using strings to refer to properties (by their property name) is clearly fragile eg. to renaming properties, and the IDE can't assist because it's just a string.

• No more big additions
  2007-01-16 00:10:13 bkondepudi [Reply | View]
  
  Java 5 has added huge list of very useful features. And they are very much necessary for next generation computing using annotations, aspect-based etc.
  
  But by looking at the rt.jar and the whole language libraraies they are growing huge day-in day-out and having significant impact on the performance.
  
  Also the language has far reach for the new programmers who cannot understand annotation and generic notation on fly.
  Recently I had a conversation with few of college grads and they no more interested in java and the answer that I got from them is "Neither community nor sun nor anybody doesnt know where Java will be in next 3-5 years by looking at each of the Java realeases". So there is lot of confusion.
  
  A programming language shd help in concenptualize a business logic and not be a one stop facilitator. As it will kill the innovative thinking of implementation.
• No more big additions
  2007-01-16 13:34:46 tompalmer [Reply | View]
  
  I haven't reviewed the details, but I hear that the JRE for Java 6 is smaller than for Java 5. Also, due to added features, startup time is much faster. Still, you have some interesting thoughts to consider.

• A new language please
  2007-01-15 12:10:42 thiagosc [Reply | View]
  
  They should really consider creating a new language from scratch for running on the JVM. This way they could improve upon Java without messing with it.

• Fear of churn
  2007-01-15 10:52:54 tompalmer [Reply | View]
  
  I appreciate fear of churn, but Java as it stands today isn't vaguely as good for writing reliable code as it could be. Maybe it is time for another language, but I don't like any of the current JVM languages enough yet. And tooling support is still best for Java. That's the predicament that I think a lot of us face. If tools only exist (in good enough form) for Java, but Java otherwise has lots of warts and trouble, what to do? But churn in the language also stirs things up.
• Fear of churn
  2007-01-15 23:01:05 jwenting [Reply | View]
  
  If you can't write reliable code in Java that's a problem at your end, not Java's.

  In other words, your skills are deficient, not the language.

  And most of the proposed "features" will only make it harder to use, harder especially to write predictable code. Function pointers (renamed "closures" to make them sound less dangerous and more OO) are notoriously easy to abuse and hard to predict and debug, properties (certainly as proposed) muddy the line between data members and methods, making it very easy to provide what is essentially naked access to application state.

  It's possible to write crappy code in any language, but harder (by design) in Java than many others. Yet in the rush to include features just "because .NET/Ruby/C++ has them" the language is being made harder to use, more easy to write bad code in.

• Fear of churn
  2007-01-16 08:37:24 tompalmer [Reply | View]
  
  Oh, and function pointers (a la C) and closures are pretty different beasts. For instance, Java already has better closure support than C (given final vars). Interfaces are function pointers, too, at that vague of a definition. (And I don't care about OO or not. Many people who say "OO" don't know what it means, anyway.)
• Fear of churn
  2007-01-16 23:39:10 jwenting [Reply | View]
  
  They are effectively function pointers.
  You're supplying a pointer/reference to a method as an argument to a method, which is what a function pointer is.
  Interfaces aren't that, they're no more than a design contract.
• Fear of churn
  2007-01-16 08:34:24 tompalmer [Reply | View]
  
  My code is usually pretty reliable, but it takes a lot of effort. And I see a lot of code from others that isn't so reliable. Because it's hard to do. Closures, by the way, make writing reliable code easier in my experience. No more "whoops, I forgot to close the connection". And many other varieties of handy, easy-to-get-it-right-ness.
• Fear of churn
  2007-01-16 23:38:00 jwenting [Reply | View]
  
  if you forget to close a connection in an inner class with a single method, what makes you think you won't forget it when you replace that inner class with a function pointer to a method in your class?

• enough is enough
  2007-01-15 02:41:18 lorenzhawkes [Reply | View]
  
  I work for a bank where 'high availability and high throughput' is the name of the game. I find that using just the feature in java 1.4 is enough. Generics is a maybe nice feature for us, but will we need closures or properties? I don't think so. I agree with the majority on this one, people need to take a step back, take a deep breath and ask if they really really *need* not want this.

• Enough is enough!
  2007-01-14 10:21:14 ewin [Reply | View]
  
  

  How many more junk does Sun plan to add to the language, and when will they stop?

  Would someone please replace the script-kiddies currently posing as Sun Java Language designers with some real professionals, please? They have already done enough damage to the language by adding one gimmick after the other, just because some other language has it, too.

  Some programmers apparently have the wrong job and believe that all it takes are more and more features so they can finally stop writing any line of code at all. I'll tell you what. It will not happen. If you don't like writing code, get another job, study some liberal arts, become a sales weasel, but stop insisting on getting the language fscked up.

• Enough is enough!
  2007-01-18 04:56:48 dancres [Reply | View]
  
  +1
  
  It seems Sun have forgotten the original reasons for Java such as simplicity and readable code. Now we're focused on having the biggest number of developers using the language leading to the absurd feature creep we now have.
  
  Rather than working on new language features, how about Sun get around to actually fixing the classloader model and enabling the use of dynamically downloaded code which is where Java started from? This is the kind of innovation that attracts decent developers as opposed to the language magpies who one week use c#, the next Java and the week after Ruby.
  
  
  
  
  
  
  
  
• Enough is enough!
  2007-01-15 02:31:00 jwenting [Reply | View]
  
  well said. It seems that the criteria for adding stuff to the language have been changed from "does it make sense, would it be useful for people" to "does it exist in .NET, Python, Ruby, or C++".

• How about using New as the constructor
  2007-01-14 04:59:18 datle [Reply | View]
  
  how about having the keyword New as the class constructor instead of the class now. So if you look at someone else source and see the word New() you immediately know its the constructor regardless of class name. Please don't say this should be a task for the IDE to highlight the constructor; java, unlike .net doesn't have a default IDE (VS) so the convention can vary from vendor to vendor.
• How about using New as the constructor
  2007-01-15 09:24:46 alski [Reply | View]
  
  Are you serious? You mean you can't identify constructors by the fact that 1) they have the class name and 2) they have no return type? Maybe you should stick with your VB#/C#...

• Properties would be OK, but ...
  2007-01-13 15:18:45 fredswartz [Reply | View]
  
  There are a lot of things that should be done before properties to make a programmer's life easier: eg, a usable replacement for GridBugLayout, fixing the switch statement (strings, ranges, .equals, continue, ...), operator overloading (less than, etc for strings and other Comparables), ....

• @Property(bound=true, vetoable=false)
  2007-01-13 12:33:03 eirikma [Reply | View]
  
  ...would do it if someone bothers to implement it.

• No more extensions to the core language
  2007-01-13 03:57:20 aehrenr [Reply | View]
  
  The power of java is its KISS design. Java source is very self documenting even when some other person has written it and good comments are rare. And that is very important in practice. Don't clutter it with goofy extensions just to emulate some scripting languages, like closures (there are already anonymous classes), properties (a task of the editor!) or the worst of the suggestions the XML build in the language (this is a task of a smart library). It is a common mistake in computer science that features are added to a language or a program to please a few freaks until it gets unusable for the majority ! There is no need to clutter as many features as possible in a single language. This is more the mentality of a little child: This language is better because it has delegates, properties and so on. If some language freaks really miss features it would be much more clean to start out a new language running on the java platform and include their ideas. If it is really a good design it will get adopted widely. Just like for example AspectJ.
  You should also keep in mind that there are many, many developers that have no interest in additional language features, for example because they use a computer-language just as a tool to realize a very smart business logic or solve a mathematical or scientific problem. I mean those people that some bigheaded people at Javalobby and elsewhere call "Joe developer". Those "Joes" concentrate on smart ideas what to realize with a computer and have their interest focussed on an algorithm to solve a problem (and know for example much about science than about computer languages). They have no interest in a programming language that can express as much as possible in a single line, but they prefer a language that you can easily read and understand even when you get source from other people or program only from time to time.
  The language freaks tend to add features until something like Perl or C++ comes out. Thats OK with me, use those languages and laugh at the "Joes" that do not remember all features of C++, but please don't deform Java. The language is a great tool as it is ! Go on with improving the libraries, the integration in operating systems, web-start and so on.

• Shouldn't this all be about what developers want?
  2007-01-13 02:22:53 calum [Reply | View]
  
  It's interesting that JDK7 and to a lesser extent JdK6 was all about what Sun thinks developers want.
  
  Properties...don't know if it's really been thought through - yes gettters and setters are a real PITA but all that properties will give us is new way of writing them with no real other benefits.
  
  Closures - I can see a need for them as a way to replace anonymous clases....but who decided out of all the ways to replace anonymous classes (closure, delegates, auto-wiring) that closures was the best of them?
  
  XML built into the source.....not a chance, it's a disaster waiting to happen.
  
  Web Service in JDK6 - why??? If Sun wanted to put in a good distributed SOA system, why didn't they put Jini in there, or at least enhance RMI.

• Shouldn't this all be about what developers want?
  2007-01-13 02:22:21 calum [Reply | View]
  
  It's interesting that JDK7 and to a lesser extent JdK6 was all about what Sun thinks developers want.
  
  Properties...don't know if it's really been thought through - yes gettters and setters are a real PITA but all that properties will give us is new way of writing them with no real other benefits.
  
  Closures - I can see a need for them as a way to replace anonymous clases....but who decided out of all the ways to replace anonymous classes (closure, delegates, auto-wiring) that closures was the best of them?
  
  XML built into the source.....not a chance, it's a disaster waiting to happen.
  
  Web Service in JDK6 - why??? If Sun wanted to put in a good distributed SOA system, why didn't they put Jini in there, or at least enhance RMI.

• Load system properties from file upon startup
  2007-01-13 00:39:53 ujay68 [Reply | View]
  
  No need for an entirely new syntax. But I would appreciate a standard jvm command-line option to pass a property file and have the jvm load that property file upon startup to initialize system properties:
  
  java -Pmysettings.properties ...
  
  That would simplify all those Tomcat-like startup shell scripts with endless JAVA_OPTS="$JAVA_OPTS -Dfoo=bar" ...
  
  Jay

• Keep the language simple
  2007-01-12 21:04:01 bharathch [Reply | View]
  
  Repeat after me - s-i-m-p-l-i-c-i-t-y. That's the power of Java. Let an IDE do things for you. Don't try to make the lang super smart. Please. The same holds for closures. The world can do without the BGGA proposal. What we need is CICE.
• Keep the language simple
  2007-01-15 02:08:20 xodox [Reply | View]
  
  Yes.. Simplicity.
  
  And properties WILL make it even more simple for developers to develop in Java.
  
  If implemented as in C#:
  public String Title{ get{ return title; } set{ title=value; } }
  
  ...getters and setters will be forced to be in the same block of code, instead some times randomly placed around a 2500 lines pile of code. Furthermore, how many times havent you gotten sick and tired of large classes having not only 50 getters, but also 50 setters. The lists generated for these classes for "intellisense" use are loooong.
  
  Using properties the bean-patterns could be a lot easier to use for a developer using the bean.
  
  
  
  
  
  
  
  
  
• Keep the language simple
  2007-01-17 14:29:43 hontvari [Reply | View]
  
  yes, it makes more readable the bean-pattern, and that is important because the bean-pattern is abused in so much code. The property syntax will make bean-like objects looking like real POJOs. But I think what is really needed is another feature: we should be able to write real POJOs and frameworks should be able to manage them similarly to javabeans. I.e. something which can intercept the reading and writing of attributes.
• Keep the language simple
  2007-01-17 14:25:05 hontvari [Reply | View]
  
  yes, it makes more readable the bean-pattern, and that is important because the bean-pattern is abused in so much code. The property syntax will make bean-like objects looking like real POJOs. But I think what is really needed is another feature: we should be able to write real POJOs and frameworks should be able to manage them similarly to javabeans. I.e. something which can intercept the reading and writing of attributes.
• superfluous getters and setters
  2007-01-16 09:45:51 weberjn [Reply | View]
  
  getters and setters are kind of holy cow. But if almost all do nothing but set or get a value, why not directly access the attribute?
  Yes, I know the all-customers-directly-taking-money-from-the-bank-safe argument, but if the bank clerk blindly does what the customers want, she's superfluous and the customer might as well take money from the safe himself. Same goes for setters like
  
  public void setXX(XX xx)
  {
  this.xx = xx;
  }
  
  But if a setter really does something useful, it indeed should be a distinct method and not a C# like setter.
• superfluous getters and setters
  2007-01-16 12:13:20 xodox [Reply | View]
  
  if the bank clerk blindly does what the customers want, she's superfluous and the customer might as well take money from the safe himself.
  
  Say that some time in the future all transaction to/from the safe had to be reported. Then the clerk had to tell all customers how to report and maybe even check that they did. Of course, if he always had bben the one to take the money from the safe, only the clerk would need to know how to report. In general, I think direct access to an attribute is bad design. You never know if some demand in the future needs something done when an attribute is changed og retrieved.
  
  
• superfluous getters and setters
  2007-01-17 15:38:49 hontvari [Reply | View]
  
  it will take about 3 clicks in a modern IDE to replace direct access to an attribute with a getter method IF that is needed sometime in the future. You are right though in case of libraries. But bank, clerk etc. seems to be business logic of an application and not a library.
• Keep the language simple
  2007-01-16 05:48:09 alexter [Reply | View]
  
  Simplicity is not about typing less, it's all about code being easier to understand. The more special cases a language syntax provides the harder it is to understand. Java was once perfect in this regard. Generics and autoboxing spoiled the simplicity; properties will make things even worse.
  
  All this features are useful (though properties is least useful of them), but usefulness is not the only or even the main point. Maintainability is the king of the game. Some people seem to see Java as a language for writing cool apps in three hours, but it’s not. When you develop software to be maintained by many people over many years language verbosity becomes a feature rather than a problem.
  
  P.S. A class of 2500 lines with 50 getters and 50 setters is usually a result of bad design, which has nothing to do with the language.
• Keep the language simple
  2007-01-16 12:34:34 xodox [Reply | View]
  
  Generics and autoboxing spoiled the simplicity; properties will make things even worse.
  
  Thats the strange part abouts this prototype thing. I feel the exact opposite.
  When I think of simplicitity, I mostly think of easy-to-use API's. Consider Java's date/calendar API and .NET's DateTime/Calendar API.
  
  I really can't stress this enough: I hate Java's date/calendar API - I love .NET DateTime/Calendar API.
  Reason? .NET's API is so easy to use - Java's is not.
  
  I believe that prototypes can help us make more easy-to-use API's, which Java really need. It will often decrease the number of getters and setters by half and IDE's will most likely begin to visualize prototypes in "intellisense"-lists using other icons, making it even more simple to get a quick overview of what a developer can change on an object.
  
  
  
  
  
  
  
  
• Keep the language simple
  2007-01-17 01:30:48 xodox [Reply | View]
  
  visualize prototypes
  
  I meant "visualize properties" of course.
  
  
• Keep the language simple
  2007-01-15 09:35:20 cayhorstmann [Reply | View]
  
  

  Your point is very well taken. The goal is simplicity. The hope is to improve upon C# and make it even simpler. By default, there would be no need to specify getter/setter code.

  public property String title;.

  However, if a property requires non-trivial getters/setters, you'd specify them, like in C#.

• Keep the language simple
  2007-01-16 12:41:36 xodox [Reply | View]
  
  By default, there would be no need to specify getter/setter code.
  public property String title;.
  
  Hmm. Not a bad idea. This way an author of MyClass could later on change his property from:
  public property String title;
  
  to:
  public property String title{
get{
return this.inner_title;
}
set{
this.inner_title=value;
this.doTheHulaHoop();
}
}

  
  ....without breaking any API's? Nice!
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

• Not another language change
  2007-01-12 14:04:39 jseltzer [Reply | View]
  
  Please stop with the language changes in an effort to make things easier to do. This is the job of the ide not the language. Can you say generics?

• vs. Closures survey
  2007-01-12 11:50:39 tompalmer [Reply | View]
  
  I don't know if it would turn out the same again, but this definitely looks different than the results of the closures survey.

• Lets focus on User features
  2007-01-12 11:46:49 jackdog [Reply | View]
  
  Some suggestions...
  
  -> Non-Opaque root windows. This would be huge.
  -> Revamp webstart - make it easier to use, more stable and less rigid. No CA certs!
  -> Start integrating more advanced UI abilities to rich clients. swingx, painters, LnF.
  -> Better OpenGL support for Java2D
  -> New Swing Components

• It ranks right up there with...
  2007-01-12 10:51:12 alski [Reply | View]
  
  ...needing a feature to automatically crash the VM. I think someone ought to get right on it!
• Keep the language simple
  2007-09-19 09:43:09 pirates_of_java [Reply | View]
  
  Features introduced in java 5 make the language sufficiently mature..adding property feature to the class is not gonna make the laguage buggy..but FANCY things like function pointers or the very concept will tend to make the language complex...a very simple language with a powerful set of libraries is the best option...its only two numbers 1 and 0 with which we have created the world of computers..how about introducing one more digit say x ..and then INVENTING NEW COMPUTERS with digital logic circuits having 3 states ,does anyone ready to work on this FANCY IDEA...?
• Keep the language simple
  2007-09-19 09:42:38 pirates_of_java [Reply | View]
  
  Features introduced in java 5 make the language sufficiently mature..adding property feature to the class is not gonna make the laguage buggy..but FANCY things like function pointers or the very concept will tend to make the language complex...a very simple language with a powerful set of libraries is the best option...its only two numbers 1 and 0 with which we have created the world of computers..how about introducing one more digit say x ..and then INVENTING NEW COMPUTERS with digital logic circuits having 3 states ,does anyone ready to work on this FANCY IDEA...?