My 2 cents: Although static methods are valid code applied to instances of the class; this is a matter of parsing and code generation. Static methods are logically methods of that instance's class object.
In either case Java's reflecton mechanism doesn't seem to provide API access to invoking a static method. Though I don't recall having tried such... Roy On Tue, 2004-04-06 at 17:06, Andrew Stevens wrote: > Hi Bill, > > Thanks again for your reply. This JavaBeans component model specification > seems quite hard to locate. > I did find a PDF from 1997 on the Sun site (ver 1.01). Is this the only > point of reference? Can you provide me with any recent JavaBeans Spec > documentation? > > I suppose I am struggling to find the meaning/advantages of excluding access > to static methods (accessed in a non static way). > My knowledge is limited with AWT, reflection, intraspection etc, but I'm > guessing that using these while doing GUI development (other than web) would > allow/enable access to these types of methods. > > Cheers, > AS > > -----Original Message----- > From: Bill Siggelkow [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, 6 April 2004 12:50 > To: 'Tag Libraries Users List' > Subject: RE: Beans static method in non static way > > Thanks for the clarification, Andrew. JSTL is predicated on the > JavaBeans > component model and is such getter methods are expected to be > instance > variables. And I certainly understand your limitations as far as > the code. > I think in a lot of cases, a getMaxLength() method would be an > instance > method that uses a static field. > > However, since you indicated that you cannot change these things -- > if you > are using a JSP 2.0 container like Tomcat 5 than you could use JSPs > support > for static methods described here: > > http://www.javaworld.com/javaworld/jw-05-2003/jw-0523-calltag-p2.html > > If you do not or cannot do this then another option is to load your > static > data into the servlet context using a servlet. > > > Bill Siggelkow > [EMAIL PROTECTED] > > > -----Original Message----- > From: Andrew Stevens [mailto:[EMAIL PROTECTED] > Sent: Monday, April 05, 2004 10:30 PM > To: 'Tag Libraries Users List' > Subject: RE: Beans static method in non static way > > > Thanks v.much for your reply. To the contrary, I don't have a lot of > static > methods, but many objects each with one or two static methods. > > For example: we have a class called 'Subject' (yep nothing special - > building HTML forms here). Classes like Subject are provided to me > in a > package. > Subject has static getMaxLength(). If this was accessible in JSTL it > will > make my life as the web guy a lot simpler. > Instead I have to create a class like SubjectHolder which has a > Subject > property and a method which calls this.subject.getMaxLength(). > (This is starting to sound like Struts Form Beans etc... but I have > found > them limiting and for now choose to avoid them) Then JSTL also > starts to > look like ${thing.subjectHolder.subject.maxLength}. > > If Subject class has a max length, any instance also has a max > length. I > don't see how this suggests state? Can you elaborate? > I can't really dictate the way these classes are designed. Wrappers > it may > have to be (in the order of 10's to 100's!). > > Cheers, > AS > > -----Original Message----- > From: Bill Siggelkow [SMTP:[EMAIL PROTECTED] > Sent: Tuesday, 6 April 2004 11:31 > To: 'Tag Libraries Users List' > Subject: RE: Beans static method in non static way > > Well, I don't mean to sound like a OO-snob, but I have to > say that > if you > have a lot of static methods than it means that your code is > written > more > like a procedural language than an object-oriented one. > > That being said, if you have to de4al with thte static > methods than > the best > way I would think is to use the wrappers like you are doing. > I > mean, the > method you access with JSTL are object properties -- > properties mean > "state" > -- so, static methods mean "no state" -- since I think it is > completely > reasonable to not be able to access static methods -- aside > from the > technical/implementation reasons. > > Another approach is to turn your classes with the static > methods > into > singletons and change the static methods to instance methods > on the > singleton. > > That is all I can say for now as I need to get back to > watching my > the > Jackets! > > > Bill Siggelkow > [EMAIL PROTECTED] > > > -----Original Message----- > From: Andrew Stevens [mailto:[EMAIL PROTECTED] > Sent: Monday, April 05, 2004 9:08 PM > To: '[EMAIL PROTECTED]' > Subject: Beans static method in non static way > > > Hello, > > I have read most of the discussion on JSTL1.0/1.1. > Especially concerning static member/methods defining > functions and > all that > jazz. > > Here's my question. WHY if I create an instance of a bean > and put it > in a > scope (ie: request) can I not access static methods from the > instance? > I mainly use the JSTL core taglib. > > I can understand not being able to access a static method > from a > Class like: > SomeClass.getSomeStaticValue(). Because an instance is never > created. > But I don't see why there's a limitation that stops me from > accessing that > static method from an instance of the class (bean). > I think it's called accessing a static method in a non > static way > (?). > The really tedious part is I can create a bean which wraps > any > static > methods I need to access with non-static methods. Which > works fine. > But this introduces more code and less clarity/readability. > I might > argue > that defining functions in JSTL1.1 will be even more > overhead. > > Please share your thoughts. Can anyone provide an approach > to make > this > easily doable? Otherwise I have to convince some developers > to > re-code about > 200 classes to provide another method which is not static, > and just > returns > the results of the static equivalent. > > Thanks. > > > GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER > > Goldman Sachs JBWere Pty Ltd and its related entities > distributing > this > document and each of their respective directors, officers > and agents > ("the > Goldman Sachs JBWere Group") believe that the information > contained > in this > document is correct and that any estimates, opinions, > conclusions or > recommendations contained in this document are reasonably > held or > made as at > the time of compilation. However, no warranty is made as to > the > accuracy or > reliability of any estimates, opinions, conclusions, > recommendations > (which > may change without notice) or other information contained in > this > document > and, to the maximum extent permitted by law, the Goldman > Sachs > JBWere Group > disclaims all liability and responsibility for any direct or > indirect loss > or damage which may be suffered by any recipient through > relying on > anything > contained or omitted from this document. > > Goldman Sachs JBWere does not represent or warrant the > attached > files are > free from computer viruses or other defects. The attached > files are > provided, and may only be used, on the basis that the user > assumes > all > responsibility for any loss, damage or consequence resulting > directly or > indirectly from use. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > Goldman Sachs JBWere > Disclosure of Interest > ORG: Goldman Sachs JBWere and/or its affiliates expect to receive > or intend > to seek compensation for financial and advisory services in the next > 3 > months from the company, its parent, or its wholly owned or majority > owned > subsidiary. > > > > GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER > > Goldman Sachs JBWere Pty Ltd and its related entities distributing > this > document and each of their respective directors, officers and agents > ("the > Goldman Sachs JBWere Group") believe that the information contained > in this > document is correct and that any estimates, opinions, conclusions or > recommendations contained in this document are reasonably held or > made as at > the time of compilation. However, no warranty is made as to the > accuracy or > reliability of any estimates, opinions, conclusions, recommendations > (which > may change without notice) or other information contained in this > document > and, to the maximum extent permitted by law, the Goldman Sachs > JBWere Group > disclaims all liability and responsibility for any direct or > indirect loss > or damage which may be suffered by any recipient through relying on > anything > contained or omitted from this document. > > Goldman Sachs JBWere does not represent or warrant the attached > files are > free from computer viruses or other defects. The attached files are > provided, and may only be used, on the basis that the user assumes > all > responsibility for any loss, damage or consequence resulting > directly or > indirectly from use. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > Goldman Sachs JBWere > Disclosure of Interest > ORG: Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek > compensation for financial and advisory services in the next 3 months from the > company, its parent, or its wholly owned or majority owned subsidiary. > > > > Goldman Sachs JBWere > Disclosure of Interest > SUN: Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek > compensation for financial and advisory services in the next 3 months from the > company, its parent, or its wholly owned or majority owned subsidiary. > SUN: Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek > compensation for financial and advisory services in the next 3 months from the > company or its affiliates. > > > > GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER > > Goldman Sachs JBWere Pty Ltd and its related entities distributing this document and > each of their respective directors, officers and agents ("the Goldman Sachs JBWere > Group") believe that the information contained in this document is correct and that > any estimates, opinions, conclusions or recommendations contained in this document > are reasonably held or made as at the time of compilation. However, no warranty is > made as to the accuracy or reliability of any estimates, opinions, conclusions, > recommendations (which may change without notice) or other information contained in > this document and, to the maximum extent permitted by law, the Goldman Sachs JBWere > Group disclaims all liability and responsibility for any direct or indirect loss or > damage which may be suffered by any recipient through relying on anything contained > or omitted from this document. > > Goldman Sachs JBWere does not represent or warrant the attached files are free from > computer viruses or other defects. The attached files are provided, and may only be > used, on the basis that the user assumes all responsibility for any loss, damage or > consequence resulting directly or indirectly from use. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
