I've used proxies in an object-relational tool, and they were used in that context to defer loading objects from the datastore until they are accessed for the first time. Querries return proxies to the data objects, and not the actual data objects themselves. How does this relate to the code-generation mechanism you were talking about? From what I've read, proxies act 'on-behalf' of the actual target of an invocation such that you can give the fascade that you are talking to an actual object, but you are talking to an object that can do some work before calling the actual class. Can you please explain where the concept of 'code-generation' comes into play here?

Templates are an intimate part of the language Chris. The compiler reads them and then translates them to IL - just like any other C++ code you write. If you don't believe me, simply confirm it with your favorite compiler / library implementer. You might consider Steve Clamage who works on the Forte C++ compiler for Sun, or perhaps Pete Becker who works on the Dinkumware Standard C++ library that ships with VC++, or even Greg Comeau who has written possibly the world's most conforming C++ compiler. They hang out at comp.lang.c++.moderated, so you might be able to catch them there.

The next question is: is there a way to view the c++ source that a STL generates? I didn't find much, but I did find this quote:

Not unless you enjoy looking at the object code. For example, where do you think all those template instantiations go in VC++? They go into the object files. Where do you think they go in Forte C++? Object files. The answer is the same for all of the C++ compilers you use. I challenge you to find one which does otherwise.

So, exactly how is STL not the code generator that I've been describing all this time? I understand that it's 'smart' and it handles recursion, etc etc, but I think it still amounts to copy-paste coding which can be a nightmare to maintain.

Here we go again. Exactly what disadvantages can you associate between copy-paste and templates?

R. claims that you just need to re-run your make and all the code will be re-generated, but that's one thing I like about java: you don't need to do an entire rebuild if you just change a single class.

You're not doing an entire rebuild if you change a template class in C++ either. Yes, the compiler / linker will automatically rebuild any template instantiations that are affected by a template change.

Generics allow you to define a full-fledged java object that is parameterized (aka "Parameterized Types") that if it changes, you only need to rebuild the PT and re-deploy.

Apples and oranges, Chris. In the situation that you want your templates to act like Java generics, your template code will delegate to functions outside of the template. You simply redeploy those functions.

How does this relate to the code-generation mechanism you were talking about?... Can you please explain where the concept of 'code-generation' comes into play here?

Umm... because Proxy generates code? I suggest you sit down with a good article on Proxy and spend some time looking at the source code for both Proxy and sun.misc.ProxyGenerator. In particular, I hope you'll find Proxy.getProxyClass() and ProxyGenerator.generateProxyClass() enlightening.

That's not really answering my question, Toby. For example, wrt STL, i showed examples of how code is generated from templates (reguardless of whether or not there was a actual c++ source artifact produced, code was generated base don the type). I'm asking you to produce an example of the use of a proxy that generates code. The getProxy() and generateProxyClass() are all methods executed at run-time, not at compile time like STL.

Just to be clear, we're not talking about STL anymore, we're talking about 'Proxies being code generators.' I look forward to seeing your example.

That's not really answering my question, Toby. For example, wrt STL, i showed examples of how code is generated from templates

Chris, you didn't show examples, you just twisted the text in an article to fit your needs. I did answer your question. The compiler generates code for templates just like it does for any other language construct. How can I make that more clear to you? Like I said, if you don't believe me, go ask the experts - even Stroustrup. They are nice guys, and they don't bite, I promise. I've already held conversations with each one of them. It wouldn't be nice, though, if I didn't warn you that they may laugh at you (that or killfile you) if you keep insisting that templates are in the same class as macros or copy and paste.

If you're unwilling to believe anybody else, no matter how clear the facts, why don't you do yourself a couple of favors. Purchase the Ansi C++ Standard for $18 and read it. Seriously, I'll front you the dough if you can't afford it. Then go download and examine the source code for gcc 3.1+.

I'm asking you to produce an example of the use of a proxy that generates code. The getProxy() and generateProxyClass() are all methods executed at run-time, not at compile time like STL.

Huh? All "code generators" generate code at "runtime". The code doesn't just drop out of mid-air. In the case of C++ templates, the code generator is the compiler. In the case of Proxy instances, the code generator is java.lang.reflect.Proxy.

Don't accuse me of twisting text of an article, that was a direct cut-and-paste of relavent sections of the article, and I gave a reference to the full article for anyone who wants more background.

As far as your response, you chose to ignore my statement that "We are not talking about STL, we are talking about Proxies as code generators" and decided to go on an off-topic rant. In addition, you say:

Quote

The compiler generates code for templates...

and then go on to say

Quote

All "code generators" generate code at "runtime".

So, compilers compile at runtime....[sarcasm]right[/sarcasm].

Anyways, getting back to the topic, your example doesn't demonstrate any code generation from proxies, you just created an object and passed in a few parameters. This is code generation? does that mean something like:

vector.add(new Object()) // this generates code??

actually generates some code based on the logic of your example? Of course not. Proxies are more akin to dynamic method invocation than code generations, and certainly have no resembelance to macros as you sugest here:

Quote

Do you believe java.lang.reflect.Proxy is basically a macro? If not, then how is it different? Then how does Proxy differ from templates? Hopefully, these questions will be rhetorical for you.

Perhaps you should explain (without saying 'read this book') how Proxies do not differ from Templates.

I wasn't trying to stray, but I see your point now.. templates can be designed to adapt much better than some sort of macro would.. (is that the point?)..

My point is that templates are a powerful first class language feature. Preprocessors (and hence macros) by their very nature are not. That is why macros suck and should be avoided at all costs and why templates rock.

I have to admit though taht my knowledge of C++ templates (which may be severely lacking) makes it seem that what you are talking about is akin to a fancy recursive macro.

I'm beginning to believe that you think that anything that operates on a meta level is a macro. Maybe you should state what you think a macro is?

Maybe generics in Java are not all that because the Java language tries to keep simple and elegant .. and a simple elegant way to do this meta-programming was too far off?

This is pretty close to the answer I got from Gilad Bracha (the spec lead for Java Generics). He basically said that they felt that a more powerful version of Java generics would have been too difficult for Java users. I personally prefer not to have the language dumbed-down to the level of VB. Reflection is a difficult (well I don't think so, but others do) part of the Java language too, but it's incredibly powerful and Java would be a much, much less useful language without it. But it's presence, doesn't mean that every Java programmer has to be an expert at it.

Can't you get a lot of that with Java Generics? I mean, there are existing ways to deal with that.. e..g. you can sort any objects that implement comparable.

No. Have you heard of concepts before? They are the C++ template equivalent of a Java interface. For example, the sort function defines the values of the iterator parameters to implement the LessThanComparable concept, which, roughly speaking, means that they must be able to compare to each other using the "<" operator. Concepts are actually more powerful than interfaces, in that they allow conformance through structure and not just name. On the other hand, specialization allows you to replace an entire function, method, or class altogether for a particular combination of types. It's quite powerful.

Which is why this seems to be a strrange conclusion.. I would have concluded "Right - so there isn't much to them, but they give you a lot."

Java generics don't enable anything whatsoever besides casting. That doesn't help anybody implement generic algorithms or containers in any fashion. Hopefully you're starting to see some of the differences here.

the fact that I worked with C++ for so many years and only recently hearing of these things is why I suggested that templates generally aren't used that way in most programs

Programs that use templates this way have been around for at least over five years. That's over half of Java's entire lifetime. Perhaps you don't keep up with C++ as much as you used to? For example, how many C++ journals do you read compared to Java journals? How many C++ newsgroups do you read as compared to Java newsgroups? It's easy to fall behind.

The whole Lambda-calculus thing for instance.. it seems mostly academic now.. how much programming is really done that way... in the grand scheme of things none (at he moment), regardless of it's power.

Come now, nobody's programming in functional languages? Lisp, Haskell, etc...? I personally know people who do. Besides all of that, the Standard C++ library is based on a functional approach. What do you think algorithms are? In fact, most C++ users have been complaining their heads off that they can't create lambda functions to use with their algorithms. This is one potential advantage that Java has over C++. Last time I checked, Gilad Bracha was working on a JSR to add lambda functions to Java.

So while I accept your point that generics could be vastly more powerful, and that C++ templates ARE more powerful, it still seems that the power is ultimately lost on the chumps like me that haven't caught on to it yet.. but since we chumps make up the bulk of the users (I'm making assumptions, I know) it isn't really worth it...

I'm not suggesting that Java be made into a vastly complex language. I'm suggesting that we get a more powerful generics mechanism. If it takes you a while to use the mechanism for more than shallow casts, then that's fine. Just like for those who use reflection at its very shallowest level - System.out.println( getClass().getName() ).

Don't accuse me of twisting text of an article, that was a direct cut-and-paste of relavent sections of the article, and I gave a reference to the full article for anyone who wants more background.

You derived a different meaning from the text of the article than the author intended. That's twisting the meaning.

As far as your response, you chose to ignore my statement that "We are not talking about STL, we are talking about Proxies as code generators" and decided to go on an off-topic rant.

What? Off-topic? Rant? I simply responded to your statements.

So, compilers compile at runtime....[sarcasm]right[/sarcasm].

Umm, they sure do Chris. What do you think a compiler is? Code that runs on your machine. When do template instantiations get created? As the compiler is running.

What do you think Proxy is? Code that runs on your machine. When do Proxy instances get created? As the Proxy is running.

Anyways, getting back to the topic, your example doesn't demonstrate any code generation from proxies, you just created an object and passed in a few parameters. This is code generation?

Ok Chris. If you can't see that the function Proxy.newProxyInstance actually generates (through delegation to sun.misc.ProxyGenerator) the byte code for an entirely new class and then loads that the class into the Java Virtual Machine, then nothing else I say can make any sense to you.

does that mean something like:vector.add(new Object()) // this generates code??actually generates some code based on the logic of your example?

You've managed to draw an analogy that makes no sense. I'm not impressed.

Proxies are more akin to dynamic method invocation than code generations

No they aren't. A Proxy doesn't dynamic dispatch to anything. Proxy generates the bytecode for a new class that implements the interfaces that you specify. That new class is hardcoded to call the InvocationHandler that you pass it. That's it. No dynamic method invocation whatsoever. Lots of code generation.

and certainly have no resembelance to macros as you sugest here:

Congratulations. You managed to answer the rhetorical question correctly. You win a $1000. (Well, maybe not). Proxy does not have a relationship to macros, and neither do templates. If you read that converation closely, you will see that I was saying that templates are like Proxy in that they are not like macros. They both have total respect for all of the features of their language.

If you can't see that the function Proxy.newProxyInstance actually generates (through delegation to sun.misc.ProxyGenerator) the byte code for an entirely new class and then loads that the class into the Java Virtual Machine, then nothing else I say can make any sense to you.

Ok, I did some reading on proxies, and I'm not sure where you got the information that bytecode was being generated, but this is my take on it (bearing in mind I didn't write the JVM nor the proxy classes API, I'm only relaying my understanding)....

First, I'm going to take the code you provided, and re-work it slightly to remove the annonymous class so that it's clearer what bytecode is being generated.

After we compile, we have 2 .class files with bytecode, the ActionListenerInvocationHandler and the ProxyBuilder. When this code runs, all the code is doing is dynamically building a class definition (indicating what class loader should be the 'owner' of the class, defining the interfaces that the class (the proxy) should implement and who should handle method invocations. All that's happening is a object is being built, but no new bytecodes are being produced, it's all using the standard reflection api to define the type at runtime. Also, I can dynamically decide how to handle the invocation at runtime by putting the required logic into the invocation handler's invoke() method.

When I wrote this:

Quote

vector.add(new Object()) // this generates code??

the analogy I was trying to show that building a list isn't code generation, and building a proxy is not code generation either. I hope that this is clearer now.

As an aside, do you consider yourself more of a C++ programmer than a Java programmer?

Ok, I did some reading on proxies, and I'm not sure where you got the information that bytecode was being generated, but this is my take on it

Where did I get my information from? Where did you get your (mis)information from? You don't seem interested in reading anything, but I'll suggest you try, http://www.sys-con.com/java/articleprint.cfm?id=1308, anyway. It's detailed enough to talk about the bytecode generation, and it's short, so hopefully it's right down your alley.

Personally, I read the Javadoc for Proxy, I read a couple of articles on Proxy, I used Proxy myself when I developed a JDO based O/R engine from scratch (got to love JavaCC for that JDOQL parsing), I wrote an article for CUJ (The Tattletale Technique) based on code I wrote for generic resource management that uses Proxy, and I actually read the source code for java.lang.reflect.Proxy and sun.misc.ProxyGenerator. It only takes about 1/10th of that to make it painfully obvious that Proxy does actually generate bytecode.

Btw, I don't appreciate the condescending rewrite and explanation of my code. It really doesn't reflect well on you as it demonstrates that you're missing the entire point of this discussion.

the analogy I was trying to show that building a list isn't code generation, and building a proxy is not code generation either. I hope that this is clearer now.

As I said before, you have managed to draw a meaningless analogy. Nothing has changed.

As an aside, do you consider yourself more of a C++ programmer than a Java programmer?

Actually I consider myself an excellent software engineer who happens to be particularly well-versed in both C++ and Java. The work I've done on Jace, http://jace.reyelts.com/jace, should demonstrate that. As an example, Jace has a tool that parses the bytecode in class files to generate C++ proxy classes, and it has another tool that modifies the bytecode (significantly more difficult than generation of bytecode) in .class files to add transparent C++ peer management (similar in ways to JDO enhancement).

I'm beginning to believe that you think that anything that operates on a meta level is a macro. Maybe you should state what you think a macro is?

I think that macros can sometimes be used to come to the same end. I understand that they are not the same.

Quote

I personally prefer not to have the language dumbed-down to the level of VB. Reflection is a difficult (well I don't think so, but others do) part of the Java language too

I agree. Reflection is great, and dumbing down a language is (usually) a bummer. That said, I don't mind much that Java doesn't have multiple inheritance or operator overloading... I think C++ is really pushing it on the operator overloading for instance >>, << for stream I/O and shifting seemed to be a bit of a stretch, but I admit I've gotten used to it.

Quote

No. Have you heard of concepts before? They are the C++ template equivalent of a Java interface.

I know what you are talking about, but I'm not that familiar with using the term 'concepts' in that context. I always considered using an abstract base class as an 'interface' to be a more direct equivalent to java's 'interface'.

Quote

For example, the sort function defines the values of the iterator parameters to implement the LessThanComparable concept, which, roughly speaking, means that they must be able to compare to each other using the "<" operator.

But the "<" operator is really nothing more than the Java compareTo method.. At least the difference is insignificant in the same way that 'java generics are just a fancy way to cast'. So I'm missing the point... I just don't see how 'concepts' are fundamentally different. They both appear to allow for generic programming.. at least to some degree. I mean, how is not writing an operator< any different from not implmenting the comparable interface? I believe you when you say 'concepts are more powerful', but what is not clear is "How much? and Why?"

Quote

Java generics don't enable anything whatsoever besides casting. That doesn't help anybody implement generic algorithms or containers in any fashion. Hopefully you're starting to see some of the differences here.

I'm afraid I'm not yet seeing the differences, as I think generics do help, BY elminating the casting. Just as any high level language helps by allowing me to not write everything in machine code. That's ultimately all any language feature is doing for you, be it 'concepts', generics, templates, whatever...

Quote

Programs that use templates this way have been around for at least over five years. That's over half of Java's entire lifetime.

That wasn't the point.. programs that use templates for anything more than saving you what you could get with some tedious cut and paste have been, in my experience, hard to come by. I just don't see functional languages being used much. Lisp has been around for ages, and I only know of one program in wide spread use (Emacs) that has anything to do with it. I've heard of Haskell, I think I read a bit about it, and came to the same conclusion.. it hasn't caught on, sure it is used, but for much less than 1% of the software development going on in the world. (another assuption, I know)

Quote

Perhaps you don't keep up with C++ as much as you used to? For example, how many C++ journals do you read compared to Java journals? How many C++ newsgroups do you read as compared to Java newsgroups? It's easy to fall behind.

Very true, I don't keep up as much as I would like.. that's sort of what I'm trying to do here - I figure I learn it faster if you shove it down my throat . I'm just at the stage where I am trying to get used to proper use of C++ templates and Smart pointers and C++ resouce management in the face of C++ exceptions.. they are all areas that I know I need to develope in. This thread is helping to open some other possiblities.. I wish I had more time to practice this stuff.. as I fear I have already fallen too far behind. I tried to get things moving in that direction at my last workplace, but the rest of the team were happy with something only slightly beyond C++ as a better C.. our object oriented design was lacking.. i got violent protests from the use of C++ templates.. mainly because the tools made them so hard to debug! (Try setting a break point in a specific instantiation of a template.. ugh!)

BTW.. Thanks for Jace.. I now remember checking it out quite awhile ago, and you reminding me of it here made me take another look.. I just may have a good opportunity to use it in my next project. It looks quite cool.

Good article. I only had the Javadocs on Proxy to glean my understanding from (and using them in practice doesn't always reveal how things are done under the covers). Based on the article, you are correct that a byte[] is being generated and processed by a ClassLoader when a Proxy is being generated. Unfortunately, some things are left unclear.

I coudln't find 'Listing 5' to see what the decompiled Proxy does. Obviously I can't argue that bytecodes aren't being generated, but without seeing what Listing 5 is, I'd like to propose that the bytecodes generated are more 'metadata' then implementation code (I'm wondering what resembelance to the decompiled proxy file would look vs a decompiled interface file). My comparision between STL and Proxy generation is (and I still am not sure that my assumption is wrong) is that in the case of STL, the code within the template is duplicated, if I had a sprintf("Hello world") in my template, the binary code that tells the OS to output "Hello World" would be duplicated once in each instance of the template type (If no, why would I need to re-build the generated classes to get the new changes?). In the case of the proxy, the are bytecodes that I have in my InvocationHandler being used for every proxy instance I create to implement the proxy, or is the invocation handler being copied into the new proxy that was generated? Is the implementation of the Proxy forced to create a byte[] of bytecode because, currently, that's the only way to interface with the class loader to build a Class at runtime? Does anyone else feel that by embedding the bytecode specification into the API, that if the bytecode spec changes they need to remember to not only update the compilers (javac) but also go back to this one class and update _it_ so that it generates proper bytecode? I liked the separation between the API and bytecode but now it just got tighter-coupled. Hopefully they will introduce in the future an API to dynamically define classes through method invocation instead of writing a raw bytestream and loading it into the class loader. Seems like a kludge.

Quote

Btw, I don't appreciate the condescending rewrite and explanation of my code. It really doesn't reflect well on you as it demonstrates that you're missing the entire point of this discussion.

Get over it.

Quote

As I said before, you have managed to draw a meaningless analogy. Nothing has changed.

Nice attitude. Another possible response could have been 'If proxy generation involved building a class through an API and not producing bytecode that is processed by a ClassLoader, it might apply, but that's not what has been shown to be the case.' For someone who concludes with 'God bless' after every post, you certainly have a remarkable lack of consideration for another person's point of view.

Ok, found listing 5, and the bytecode generated creates a big wrapper. I can see why the author of the article wasn't impressed by the proxy. I don't really see the InvocationHandler code being generated in the generated Proxy0.class tho, unless I'm reading too deeply into your comparison between Proxy and STL...I got the impression that I should have no problem with what STLs are doing because Proxies are doing the same thing...and, again, my problem with STL is the copy-paste coding style not so much as a 'code generator' like the Proxy is...I'm not sure why you brought it up...is this what you call a 'straw man'?

I think that macros can sometimes be used to come to the same end. I understand that they are not the same.

Macros can be used to do all sorts of things, for example, you can implement inheritance, reflection, and serialization with macros. That doesn't mean that macros are more than shallowly related to first class implementations of those mechanisms.

That said, I don't mind much that Java doesn't have multiple inheritance or operator overloading...

Java does have multiple inheritance - It's just multiple interface inheritance. I've found multiple implementation inheritance can be useful (for example, it gets used in Jace to make java::lang::Throwable both a std::exception and a java::lang::Object), but I rarely use it.

I think C++ is really pushing it on the operator overloading for instance >>, << for stream I/O and shifting seemed to be a bit of a stretch, but I admit I've gotten used to it.

Operator overloading is nice, but it's abused terribly. Outside of mathematic code, I find that operators are powerful in that they allow primitives to be treated polymorphically along with other class types in templates. That's incredibly useful.

Of course all of these things are peripheral to the primary discussion - Java generics and templates.

I know what you are talking about, but I'm not that familiar with using the term 'concepts' in that context. I always considered using an abstract base class as an 'interface' to be a more direct equivalent to java's 'interface'....

You dance all around the point here. Yes, a pure abstract C++ class is the direct equivalent of a Java interface. However, I stated that a concept is the C++ _template_ equivalent of a Java interface. Java has no direct analog for a concept. Templates implement compile-time polymorphism and operate on structural conformance. A concept describes compile time structural conformance. An interface describes run time named conformance.

But the "<" operator is really nothing more than the Java compareTo method..

Yes, my point last time was that concepts are indeed used like Java interfaces. I was trying to explain that the LessThanComparable concept was roughly equivalent to the Comparable interface. The larger goal was to correct the misunderstanding that C++ template specializations were somehow related to Java interfaces.

I just don't see how 'concepts' are fundamentally different.

Like I said, concepts operate on structural conformance, which is more powerful. It's what allows for cool things like traits and policy classes and non-virtual polymorphism in general. But again, that's not the main point. The main point was correcting the misunderstanding concerning specialization.

I think generics do help, BY elminating the casting.

I'm not arguing that eliminating casting is bad, just like I wouldn't argue that retrieving the name of a class at runtime is bad. However, if that was the only capability reflection had, you'd be seeing me ranting about how much reflection sucks.

That wasn't the point.. programs that use templates for anything more than saving you what you could get with some tedious cut and paste have been, in my experience, hard to come by.

Okay, first, Java generics aren't powerful enough to even save you from lots of cut and paste. Repeat with me, Java generics only add casts.

Second, even if you don't personally write code that makes use of advanced template features, you use the Standard C++ Library, which makes use of them.

Outside of that, I believe the C++ code you work with is probably heavily biased (correct me if I'm wrong).

I'm just at the stage where I am trying to get used to proper use of C++ templates and Smart pointers and C++ resouce management in the face of C++ exceptions..

Right, you are more concerned about basic C++ coding than advanced use of C++. That shouldn't prevent other programmers from making use of powerful C++ techniques. If you were just at the stage of learning how to properly prevent object leaks in your Java code, would you want to prevent someone else from using anonymous inner classes?

I tried to get things moving in that direction at my last workplace...

I'm sorry to hear that's the environment you work in. I have recently had to work with people who have a hard time using C++ even as a better C.

i got violent protests from the use of C++ templates.. mainly because the tools made them so hard to debug! (Try setting a break point in a specific instantiation of a template.. ugh!)

Humm... In VC++ you can set a breakpoint in any particular instantiation of a template. Just set the breakpoint in your template definition, Hit Alt+F9 (Edit->Breakpoints) and breakpoints for all of the different instantiations of that template will be set. You can remove the ones you're not interested in. I have seen where this doesn't show up correctly until you make a trial run through your code.

BTW.. Thanks for Jace.. I just may have a good opportunity to use it in my next project.

Okay, first, Java generics aren't powerful enough to even save you from lots of cut and paste. Repeat with me, Java generics only add casts.

Did you mean remove casts? And doesn't generics give you compile time type safety of collections (Like I can't add a String to a Vector<Integer> without generating an error at compile time) on top of the fact that i don't need to do something like (Integer)v.get(key) (where generics remove the need for casting). I'm a big fan of find out problems at compile time. I can understand that Templates in general have evolved into a very powerful tool, it sounds like it supports lots of features such as AOP, Concepts, etc, in addition to parameterized types, I think the scope of Generics is much much smaller (only support parameterized types). If the overall theme is that you want Java to do more, better, I don't think anyone would say they didn't want that too. Perhaps the label 'Generics' placed on the parameterized type functionality is stretching the term too much based on your C++ background, but from my perspective, I see it fulfilling a specific need. I wish I had more background in in the other aspects that are being described here, but I don't, so I can only argue why it's good enough for me.

Operator overloading is nice, but it's abused terribly. ...operators ... allow primitives to be treated polymorphically along with other class types in templates. That's incredibly useful.

I agree completely.

Quote

You dance all around the point here.

Sorry, about that.. but it's because I'm just not seeing it clearly. The things you describe, 'concepts', and uses in STL for instance, don't seem to be using those advanced concepts in a way that is unique enough that Java doesn't have a facility for doing the same thing with similar effort (with generics). STL generic algorithms and container classes (the bulk of my experiece with STL, if I'm missing something big let me know) can all be implemented in Java with generics and interfaces.. or so it would appear. So I'm missing where the 'advanced' C++ templates are coming into play. So far the examples of computing a factorial, or unrolling loops are all I have. Useful for sure, but not enough (for me) to rant over.

Quote

non-virtual polymorphism

This sounds like the bit I'm missing.. perhaps I really need to learn more about what that really means.. as my Java examples with interfaces are 'virtual polymorphism'

Quote

Right, you are more concerned about basic C++ coding than advanced use of C++. That shouldn't prevent other programmers from making use of powerful C++ techniques.

Absolutely true, but I also don't want the language polluted with fancy tricks that just give programmers enough rope to hang themselves. Because not having to deal with that stuff is part of what I like about Java.

Quote

In VC++ you can set a breakpoint in any particular instantiation of a template.

Ah, but I was doing device driver work, and SoftIce and templates didn't get along so well... Shoot, I had arguments just with respect to moving to C++ for kernel mode drivers. I would have hated to lose that one :).

Another problem was the horrible error messages that the compiler spewed forth when something very simple was wrong with template based code... Trying to figure out the actual location of the error was quite a pain. I'm hoping that VC 7 and other compilers are getting better at that.

Sorry, about that.. but it's because I'm just not seeing it clearly....

Oh well, I've tried my best to explain them in a few short posts, but I obviously do not seem to be doing a good job. We can always discuss this further, if you decide to pursue learning more about templates someday.

Absolutely true, but I also don't want the language polluted with fancy tricks that just give programmers enough rope to hang themselves.

A fool can hang himself with anything. Languages should follow the principle of least surprise and shouldn't fail miserably (coredump, exhibit undefined behavior, etc...) when used incorrectly. Making Java generics more powerful wouldn't change any of that.

Ah, but I was doing device driver work, and SoftIce and templates didn't get along so well...

Sorry, I don't know anything about SoftIce, so I can't help you there. Frankly though, that's simply a QOI issue with respect to one vendor.

Another problem was the horrible error messages that the compiler spewed forth...

It's derived from personal attacks and constant affirmation of misinformation and denial of facts.

For someone who concludes with 'God bless' after every post, you certainly have a remarkable lack of consideration for another person's point of view.

I have little patience for obvious nonsense, especially when it comes from those who refuse to avail themselves of any of the relevant publicly available information. I strive to be patient for those who genuinely care.

I don't really see the InvocationHandler code being generated in the generated Proxy0.class tho

I never said it was. I said that Proxy generates classes that directly invoke the InvocationHandler - in opposition to your statement that Proxy simply wraps dynamic dispatch to the InvocationHandler.

I got the impression that I should have no problem with what STLs are doing because Proxies are doing the same thing...and, again, my problem with STL is the copy-paste coding style not so much as a 'code generator' like the Proxy is

Chris, you leave me no choice. I don't have the time to argue against templates as "copy-paste" with you anymore. You won't read the facts on your own and you won't listen to the facts either. I do hope this discussion eventually pushes you into learning more about them.

Did you mean remove casts?

No, I meant what I said. The compiler will generate casts in the bytecode where you have none in your source code. (As compared to C++ templates, where there are no hidden costs).

And doesn't generics give you compile time type safety of collections.

Yes - I consider this to be the same feature as adding casts. As an aside, Java generics will let you perform unsafe assignments with warnings.

I'm a big fan of find out problems at compile time.

As am I, yet in the seven or so odd years I've been writing Java code, I've only casted a container element to the wrong type once.

Perhaps the label 'Generics' placed on the parameterized type functionality is stretching the term too much based on your C++ background.

Yes, perhaps Java generics should be renamed "Type Auto-casting with Bonus Covariant Return Types". (This is also hilarious. Rather than introduce covariant return types as a first class Java feature, we're creating a hacked implementation of it that is joined with the support for generics).

No, I meant what I said. The compiler will generate casts in the bytecode where you have none in your source code. (As compared to C++ templates, where there are no hidden costs).

Suppose that this was the case only to provide byte-code compatability for legacy JVMs, but in the future the byte-code spec would be modified to support the parameterized-type natively? It should meean that no casts are performed at runtime. This would be good, no?

Suppose that this was the case only to provide byte-code compatability for legacy JVMs, but in the future the byte-code spec would be modified to support the parameterized-type natively? It should meean that no casts are performed at runtime. This would be good, no?

Suppose that this was the case only to provide byte-code compatability for legacy JVMs, but in the future the byte-code spec would be modified to support the parameterized-type natively? It should meean that no casts are performed at runtime. This would be good, no?

This might not need the VM spec be modified.

The native JIT compiler could possibly optimize the casting verification away based on extended properties found in the class file left there by the java compiler.

I still find generics in Java, although somewhat useful, to be a rather bulky hack. I mean, it's not a very elegant solution, adding hidden methods (not in the source code) behind your back. This is of course unavoidable when you aim to maintain backwards compatibility.

Yes, strictly speaking, it is possible that some improvements to Java generics could be realized without updating the VM spec. Of course, this would then rely on new unspecified conventions, for example, the use of special new JVM attributes for generics. I have a feeling that Sun felt that that would be tantamount to a spec change.

I still find generics in Java, although somewhat useful, to be a rather bulky hack.

I agree that it's pretty much a hack, although some people may feel that it was elegant considering the particular goals (backwards compatibility, container auto-casting) the spec team had in mind.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org