Johan Compagner

from 0.9 to 0.10 is not back, but forward 9 + 1 is 10...

0.9 doesnt have to become 1.0

from 0.9 to 0.10 is not back, but forward 9 + 1 is 10...

0.9 doesnt have to become 1.0

from 0.9 to 0.10 is not back, but forward 9 + 1 is 10...

0.9 doesnt have to become 1.0

we throught about such model, thx for pointing to a implementation..

problem is that how to get that first jar and execute it with those arguments.. Thats way to much for an average user and we have a problem because we use urls for "deep linking" so if you use url X then the application (same app code) starts up loading X and if you use url Y then the application is called with other arguments so it is configureds and loads solutio Y... So we push quite some arguments to the applicatio from the server to the client with the jnlp, don't know if that is easy to do with GetDown..

we throught about such model, thx for pointing to a implementation..

problem is that how to get that first jar and execute it with those arguments.. Thats way to much for an average user and we have a problem because we use urls for "deep linking" so if you use url X then the application (same app code) starts up loading X and if you use url Y then the application is called with other arguments so it is configureds and loads solutio Y... So we push quite some arguments to the applicatio from the server to the client with the jnlp, don't know if that is easy to do with GetDown..

we throught about such model, thx for pointing to a implementation..

problem is that how to get that first jar and execute it with those arguments.. Thats way to much for an average user and we have a problem because we use urls for "deep linking" so if you use url X then the application (same app code) starts up loading X and if you use url Y then the application is called with other arguments so it is configureds and loads solutio Y... So we push quite some arguments to the applicatio from the server to the client with the jnlp, don't know if that is easy to do with GetDown..

we throught about such model, thx for pointing to a implementation..

problem is that how to get that first jar and execute it with those arguments.. Thats way to much for an average user and we have a problem because we use urls for "deep linking" so if you use url X then the application (same app code) starts up loading X and if you use url Y then the application is called with other arguments so it is configureds and loads solutio Y... So we push quite some arguments to the applicatio from the server to the client with the jnlp, don't know if that is easy to do with GetDown..

> http://www.javagaming.org/index.php/topic,22230.0.html

that site exactly also sums up the things we found, i already made bug reports for most of them yes.

Especially that all our extension jnlp files now also need and must ask for all permissions... Else we still get that mixed mode dialog.. Very weird, you force now that the extension must ask for something they even dont want or need.

> http://www.javagaming.org/index.php/topic,22230.0.html

that site exactly also sums up the things we found, i already made bug reports for most of them yes.

Especially that all our extension jnlp files now also need and must ask for all permissions... Else we still get that mixed mode dialog.. Very weird, you force now that the extension must ask for something they even dont want or need.

and our solution is just exactly that.

It is a webstart applicaiton that is launched by downloading it from a https site, but without that site running also our server portion the application itself is useless. Because the client side is more or less a "browser" for the data that comes from that site (a tomcat application server)

So it is a always connected webstart application of the server it is coming from.

The thing is with signed application the only thing it does for you is that you can validate where it comes from. Or validate who made it so that you can trust it, the same is for a https site where you fill in your credit card information. You know 2 things, you know that the communications is encrypted, and you know that you talk to the person/site that you expect to talk to. And thats just the same when downloading jar files. You know where it comes from, you know for sure that it really comes from that site, and you know who is giving you those files because you do know and trust the site.. So what is the difference? Which other security do you think you get by adding a layer of signed jnlp and jar files on top of that? Do you think that because of that you dont get keyloggers? If you install such a program then with a signed jar or with a https site you know where you can go and complain to. There is not a big difference, its just what you trust. Do you trust the site, do you trust the company that signed the jar?

and our solution is just exactly that.

It is a webstart applicaiton that is launched by downloading it from a https site, but without that site running also our server portion the application itself is useless. Because the client side is more or less a "browser" for the data that comes from that site (a tomcat application server)

So it is a always connected webstart application of the server it is coming from.

The thing is with signed application the only thing it does for you is that you can validate where it comes from. Or validate who made it so that you can trust it, the same is for a https site where you fill in your credit card information. You know 2 things, you know that the communications is encrypted, and you know that you talk to the person/site that you expect to talk to. And thats just the same when downloading jar files. You know where it comes from, you know for sure that it really comes from that site, and you know who is giving you those files because you do know and trust the site.. So what is the difference? Which other security do you think you get by adding a layer of signed jnlp and jar files on top of that? Do you think that because of that you dont get keyloggers? If you install such a program then with a signed jar or with a https site you know where you can go and complain to. There is not a big difference, its just what you trust. Do you trust the site, do you trust the company that signed the jar?

I figured out the problem why we where getting the security warning about not being able to verify the signature. We are also sending in some <property> values (for example the mac menu bar position) and 1 jvm args property (SoftRefLRUPolicyMSPerMB) which is important for our application (we rely big on soft references in our application)

I dont agree with if you trust https to fill in your credit card information that you dont trust it for running an application. I dont say that the app needs "root" permissions just user permissions to do stuff for that user (read/write files). I am the opposite in this area, the credit card info for me is way more sensitive data then that application... Besides that signing stuff is just to validate it origin, so thats exactly the same for https sites, if we download a webstart application that completely comes from the same server (jnlp files and jars) and that is a https server so the downloaded can verify exactly where it comes from What is then what you loose??

I find this uber sensitive restrition we have now with the latest webstart releases just way to much. 99% of the people on the internet just download application and just install it.. 99% of the people that get that webstart security dialog just dismiss it and say yes i accept, because 99% of those people really have no idea what to do else and what it all means, and they want just to have that app.

For example if we made our application a downloaded application and people could just install it locally there wouldnt be any strange security dialog and people woud just install it as easy. So why is a webstart suddenly so much harder? This will make webstart applications just way harder to use. Because it managers could say no we dont allow those app that say "cant verify signature" which is in our case just not true.. Everything is signed, except the jnlp file that sets 1 vm property that we want for performance.... If we would have a downloadable application that users could install then suddenly in that same environment it wouldnt be any problem! That is just strange.

For our product it is already a burden now that every plugin and extension that 3th party vendors can build must be signed also because else you will get that mixed mode dialog now everytime. So thats not an option. And as i said many of those plugins are free open source plugins, how can they sign it?? years and years before java 6u19 this was not a problem and suddenly it is a bit problem where we just can go around..

I dont mind Information dialogs telling the user that this application is going to be installed or this (jnlp) extension is going to be installed. Thats just fine, i just dont want those "signature cant be verified" warning dialogs.

1 other reason for us that a https check and information dialog would be way better for our product that the dialog they get now is that end users dont know is, because they are not a customer of us, they think they download application X from there supplier, so for them there suplier is the one they want to trust and know. Not us. So that dialog doesnt tell them much at all.

i tested some more, i always through that signing jars also made sure that that code cant be altered with, but this is not really true.

i can just go to the cache dir of javaws and then alter a jar file that is signed by updating an existing class, this class will be run just fine. I cant create new classes but if i can just alter existing classes inside a jar, how can i then know if that is secure. Because signing not only says to the downloader of the application that it is secure, but also for me as the one with the application on the server wants to make sure that the downloader (or another not so nice person) will not tamper or cant tamper with the code he gets from me.

i always thought that signing classes would result in also taking the hash (and size) or something from the class file. Then it could in theory also go wrong if somebody could exactly reproduce the hash and size of the class but that is way more difficult then what he can do now.

i am not sure yet, but it seems 6u18 has broken a lot for us.

We use signing and have a few signed jars for our application. When we upgrade or system not all jars are updates (if the signing certificate stays the same). But the core jars are. Now it seems that i have jar X,Y and Z and in an update X,Y are updated and downloaded again but Z didnt change so webstart leaves it as is.

Now when i access something in Z i get a signing error! But they are signed with the same thing, thats not changed. This always worked before u18

When i clear the cache and let webstart redownload the complete application then it works fine..

anybody else encountered something like this?

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

what mess did MS do with the switch to 64 bit?? Please explain because i haven't noticed any mess and i have used Vista64 bit for some time until the first 64bit beta1 of Windows 7 (now RC waiting for the final). And i never had really problems, except that some specific software that needs device driver stuff had to make 64 bit clients and that toke a while, but thats not MS's problem.

In java having a 64 bit vm there is that problem that you also then NEED 64 bit native code (not so on the os level). And yes eclipse is i guess one of the biggest java applications with native code portions (swt/filesystem and so on). I think if you take eclipse/rcp out of the picture for a moment then only having a 64bit jvm is for most people not really a problem.

I dont care what JavaFX can do more then flash. Communicate with java on the client which flash cant? Why should flash want to do that? It has its own runtime. i find that a very bad example But thats not the point i made. I just say that Sun is so many times playing catch up. Always trying to do something that just WAS hot.. Common there latest thing... Java App Store. What the hack???? Because apple has a store and nokia also creates one (and all the mobile os's do follow) Sun has to make a Java App Store, who does come up with that? its ridicules .. So the information is compiled into java binaries/classes? Huh? But wait it was given a an example that linux couldnt use the packages system of osgi.. But thats just a simple text file inside a jar. But now it is compiled into. something so you really have to know or read binary stuff? By the way, you do know why eclipse does everything in plugin.xml and now in the manifest.mf file right? Because first they had much more in classes. But that didnt scale 1 bit. They had to externalize as much as possible into xml/manifest files so that the plugins classes didnt have to be hit. I am not a big fan of xml (commiter of the wicket web framework because of the xml free stuff and compile time safety of everything) but i guess if you are as big and want to scale out as big as eclipse wants to be you have to. But maybe sun makes this a bit better so that we can have both worlds. But as a said before this isnt something osgi could because they have no control of the java spec. But this by far doesnt mean that sun should just discard osgi.. that would be soo stupid. Work together, there are loads of very experienced guys on both ends and already a working system. Now improve that by introducing changes into the java vm together!

I dont care what JavaFX can do more then flash. Communicate with java on the client which flash cant? Why should flash want to do that? It has its own runtime. i find that a very bad example But thats not the point i made. I just say that Sun is so many times playing catch up. Always trying to do something that just WAS hot.. Common there latest thing... Java App Store. What the hack???? Because apple has a store and nokia also creates one (and all the mobile os's do follow) Sun has to make a Java App Store, who does come up with that? its ridicules .. So the information is compiled into java binaries/classes? Huh? But wait it was given a an example that linux couldnt use the packages system of osgi.. But thats just a simple text file inside a jar. But now it is compiled into. something so you really have to know or read binary stuff? By the way, you do know why eclipse does everything in plugin.xml and now in the manifest.mf file right? Because first they had much more in classes. But that didnt scale 1 bit. They had to externalize as much as possible into xml/manifest files so that the plugins classes didnt have to be hit. I am not a big fan of xml (commiter of the wicket web framework because of the xml free stuff and compile time safety of everything) but i guess if you are as big and want to scale out as big as eclipse wants to be you have to. But maybe sun makes this a bit better so that we can have both worlds. But as a said before this isnt something osgi could because they have no control of the java spec. But this by far doesnt mean that sun should just discard osgi.. that would be soo stupid. Work together, there are loads of very experienced guys on both ends and already a working system. Now improve that by introducing changes into the java vm together!

I dont care what JavaFX can do more then flash. Communicate with java on the client which flash cant? Why should flash want to do that? It has its own runtime. i find that a very bad example But thats not the point i made. I just say that Sun is so many times playing catch up. Always trying to do something that just WAS hot.. Common there latest thing... Java App Store. What the hack???? Because apple has a store and nokia also creates one (and all the mobile os's do follow) Sun has to make a Java App Store, who does come up with that? its ridicules .. So the information is compiled into java binaries/classes? Huh? But wait it was given a an example that linux couldnt use the packages system of osgi.. But thats just a simple text file inside a jar. But now it is compiled into. something so you really have to know or read binary stuff? By the way, you do know why eclipse does everything in plugin.xml and now in the manifest.mf file right? Because first they had much more in classes. But that didnt scale 1 bit. They had to externalize as much as possible into xml/manifest files so that the plugins classes didnt have to be hit. I am not a big fan of xml (commiter of the wicket web framework because of the xml free stuff and compile time safety of everything) but i guess if you are as big and want to scale out as big as eclipse wants to be you have to. But maybe sun makes this a bit better so that we can have both worlds. But as a said before this isnt something osgi could because they have no control of the java spec. But this by far doesnt mean that sun should just discard osgi.. that would be soo stupid. Work together, there are loads of very experienced guys on both ends and already a working system. Now improve that by introducing changes into the java vm together!

I dont care what JavaFX can do more then flash. Communicate with java on the client which flash cant? Why should flash want to do that? It has its own runtime. i find that a very bad example But thats not the point i made. I just say that Sun is so many times playing catch up. Always trying to do something that just WAS hot.. Common there latest thing... Java App Store. What the hack???? Because apple has a store and nokia also creates one (and all the mobile os's do follow) Sun has to make a Java App Store, who does come up with that? its ridicules .. So the information is compiled into java binaries/classes? Huh? But wait it was given a an example that linux couldnt use the packages system of osgi.. But thats just a simple text file inside a jar. But now it is compiled into. something so you really have to know or read binary stuff? By the way, you do know why eclipse does everything in plugin.xml and now in the manifest.mf file right? Because first they had much more in classes. But that didnt scale 1 bit. They had to externalize as much as possible into xml/manifest files so that the plugins classes didnt have to be hit. I am not a big fan of xml (commiter of the wicket web framework because of the xml free stuff and compile time safety of everything) but i guess if you are as big and want to scale out as big as eclipse wants to be you have to. But maybe sun makes this a bit better so that we can have both worlds. But as a said before this isnt something osgi could because they have no control of the java spec. But this by far doesnt mean that sun should just discard osgi.. that would be soo stupid. Work together, there are loads of very experienced guys on both ends and already a working system. Now improve that by introducing changes into the java vm together!

isnt this a bit unfair to say that the Java Module System can be way more reliable and sound then OSGi...

Yeah if i can just alter the jvm itself, i could also do way more cool things.. OSGi had to work with what they have and get..

"Jars/Packages will be more intelligent" where will that be stored? How can a jar that is a container format be more intelligent? Ofcourse it can be wait. just store something in your meta data file...

I dont know if trust Suns/Oracle engineers more the IBM. It will not be the first time that sun does come up with something eventually that is already long there and working perfectly as an open source project (for example logging. Sun should just look at what is now working on the market, and work with those to come up with a perfact combined solution.Do not reinvent the wheel again and again (thats what sun really is in my eyes, the list is so huge, asp -> jsp, ASP.NET -> JSF, Flash -> JavaFX, and this list can go on and on)

isnt this a bit unfair to say that the Java Module System can be way more reliable and sound then OSGi...

Yeah if i can just alter the jvm itself, i could also do way more cool things.. OSGi had to work with what they have and get..

"Jars/Packages will be more intelligent" where will that be stored? How can a jar that is a container format be more intelligent? Ofcourse it can be wait. just store something in your meta data file...

I dont know if trust Suns/Oracle engineers more the IBM. It will not be the first time that sun does come up with something eventually that is already long there and working perfectly as an open source project (for example logging. Sun should just look at what is now working on the market, and work with those to come up with a perfact combined solution.Do not reinvent the wheel again and again (thats what sun really is in my eyes, the list is so huge, asp -> jsp, ASP.NET -> JSF, Flash -> JavaFX, and this list can go on and on)

And the dltk project has more of those contributions

My company uses the javascript part of dltk in our product, we funded the first big cut (and some small things like the js formatter afterwards) and in the meantime i am now committer on it now and do al the more small enhancements and fixes our selfs.

Can anybody explain to me who at sun thought about this "great" idea?

How do they come up with it, why would i go to the java app store?

On a phone its a very good thing to have. (and then i still dont care where it is written in, java or native) But on the desktop? Why would i go as a consumer to the Java App store and buy there a java application.. An average consumer really doesnt care where it is written in.. Doesnt even know that. Or some a bit more techie person doesnt want java apps (because it is so slow... at least thats what they still think)

This really looks agian to something that Sun thought hmm others are also doing that, we should also be doing that.. Why oh why does sun always follow the market and try to copy stuff. And then in this area completely miss the whole point about all those app stores that are currently there. That they are for a very specific target not for desktop stuff...

hmm.. let me think about oracles open source stuff then Do i or did i use, any piece of source, doesnt matter how small, from oracle.. let me think... Nope never have, nothing not 1 piece of open source code from oracle i have ever used. Let me see do i use ibm's? Yes plenty i use it as a tool and i develop on top of it everyday. It is not just the open source that ibm did but also how they did it and how the market it yes. Also as an example for many others. Oracle i just dont trust 1 bit. Its a software company first and maybe if they are really going that path a hardware company thirth. Sun was the other way. Ibm is way more a services company and a hardware company then a pure software company if you ask me. And also because of that i just think that oracle will just see the jvm as a software piece that doesnt make money and will commercialize it. Now that java source is gpl for the most part what does that exactly mean for the java source? I guess they are the only company that just also can release it under another licence? So they can retract it again and just build on top of that again?

hmm.. let me think about oracles open source stuff then Do i or did i use, any piece of source, doesnt matter how small, from oracle.. let me think... Nope never have, nothing not 1 piece of open source code from oracle i have ever used. Let me see do i use ibm's? Yes plenty i use it as a tool and i develop on top of it everyday. It is not just the open source that ibm did but also how they did it and how the market it yes. Also as an example for many others. Oracle i just dont trust 1 bit. Its a software company first and maybe if they are really going that path a hardware company thirth. Sun was the other way. Ibm is way more a services company and a hardware company then a pure software company if you ask me. And also because of that i just think that oracle will just see the jvm as a software piece that doesnt make money and will commercialize it. Now that java source is gpl for the most part what does that exactly mean for the java source? I guess they are the only company that just also can release it under another licence? So they can retract it again and just build on top of that again?

hmm.. let me think about oracles open source stuff then Do i or did i use, any piece of source, doesnt matter how small, from oracle.. let me think... Nope never have, nothing not 1 piece of open source code from oracle i have ever used. Let me see do i use ibm's? Yes plenty i use it as a tool and i develop on top of it everyday. It is not just the open source that ibm did but also how they did it and how the market it yes. Also as an example for many others. Oracle i just dont trust 1 bit. Its a software company first and maybe if they are really going that path a hardware company thirth. Sun was the other way. Ibm is way more a services company and a hardware company then a pure software company if you ask me. And also because of that i just think that oracle will just see the jvm as a software piece that doesnt make money and will commercialize it. Now that java source is gpl for the most part what does that exactly mean for the java source? I guess they are the only company that just also can release it under another licence? So they can retract it again and just build on top of that again?

I agree with this. I dont trust oracle 1 bit. I do trust ibm way more on the java front, but yeah i use IBM projects for a long time (VAJ and eclipse) And what ibm does on the open source source for stuff that i use and contribute to my self (eclipse sub project) And how they build eclipse and there licenses is a big example for the rest, for example Symbian foundation is completely mirrored on how eclipse is set on. Besides that i work a lot with JDBC in our code, our product supports (or tries to) all jdbc databases. But in our code we have a lot of if(oracle) they even dont follow the jdbc spec! (look at how they work with date/datetime). If i look at there jdbc driver and certain stuff they only want to force you to cast to there oracle.ResultsSets and call specific methods to get everything! Maybe they have fixed this now (i hope so) but we have a special sub project that compiles against oracles own stuff to get our project working with oracle databases.. They just try to force you to be oracle all the way No i dont trust oracle 1 bit. I really hope that i am wrong

I agree with this. I dont trust oracle 1 bit. I do trust ibm way more on the java front, but yeah i use IBM projects for a long time (VAJ and eclipse) And what ibm does on the open source source for stuff that i use and contribute to my self (eclipse sub project) And how they build eclipse and there licenses is a big example for the rest, for example Symbian foundation is completely mirrored on how eclipse is set on. Besides that i work a lot with JDBC in our code, our product supports (or tries to) all jdbc databases. But in our code we have a lot of if(oracle) they even dont follow the jdbc spec! (look at how they work with date/datetime). If i look at there jdbc driver and certain stuff they only want to force you to cast to there oracle.ResultsSets and call specific methods to get everything! Maybe they have fixed this now (i hope so) but we have a special sub project that compiles against oracles own stuff to get our project working with oracle databases.. They just try to force you to be oracle all the way No i dont trust oracle 1 bit. I really hope that i am wrong

I agree with this. I dont trust oracle 1 bit. I do trust ibm way more on the java front, but yeah i use IBM projects for a long time (VAJ and eclipse) And what ibm does on the open source source for stuff that i use and contribute to my self (eclipse sub project) And how they build eclipse and there licenses is a big example for the rest, for example Symbian foundation is completely mirrored on how eclipse is set on. Besides that i work a lot with JDBC in our code, our product supports (or tries to) all jdbc databases. But in our code we have a lot of if(oracle) they even dont follow the jdbc spec! (look at how they work with date/datetime). If i look at there jdbc driver and certain stuff they only want to force you to cast to there oracle.ResultsSets and call specific methods to get everything! Maybe they have fixed this now (i hope so) but we have a special sub project that compiles against oracles own stuff to get our project working with oracle databases.. They just try to force you to be oracle all the way No i dont trust oracle 1 bit. I really hope that i am wrong

my feeling? this is the worst possible outcome ibm would be so much better. Java under or besides the eclipse platform would be the perfect solution, Ok both IBM or oralce are JEE minded (which i am not at all, developing swing/swt and web app solutions that are just plain old war files that run on all containters) but somehow i personally trusted ibm way more then oracle with java.

Embedded has one other major drawback because if there is something you shouldnt do in a webapplication is introducing classloaders on top of the webapp classloader.

Ok if you use those purely for loading services and no objects go into the session that are loaded by a osgi classloader then thats ok. But if you do that you do have a problem because session serialization (on the same server or over clusters) do have then a big problem. Because the webappclassloader doesnt know anything about the osgi classloaders so cant deserialize the objects again..

[quote=rickyclarkson]

"Ofcourse if you want backward compartibility dont add the default."

How can you know how your class is being used?

[/quote]

No it is the other side around. We know if somebody uses Wicket 1.4+ we know they are targeting 1.5

So thats not legacy code, and we dont mind that we break then compartibilty. Yes you need to recompile anyway and yes if you then use a class of us that then have a default and you do use it thats not the default then yes you have to fix that. But you have to go over your code anyway because yes we know that we break api that way. But thats not a problem because we are only binairy compartible in the x.x.y release not the x.y.

[quote=rickyclarkson]

"sun pretty much wants us to use generics everywhere or you get loads of warnings."

I think it is pretty poor form to make old code start to give new warnings.

[/quote]

But it does! thats what java 5 does all over the place!

If you get old code now and compile against a java 5 compiler you get Tons of warnings!

[quote=rickyclarkson]

I don't understand your point about 2 constructors. If you don't want the constructor that takes a Bar<T>, delete it.

[/quote]

No thats not possible, I want that object, that object is in the api and that object i want type generify. If you want real life examples just go to wicket.apache.org and look at the api things like this:

TextField textfield = new TextField("person", new Model(person))

textfield.getModelObject() ==> should return person or

textfield.getModel().getObject() --> should return person

so what we want is this:

TextField textfield = new TextField("person", new Model<Person>(person))

but what we must do because of generics:

TextField<Person> textfield = new TextField<Person>("person", new Model<Person>(person))

and thats just horrible.

We also have a component Link but for a link some uses the model so the same constructor as the TextField above. But others never use a model(object) for link so they use this:

Link link = new Link("mylink") { onclick(){stuff without model}

again errors all over the place because link is Generified. now the Default will come in handy because i will make the default map to Void which is what the user also wants here. If the user does want to use a model object then he just needs to type it.

[quote=rickyclarkson]

I think the wicket team's experience is the same one lots of us had years ago. You probably do generics wrong before you do them right. I know I did.

[/quote]

Nope there isnt. There is no right way currently in our code setup that we want to have there just isnt we have had many tryouts. I have generified the wicket code base twice. then redone and again stripped and redone again. Now we removed a lot of generics we had before and we have we less but still users complain because of the warnings and the ugly code.

default keyword and better inference is the only way to fix it. It is currently impossible to do it right.

[quote=rickyclarkson]

"Ofcourse if you want backward compartibility dont add the default."

How can you know how your class is being used?

[/quote]

No it is the other side around. We know if somebody uses Wicket 1.4+ we know they are targeting 1.5

So thats not legacy code, and we dont mind that we break then compartibilty. Yes you need to recompile anyway and yes if you then use a class of us that then have a default and you do use it thats not the default then yes you have to fix that. But you have to go over your code anyway because yes we know that we break api that way. But thats not a problem because we are only binairy compartible in the x.x.y release not the x.y.

[quote=rickyclarkson]

"sun pretty much wants us to use generics everywhere or you get loads of warnings."

I think it is pretty poor form to make old code start to give new warnings.

[/quote]

But it does! thats what java 5 does all over the place!

If you get old code now and compile against a java 5 compiler you get Tons of warnings!

[quote=rickyclarkson]

I don't understand your point about 2 constructors. If you don't want the constructor that takes a Bar<T>, delete it.

[/quote]

No thats not possible, I want that object, that object is in the api and that object i want type generify. If you want real life examples just go to wicket.apache.org and look at the api things like this:

TextField textfield = new TextField("person", new Model(person))

textfield.getModelObject() ==> should return person or

textfield.getModel().getObject() --> should return person

so what we want is this:

TextField textfield = new TextField("person", new Model<Person>(person))

but what we must do because of generics:

TextField<Person> textfield = new TextField<Person>("person", new Model<Person>(person))

and thats just horrible.

We also have a component Link but for a link some uses the model so the same constructor as the TextField above. But others never use a model(object) for link so they use this:

Link link = new Link("mylink") { onclick(){stuff without model}

again errors all over the place because link is Generified. now the Default will come in handy because i will make the default map to Void which is what the user also wants here. If the user does want to use a model object then he just needs to type it.

[quote=rickyclarkson]

I think the wicket team's experience is the same one lots of us had years ago. You probably do generics wrong before you do them right. I know I did.

[/quote]

Nope there isnt. There is no right way currently in our code setup that we want to have there just isnt we have had many tryouts. I have generified the wicket code base twice. then redone and again stripped and redone again. Now we removed a lot of generics we had before and we have we less but still users complain because of the warnings and the ugly code.

default keyword and better inference is the only way to fix it. It is currently impossible to do it right.

[quote=rickyclarkson]

"Ofcourse if you want backward compartibility dont add the default."

How can you know how your class is being used?

[/quote]

No it is the other side around. We know if somebody uses Wicket 1.4+ we know they are targeting 1.5

So thats not legacy code, and we dont mind that we break then compartibilty. Yes you need to recompile anyway and yes if you then use a class of us that then have a default and you do use it thats not the default then yes you have to fix that. But you have to go over your code anyway because yes we know that we break api that way. But thats not a problem because we are only binairy compartible in the x.x.y release not the x.y.

[quote=rickyclarkson]

"sun pretty much wants us to use generics everywhere or you get loads of warnings."

I think it is pretty poor form to make old code start to give new warnings.

[/quote]

But it does! thats what java 5 does all over the place!

If you get old code now and compile against a java 5 compiler you get Tons of warnings!

[quote=rickyclarkson]

I don't understand your point about 2 constructors. If you don't want the constructor that takes a Bar<T>, delete it.

[/quote]

No thats not possible, I want that object, that object is in the api and that object i want type generify. If you want real life examples just go to wicket.apache.org and look at the api things like this:

TextField textfield = new TextField("person", new Model(person))

textfield.getModelObject() ==> should return person or

textfield.getModel().getObject() --> should return person

so what we want is this:

TextField textfield = new TextField("person", new Model<Person>(person))

but what we must do because of generics:

TextField<Person> textfield = new TextField<Person>("person", new Model<Person>(person))

and thats just horrible.

We also have a component Link but for a link some uses the model so the same constructor as the TextField above. But others never use a model(object) for link so they use this:

Link link = new Link("mylink") { onclick(){stuff without model}

again errors all over the place because link is Generified. now the Default will come in handy because i will make the default map to Void which is what the user also wants here. If the user does want to use a model object then he just needs to type it.

[quote=rickyclarkson]

I think the wicket team's experience is the same one lots of us had years ago. You probably do generics wrong before you do them right. I know I did.

[/quote]

Nope there isnt. There is no right way currently in our code setup that we want to have there just isnt we have had many tryouts. I have generified the wicket code base twice. then redone and again stripped and redone again. Now we removed a lot of generics we had before and we have we less but still users complain because of the warnings and the ugly code.

default keyword and better inference is the only way to fix it. It is currently impossible to do it right.

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

i even could live with method pointers that the call works just as reflection

But i agree that is not so nice. For me the whole point is that the reflection part to get the method that is based on a string. I dont want to see strings like that anywhere if possible.

it would for example be nice that the recieving method would just tell me that it has to be a method with this signature so something like

class MyObject

{

public void call(method<String:String,Number> caller)

{

String concat = caller("name", 10);

}

}

where method is a special keyword and between the <> is the expected returntype:parameters

So now i have

class AnotherObject

{

public String myMethod(String name, Number number)

{

return name + number;

}

}

Thats just one usage. Where i want to use it for as i want with the compile time save properties is with property bindings

Look at wicket (web framework) property models

those are really easy to use but all based on strings:

TextField tf = new TextField("name", new PropertyModel(personObject, "name")));

what i want is:

TextField tf = new TextField("name", new PropertyModel(personObject, Person#name)));

and this has to work throughout a complete path ofcourse:

Person#address#country#name

Those are just class properties so a direct replacement of refletion but then without the string.

what also could be made possible is like above with the methods:

TextField tf = new TextField("name", new PropertyModel(personObject#name)));

so directly of an instance the name property (not the value but the property to get the value)

We are currently looking at things like byte code manupulation or using of BeanUtils to do things like that, but it would be very nice to have direct support in java for this.

Besides this what i also would love to see in Java 7 is that generics are not that verbose for example declare it only on one side:

HashMap<Stirng,String> map = new HashMap();

or

HashMap map = new HashMap<Stirng,String>();

both should be valid and just seen as it was declared on once side.

also default generic type keyword when defining generics in the class, this is really a big deal for us developers of the Wicket framework, just google around "wicket generics" and you see soo many discussions about generics that i think could be solved with 1 little addition....

now we have

public class MyClass<T> {}

what i want is this:

public class MyClass<T default Void>{}

So now when you do declare generics:

MyClass object = new MyClass()

it is defaulted to what i have declared in the class definition. So no warning nothing. Just defaults.

That will clean up soo many things for wicket including the only declare on one side.. then generics would be way better to use besides the Collection classes..

My personal view:

i want properties support and method pointers

So that i can get rid of reflection based on strings (no refatoring support)

things like

MyObject myObject = new MyObject()

AnotherObject anotherObject = new AnotherObject();

myObject.call( anotherObjec#method)

and in myObject i can then call that method

method.call(args) (just like reflection)

same for properties.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

[quote=geertjan]

Good point. But does the Wicket team [or someone else] make Wicket components available for AJAX in the way that RichFaces et al do? If I can simply put a JAR on my classpath containing a long list of Wicket AJAX components, such as GMap, and then reuse them as above, that would be very cool. And I wonder what Craig McLanahan would say, if this was true, because then the AJAX components would be accessible in the same way for both Wicket and JSF, except that one would be using them in completely different ways.

PS: I guess all I'm asking for is for as many AJAX-related components as possible to be added to the standard Wicket JARs, i.e., including Google map.

[/quote]

Things like google map dont belong in the core wicket. I am against that. Core is the basic building block for all the basic stuff wicket-extentions are more specialized component

GMap is already a seperate component that is created by the wicket-stuff people where many projects and components are hosted. Thats the whole point that components are made and supported from many places.

Wicket components can be packages in jars and dropped into the classpath of you webapplication and they are ready to go. Without any other (xml) configuration issues. They are just there, ready to use in your prefered IDE.

Such a component can have java/html/css/js files or any other resource files (images) they want. They are completely stand alone an self sufficient.

Hmm this is not a really far example because what do you think the RichFaces component does it is pre packages component???

Exactly the same kind of thing wicket does.

So if i create that code you displayed here for wicket.. And give it to you then the only thing you have to do is:

html:

<div wicket:id="gmap"></div>

java:

add(new MyPredefinedGMapComponent());

done.

I just looked the other day to some JSF faces implementation.. Its really horrible many many things based on strings.. Strings!! why do people want that? Why do people want to program in xml? And then use attributes that have a string value that is a java expression..

I personally never got that, always hated that xml declaration of stuff (for example flow) even back in 2000.. But happily more and more people see the light.. :)

we see it then really different

i prefer this

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>();

above this

var strings = ["one", "two"];

and not by a small margin but by a large large large margin

I hate the way it seems to go, why that completely stupic dynamic langagues are so hot, i have no idea

they can break at any point in any time

If i had to maintain a large 100.00+ LOC project that is all dynamic. i would be horrified.. reading that code would really suck.. Where are the Call Hierarchy where does it start, what calls what, what are the params.

People make mistakes that will also be the case in 10 years..what ever the compiler can catch the better it is.

Ok what java should get is method and field pointers (dont talk about reflection here but instance fields and methods) in the core language.. Because that is one thing i like about about dynamic languages. That you just can give a method pointer to another method.. The api will be a bit verbose but IDE's will solve that.. You dont have to type everything.

[quote=aexodo]like "sort files by name and not by ending" so you can have these together: BasePage.java BasePage.html[/quote]

that would be nice for the wicketeers under us yes :)

[quote=aexodo]like "sort files by name and not by ending" so you can have these together: BasePage.java BasePage.html[/quote]

that would be nice for the wicketeers under us yes :)

[quote=aexodo]like "sort files by name and not by ending" so you can have these together: BasePage.java BasePage.html[/quote]

that would be nice for the wicketeers under us yes :)

[quote=aexodo]like "sort files by name and not by ending" so you can have these together: BasePage.java BasePage.html[/quote]

that would be nice for the wicketeers under us yes :)

Most of you should really use the key combination CTRL-SHIFT-L a few times when you have a perspective/editor open and see what is all possible.

for example editor management: CTRL-F6 (forward CTRL-SHIFT-F6 backwards) or CTRL-E (type beginning of the filename in the editor.)

i dont know directly how to switch to editor 1 or 2 if you are at 5, But that only make sense to the open editors you see i guess so that is what 5 or 8 from the 20+ you can have open? In that case CTRL-E is your friend

Most of you should really use the key combination CTRL-SHIFT-L a few times when you have a perspective/editor open and see what is all possible.

for example editor management: CTRL-F6 (forward CTRL-SHIFT-F6 backwards) or CTRL-E (type beginning of the filename in the editor.)

i dont know directly how to switch to editor 1 or 2 if you are at 5, But that only make sense to the open editors you see i guess so that is what 5 or 8 from the 20+ you can have open? In that case CTRL-E is your friend

Most of you should really use the key combination CTRL-SHIFT-L a few times when you have a perspective/editor open and see what is all possible.

for example editor management: CTRL-F6 (forward CTRL-SHIFT-F6 backwards) or CTRL-E (type beginning of the filename in the editor.)

i dont know directly how to switch to editor 1 or 2 if you are at 5, But that only make sense to the open editors you see i guess so that is what 5 or 8 from the 20+ you can have open? In that case CTRL-E is your friend