[RFE] Access to Field, Method and Constructor without the use of Strings

[Carl Rosenberger]

Hi all,

I submitted the following RFE to Sun's RFE page.

As a reply I received a mail from Girish Manwani at Sun that I
should start a discussion in one of the Java newsgroups (Huh?).
To my knowledge, this is the most appropriate group. Here gos:


A DESCRIPTION OF THE REQUEST:
It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

// Assuming the following class
public class Foo {

String bar;

public Foo(String bar) {
this.bar = bar;
}

public void fly(String to) {
bar = to;
}
}

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});

There are other possible options for the syntax. I would just like to see
this principally possible.

The construct is similar to the ClassName.class syntax and it can be treated
by the Compiler in the same way:
It could produce the getDeclaredField, getDeclaredMethod and getConstructor
bytecode. No modifications to the JVM would be necessary.

JUSTIFICATION :
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

A notation without strings could be very easily refactored by IDEs.

We would specifically need the feature for our typesafe querying system,
so it could work completely without strings.
http://sodaquery.sf.net/

The possibility to get Method objects without strings, would encourage many
developers to use them for more dynamic programming and would result in lots
of more flexible libraries for the Java platform.


Thanks in advance for your attention and for positive comments.


Kind regards,
Carl

 

[soft-eng]

Hi all,

I submitted the following RFE to Sun's RFE page.

As a reply I received a mail from Girish Manwani at Sun that I
should start a discussion in one of the Java newsgroups (Huh?).

Interesting. I wonder if that means Sun actually monitors
Java newsgroups, or if that is their polite way to
say "go away, we are too busy"!

FWIW, Sounds like a small and useful addition.
(Then there was the variable-shadowing issue discussed
elsewhere, though I don't know if that can
be fixed without breaking existing code.)

 

[Larry A Barowski]

Hi all,

I submitted the following RFE to Sun's RFE page.

...

A DESCRIPTION OF THE REQUEST:
It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

...

JUSTIFICATION :
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

A notation without strings could be very easily refactored by IDEs.

...

But the usual reason for using reflection is that those
classes/fields/methods/constructors don't exist at compile time
and may or may not exist at run time.


-Larry Barowski

 

[Bent C Dalager]

Hi all,

I submitted the following RFE to Sun's RFE page.

I'm behind you all the way

I have two main reasons for wanting this. First, it would make me feel
a lot easier about the legacy library we have that makes heavy use of
field reflection. Right now, detection of typos is effectively left to
run-time and I really really hate that. Second, it would become
feasible to make heavier use of reflection without feeling that you're
programming Perl or something.

Is it possible to vote for this RFE on Sun's site?

Cheers
Bent D

 

[Gordon Beaton]

The existance of the field/method/constructor could be checked
during compile time. Typos would no longer be possible.

It could only be checked at compile time if the compiler has access to
the class in question.

And if that's the case, you can use "regular" syntax to access the
fields and get the checking you're asking for, without using
reflection at all.

/gordon

 

[Carl Rosenberger]

I'm behind you all the way

Thanks for the backup.

Is it possible to vote for this RFE on Sun's site?

I don't think so. Attached I send along the answer from Sun.

It tells me to discuss the theme in a newsgroup and to
submit the RFE again, if there is positive feedback.

Funny:
I submitted a similar RFE for access to methods only, more
than three years ago. At that time my suggestion as to the
syntax wasn't too good but the idea was the same. I can attach
the answer I received at that time to this mail also.

How many times do they want me to submit this RFE until it
gos into the database?

Cheers,
Carl



******************************* Answer 2 *** 2003 **************************

-----Original Message-----
From: Girish Manwani [mailto:[email protected]]
Sent: Donnerstag, 14. August 2003 22:03
To: (e-mail address removed)
Cc: (e-mail address removed)
Subject: Re: (Incident Review ID: 185015) Access
java.lang.reflect.Field, Method and Constructor objects without strings



Hi Carl Rosenberger,

Thank you for using our bug submit page. There may be merit to
your request for feature enhancement (RFE). I would suggest
that you first post this to a newsgroup and request comment from
other java developers.

You can view a list of Java newsgroups at:

http://java.sun.com/aboutJava/newsgroups.html


Based on the responses, please feel free to submit a new RFE
containing a link to the newsgroup. Thank you for your time.

Regards,
Girish
----------------- Original Bug Report-------------------

category : java
release : 1.4.1
subcategory : classes_lang
type : rfe
synopsis : Access java.lang.reflect.Field, Method and Constructor
objects without strings
description : A DESCRIPTION OF THE REQUEST :
It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

// Assuming the following class
public class Foo {
String bar;
public Foo(String bar) {
this.bar = bar;
}
public void fly(String to) {
bar = to;
}
}

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new
Object[]{String.class});

There are other possible options for the syntax. I would just
like to see this principally possible.

The construct is similar to the ClassName.class syntax and it can
be treated by the Compiler in the same way:
It could produce the getDeclaredField, getDeclaredMethod and
getConstructor bytecode. No modifications to the JVM would be necessary.

JUSTIFICATION :
The existance of the field/method/constructor could be checked
during compile time. Typos would no longer be possible.

A notation without strings could be very easily refactored by IDEs.

We would specifically need the feature for our typesafe querying
system, so it could work completely without strings.
http://sodaquery.sf.net/

The possibility to get Method objects without strings, would
encourage many developers to use them for more dynamic
programming and would result in lots of more flexible libraries
for the Java platform.
workaround :
suggested_val :
cust_name : Carl Rosenberger
cust_email : (e-mail address removed)
jdcid : CarlRosenberger
keyword : webbug
company : db4o
hardware : x86
OSversion : win_nt_4.0
bugtraqID : 0
dateCreated : 2003-04-29 06:29:20.9
dateEvaluated : 2003-08-14 14:03:03.296

******************************* Answer 1 *** 2000 **************************

-----Original Message-----
From: Sean Lane [mailto:[email protected]]
Sent: Montag, 10. Juli 2000 19:52
To: (e-mail address removed)
Subject: Re: (Review ID: 104615) Access to Method object without String
detour through getMethod


I apologize for the length of time it has taken for someone to
respond to you regarding this Bug Report you have made.
I hope you will not be offended by us contacting you after
such a long time. We are very concerned about every Bug
Report that we receive and with the volume we receive
we have not able to address all of them is the timely manner
that we would like. We are looking through our older Bug
Reports and are trying to find out if these issues are still
relevant to our customers and want to know if the problem
still exists in our more recent release.

Please let me know if this problem still exists for you.

Sean Lane

P.S.--
The following is the most recent release and
its download site:

JDK 1.3 - http://java.sun.com/j2se/1.3/


----------------- Original Bug Report-------------------

category : java
subcategory : classes_lang
type : rfe
synopsis : Access to Method object without String detour through getMethod
description : java version "1.2.2"
Classic VM (build JDK-1.2.2-004, native threads, symcjit)

I would like to be able to store methods into Method variables without the
detour through Class.getMethod(String, Class[]).

String names for methods within sourcecode
- are not very performant
- can not be checked by the compiler

Something like the following would be great:

import java.lang.reflect.*;
public class MyClass
{
public void myMethod(){
Method foo = new Method(MyClass.myMethod);
// Alternatives:
Method foo = new Method(MyClass.myMethod());
Method foo = new Method(MyClass.class.myMethod);
Method foo = new Method(MyClass.class.myMethod());
Method foo = this.getClass().getMethod(MyClass.myMethod);
Method foo = this.getClass().getMethod(MyClass.myMethod());
// Maybe sun can think of the syntactic right Java way for this.
}
}
workaround : I use an object to cache the Method so I only need a
single call to getMethod.
I still find the String representation of method names spread
throughout my
code very irritating.

A portion of my code:

package de.cros.collection;

import java.lang.reflect.*;

public class MethodProperty extends CollectionObjectProperty
{
private String i_methodName;
private Method i_Method;

public MethodProperty(Collection a_Collection, String a_methodName){
super(a_Collection);
i_methodName = a_methodName;
try{
i_Method =
a_Collection.getCollectedClass().getMethod
(a_methodName,null);
}
catch(Exception l_ex){
i_Method = null;
}
}

Object get(Object a_Object) throws IllegalAccessException,
NoSuchMethodException, InvocationTargetException{
return method(a_Object).invoke(a_Object, null);
}

private Method method(Object a_Object) throws NoSuchMethodException{
if (i_Method != null){
return i_Method;
}
return a_Object.getClass().getMethod(i_methodName, null);
}
}
suggested_val :
cust_name : Carl Rosenberger
cust_email : (e-mail address removed)
jdcid : CarlRosenberger
keyword : webbug
company : c-ros www.c-ros.de
release : 1.2.2
hardware : x86
OSversion : win_nt_4.0
priority : 4
bugtraqID : 0
dateCreated : 2000-05-09 04:16:16.0
dateEvaluated : 2000-07-10 10:51:38.1

 

[rick]

description : A DESCRIPTION OF THE REQUEST :

It should be possible to obtain references to Field, Method and
Constructor objects without the use of strings. Proposed syntax:

// Assuming the following class
public class Foo {
String bar;
public Foo(String bar) {
this.bar = bar;
}
public void fly(String to) {
bar = to;
}
}

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new
Object[]{String.class});

I think it's a good idea, too.

 

[Paul Ebermann]

"Gordon Beaton" skribis:

It could only be checked at compile time if the compiler has access to
the class in question.

And if that's the case, you can use "regular" syntax to access the
fields and get the checking you're asking for, without using
reflection at all.

Think of an API, which works by reflection.

(S.O.D.A., which Carl mentioned, is such one.)

While _you_ know the structure of the classes,
on which to work, the API-implementation does
not (and can't, since they are compiled seperately).
So it is not possible to use "regular syntax".

You have to give the names of the Fields to
the API - or the Field-Objects.
Now, you'll have to use Strings por specifiing
them - and typos will be catched first in runtime.

With Carl's proposal, you could give Field-Objects,
simply specifiing the name.


Paul

(Please forgive my bad english - I normally
only write in german and Esperanto newsgroups.)

 

[Carl Rosenberger]

Hi all,

following the above directions, I just submitted another
RFE (the third time) to the Java bug database.

I would really appreciate further "+1" comments in this
thread, should anyone else be interested to see this
feature.

It's a very small addition to the compiler and I know,
the merit for dynamic programming would be great. We
would really love to see the feature to be able to
provide the first completely typesafe object querying
system:
http://sourceforge.net/projects/sodaquery/

Thanks!

Cheers,
Carl

 

[Frank Radermacher]

Carl Rosenberger wrote:

It's a very small addition to the compiler and I know,
the merit for dynamic programming would be great. We
would really love to see the feature to be able to
provide the first completely typesafe object querying
system:
http://sourceforge.net/projects/sodaquery/

Hi,

I think that the mentioned addition to the syntax would be very useful
not only for query systems. I would lead to a much more "hygienical"
code anywhere you make heavy use of metadata.

Frank

P.S. +1

 

[Aljoscha Rittner]

I submitted the following RFE to Sun's RFE page.
[...]

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});

There are other possible options for the syntax. I would just like to see
this principally possible.

I think the qualifier .class. is a good idea. It ensures compatibility
to accessible fieldnames.

An other syntax:

Foo.class.fields.bar;

Foo.class.methods.fly (new Object[] {String.class});

I think this syntax is easier to read. fields and methods are like
"collections" (see below my extensions)

[...]

JUSTIFICATION :
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

But why? Reflection (scripting) is a runtime checked behavior.

A notation without strings could be very easily refactored by IDEs.
ACK.

The possibility to get Method objects without strings, would encourage many
developers to use them for more dynamic programming and would result in lots
of more flexible libraries for the Java platform.

In addition string queries could by usefull:

Foo.class.fields ("foo");

or:

public Object get (String fieldName)
throws // Foo.class.fields (fieldName):
SecurityException, NoSuchFieldException,
// .get (this):
IllegalArgumentException, IllegalAccessException
{
return Foo.class.fields (fieldName).get (this);
}

IMHO this is a little problem: We have a bunch of exceptions for a
single field access.

Next example (with my syntax):

public static Object invoke (Object obj, String method)
throws // Foo.class.methods (method, null):
SecurityException, NoSuchMethodException,
// .invoke (obj, null)
IllegalAccessException, IllegalArgumentException,
InvocationTargetException

{
return Foo.class.methods (method, null).invoke (obj, null);
}

Five exceptions (ok +2: NPE and ExceptionInInitializerError), phew.
But much easier than the current reflection api.

Thanks in advance for your attention and for positive comments.

+1

regards,
josh (sorry for my bad english)

 

[Peter =?iso-8859-1?Q?B=FCttner?=]

Carl Rosenberger schrieb:

I submitted the following RFE to Sun's RFE page.

[...]

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});

There are other possible options for the syntax. I would just like to see
this principally possible.

An other syntax:
Foo.class.fields.bar;
Foo.class.methods.fly (new Object[] {String.class});

I think this syntax is easier to read. fields and methods are like
"collections" (see below my extensions)

This was my idea.

We access all members, not only public?!

In addition string queries could by usefull:
Foo.class.fields ("foo");

right, but:
Foo.class.getDeclaredField("foo");
is nearly the same, so better add less.

Or get the whole bunch:
Field[] f = Foo.class.fields
Methods[] m = Foo.class.methods
Constructor[] c = Foo.class.constructors
...
This seems to change the language to much? And doesn't
help so much as the changes above:
Foo.class.fields.bar, Foo.class.methods.fly


+1

Peter

 

[Paul Ebermann]

"Aljoscha Rittner" skribis:

I submitted the following RFE to Sun's RFE page.
[...]

Field fooBarField = Foo.class.bar.field;
Method fooFlyMethod = Foo.class.fly.method(new Object[]{String.class});
Constructor fooConstructor = Foo.class.constructor(new Object[]{String.class});

There are other possible options for the syntax. I would just like to see
this principally possible.

I think the qualifier .class. is a good idea. It ensures compatibility
to accessible fieldnames.

An other syntax:

Foo.class.fields.bar;

Foo.class.methods.fly (new Object[] {String.class});

I would like not using any "new", since "new"
is evaluated at runtime (and we want compile-time
checks).

Method fooFlyMethod = Foo.class.fly.method(String);
Constructor fooConstructor = Foo.class.constructor(String);

or

Foo.class.methods.fly(String);

I think this syntax is easier to read. fields and methods are like
"collections" (see below my extensions)

[...]

JUSTIFICATION :
The existance of the field/method/constructor could be checked during compile
time. Typos would no longer be possible.

But why? Reflection (scripting) is a runtime checked behavior.

For only runtime you won't need a new syntax.

The idea (as I understands it) is to enable
compile-time-checking, wherever possible.

(It should not disable the runtime-checking, which
is necessary anyway.)

In addition string queries could by usefull:

Foo.class.fields ("foo");

For this already exists

Foo.class.getDeclaredField("foo");

and

Foo.class.getField("foo");


I see no need to use another Syntax with
only slightly less typing.


Paul
PS: +1

 

[rick]

Hi all,

following the above directions, I just submitted another
RFE (the third time) to the Java bug database.

I would really appreciate further "+1" comments in this
thread, should anyone else be interested to see this
feature.

+1

 

[Jochen Theodorou]

Carl Rosenberger schrieb:
[...]

I would really appreciate further "+1" comments in this
thread, should anyone else be interested to see this
feature.

+1

(Sorry 4 days without internet)

Byte theo

 

[Lee Fesperman]

I would really appreciate further "+1" comments in this
thread, should anyone else be interested to see this
feature.

It's a very small addition to the compiler and I know,
the merit for dynamic programming would be great. We
would really love to see the feature to be able to
provide the first completely typesafe object querying
system:
http://sourceforge.net/projects/sodaquery/

Hi Carl,

At this point, I have to give you a -1.

I think you need to provide more general arguments for a feature that changes the
language.

Object querying has very limited use and doesn't justify a language change.

Dynamic programming could be more general use, but I have serious doubts about it.

You're basically introducing a form of function pointers and variable pointers to Java.
This is definitely not OO programming.

It only supports partial type safety ... for the caller. The called methods would have
no type safety. They would receive anonymous references, to Method, Field, Constructor
objects.

I don't see dynamic references of this type as needed for Java. I find Java effective
for system programming as is.

 

[Carl Rosenberger]

At this point, I have to give you a -1.

Hi Lee,

I didn't expect anything else from you since you have
always been putting down all my postings.

I don't think we would do eachother any good with another
"Your database sucks." "No yours!" thread.

Coexistence should be our goal. SQL certainly has a future
and I think that Java method calls within an SQL query
principally are a good idea. The Evaluation/Callback feature
in S.O.D.A. is designed to make this possible also, when we
start building an SQL layer on top of S.O.D.A. It would
be nice if we would support very similar SQL dialects in
the future.

We both provide native Java engines so we will both benefit,
if Java get's a greater share as an accepted standard as
the No.1 database stored procedure language.

I think you need to provide more general arguments for
a feature that changes the language.

The feature does not change the language, it only provides
a design-time shortcut for:

try {
Class#getDeclaredField("");
} catch (NoSuchFieldException e) {
// Handling not necessary since the
// compiler ensures the field is there.
}

Changes to VMs will not be necessary, only the above small
addition would have to be introduced to the compiler. I
would estimate that to be less than an hour of work.

Object querying has very limited use

If you say so.

Funny, just yesterday someone posted to our newsgroup, that
he would like to see the feature I am talking about, without
the knowledge of this thread here. I will attach his message
to the end of this one.

The idea behind object queries:
They provide an abstraction layer as a base for other querying
systems like SQL, OQL, XPath, XQuery, JDOQL. With a common
object query system it would be possible to reuse multiple query
language parsers for all of the above query languages. All
parsers create a similar query expression tree so why not try
to set a standard at the lowest level possible? That would free
vendors from the work to write parsers themselves. Just by
implementing one standard they could support all the above query
languages. I do have some hope that Prevayler, OJB, and Hibernate
also will jump in on S.O.D.A., since I hear from them that they
are interested. I would love to share the work on query language
layers with these open source products.

and doesn't justify a language change.

The comments from the other people here come from completely
different areas, where dynamic programming is used.

I am just trying to provide one single concrete example of a
benefit.

All the best for FirstSQL!

Cheers,
Carl
--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com

and here is the posting to our newsgroup:

Hello

I'm currently evaluating db4o and I like it very much, especially its ease
of use.

But I think, the following improvement could make it even better:

1. In the trace output, there are no indications, how a query is
evaluated. Moreover if a column (e.g. in the descendent() method) is
misspelled, there's no error, warning or exception. The query just returns
nothing. To avoid the possibility of field misspelling, you could support a
parameter of type java.lang.reflect.Field. Could you also print out a
warning, if a field wasn't found?

2. If in the evaluate method the candidate is an actual descendent and
he is excluded, the parent should also be excluded.

3. Support a constrain on a specific array field (e.g.
descendent("myArray[5]").constrain(42).equal()).

4. If browsing the ObjectSet and other db4o classes in the debugger, it
seems, that the member variables are obfuscated. And it's really hard to
find out, what they mean.

Best regards
-- Pat

 

[Paul Ebermann]

"Carl Rosenberger" skribis:

Lee Fesperman wrote: [...]

I think you need to provide more general arguments for
a feature that changes the language.

The feature does not change the language, it only provides
a design-time shortcut for:

It _is_ a (small) addition to the language, but
in a backwards-compatible way.

try {
Class#getDeclaredField("");
} catch (NoSuchFieldException e) {
// Handling not necessary since the
// compiler ensures the field is there.
}

I think, better would be
---
try {
Class#getDeclaredField("");
} catch (NoSuchFieldException e) {
throw new NoSuchFieldError(e);
}
---

since there could be a difference
between runtime and compiletime (new
Class version, ...)

(And the "ignore" does not work, since then
the field-variable may be not initialized.)


Paul

 

[Lee Fesperman]

Hi Lee,

I didn't expect anything else from you since you have
always been putting down all my postings.

I don't think we would do eachother any good with another
"Your database sucks." "No yours!" thread.

I will say that a database newsgroup is more appropriate for database issues like that.
I am discussing this purely as a Java issue.

I do object to your characterizations, though. I always try to make my remarks
substantive.

The feature does not change the language...

No, you are wrong. It is a language change.

Changes to VMs will not be necessary, only the above small
addition would have to be introduced to the compiler. I
would estimate that to be less than an hour of work.

I don't care if it takes 5 minutes. My issue is whether it is an appropriate change to
the language.

If you say so.

Seems to be the crux of the matter.

The idea behind object queries:
They provide an abstraction layer as a base for other querying
systems like SQL, OQL, XPath, XQuery, JDOQL. With a common
object query system it would be possible to reuse multiple query
language parsers for all of the above query languages. ...

I don't see that. You are mixing declarative and navigational languages.

The comments from the other people here come from completely
different areas, where dynamic programming is used.

I am just trying to provide one single concrete example of a
benefit.

I know. I'm just saying that you need to present more convincing arguments for this.
The other posters haven't either. I presented arguments against this use (which you
snipped).

All the best for FirstSQL!

Thanks. I wish you well in your ventures.

No ill will intended. If you check back on my postings on cljp, you'll see that I am
quite conservative about changes to the Java language.

 

[Carl Rosenberger]

I don't see that. You are mixing declarative and navigational languages.

That's what your database engine does also:
It parses SQL and creates an object representation to be
processed by your query processor code.

A standard for the first step would reduce the necessary
implementation work for database products that don't
support SQL yet.

Kind regards,
Carl