• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

JavaBeans Naming Rules

 
Ranch Hand
Posts: 50
Eclipse IDE PHP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everybody,
I have a question about the JavaBeans Property Naming Rules used in B&K book.

This rule explain that: (pag 9)
"Getter method signatures must be marked public, take no arguments, and have a return type that matches the argument type of the setter method for that property."

But in the Java APIs, this JavaBeans property is not observed.
For example:
1)In the Java URL class (java.net package) a getter has this signature:
public final Object getContent(Class[] classes) //it takes an array argument

2)In the Integer class (java.lang package) three getters don't have standard signatures:
public static Integer getInteger(String nm)
public static Integer getInteger(String nm, int val)
public static Integer getInteger(String nm, Integer val)

and in other classes of other packages have this not standard JavaBeans behavior.

I will use this rule, but why in the Java API is not all the time respected?
Is it a issue/compatibility with the past?

Thanks, and sorry for my english
KK
 
Sheriff
Posts: 67750
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not every Java class is a bean.
 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
URL and Integer are not JavaBean components - they are not conforming JavaBean rules.

JavaBean components are objects that can be visually manipulated in the IDE,
for example in a Swing form buillder in NetBeans you can drag and drop JavaBean components from a palette
and place them on a form (button, editbox, menu etc.), launch a property editor on placed component,
set some components' properties using the property editor etc. - without writing any line of code.
You can create your own JavaBean components and add them to the palette.
To create such component, you must create a java class that MUST conform JavaBean specification.
If it doesn't conform JavaBean rules - it is not JavaBean and it can't be used in this way.
Here you can find more information about JavaBeans:
http://en.wikipedia.org/wiki/JavaBean
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138795.html
http://wiki.netbeans.org/NetBeansJavaBeansTutorial
 
Bear Bibeault
Sheriff
Posts: 67750
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ireneusz Kordal wrote:JavaBean components are objects that can be visually manipulated in the IDE


That is but one -- and fairly niche -- use of JavaBeans.

They are also used extensively in web applications and by frameworks such as Spring and Hibernate.
 
Paper jam tastes about as you would expect. Try some on this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic