How to Create a Swing CRUD Application on NetBeans Platform 6.8
this article shows you how to integrate a java db database into a netbeans platform application. we start by exploring a java db database, from which we create entity classes. next, we wrap the entity classes into a module, together with modules for the related jpa jars. note: these instructions are not applicable to java db only. rather, they are relevant to any relational database, such as oracle or mysql. several applications on the netbeans platform, many of which are listed here , use these databases too. java db was chosen for this article because it is easiest to get started with, since it comes with the jdk. once the above modules are part of our application, we create a new module that provides the user interface for our application. the new module gives the user a tree hierarchy showing data from the database. we then create another module that lets the user edit the data displayed by the first module. by separating the viewer from the editor in distinct modules, we will enable the user to install a different editor for the same viewer, since different editors could be created by external vendors, some commercially and some for free. it is this flexibility that the modular architecture of the netbeans platform makes possible. when we have a module for our editor, we begin adding crud functionality. first, the "r", standing for "read", is handled by the viewer described above. next, the "u" for "update" is handled, followed by the "c" for "create", and the "d" for "delete". at the end of the article, you will have learned about a range of netbeans platform features that help you in creating applications of this kind. for example, you will have learned about the undoredo.manager and the explorermanager , as well as netbeans platform swing components, such as topcomponent and beantreeview . contents setting up the application integrating the database creating entity classes from a database wrapping the entity class jar in a module creating other related modules designing the user interface setting dependencies running the prototype integrating crud functionality read update create delete the application you create in this article will look as follows: source code: http://kenai.com/projects/nbcustomermanager once you're at the stage shown above, you can simply download a netbeans module that provides office laf support ( ), add it to your application, and then when you redeploy the application, you will see this: note: it is advisable to watch the screencast series top 10 netbeans apis before beginning to work on this article. many of the concepts addressed in this article are discussed in more detail within the screencast series. setting up the application let's start by creating a new netbeans platform application. choose file > new project (ctrl+shift+n). under categories, select netbeans modules. under projects, select netbeans platform application. click next. in the name and location panel, type dbmanager in the project name field. click finish. the ide creates the dbmanager project. the project is a container for all the other modules you will create. run the application and notice that you have quite a few features out of the box already. open some of the windows, undock them, and get to know the basic components that the netbeans platform provides without you doing any work whatsoever: integrating the database in order to integrate the database, you need to create entity classes from your database and integrate those entity classes, together with their related jars, into modules that are part of your netbeans platform application. creating the entity classes in this section, you generate entity classes from a selected database. for purposes of this example, use the services window to connect to the sample database that is included with netbeans ide: note: alternatively, use any database you like and adapt the steps that follow to your particular use case. in the case of mysql, see connecting to a mysql database . in the ide, choose file | new project, followed by java | java class library to create a new library project named customerlibrary. in the projects window, right-click the library project and choose file | new file, followed by persistence | entity classes from database. in the wizard, select your database and the tables you need. here we choose "customer", and then "discount code" is added automatically, since there is a relationship between these two tables. specify the persistence strategy, which can be any of the available options. here, since we need to choose something, we'll choose eclipselink: specify "demo" as the name of the package where the entity classes will be generated. click finish. once you have completed this step, look at the generated code and notice that, among other things, you now have a persistence.xml file in a folder called meta-inf, as well as entity classes for each of your tables: build the java library and you will have a jar file in the library project's "dist" folder, which you can view in the files window: wrapping the entity class jar in a module in this section, you add your first module to your application! the new netbeans module will wrap the jar file you created in the previous section. right-click the dbmanager's modules node in the projects window and choose add new library. select the jar you created in the previous subsection and complete the wizard, specifying any values you like. let's assume the application is for dealing with customers at shop.org, in which case a unique identifier "org.shop.model" is appropriate for the code name base: you now have your first custom module in your new application, wrapping the jar containing the entity classes and the persistence.xml file: creating other related modules in this section, you create two new modules, wrapping the eclipselink jars, as well as the database connector jar. do the same as you did when creating the library wrapper for the entity class jar, but this time for the eclipselink jars, which are in the "customerlibrary" java library that you created earlier: note: in the library wrapper module wizard, you can use ctrl-click to select multiple jars. next, create yet another library wrapper module, this time for the java db client jar, which is available in your jdk distribution, at db/lib/derbyclient.jar. designing the user interface in this section, you create a simple prototype user interface, providing a window that uses a jtextarea to display data retrieved from the database. right-click the dbmanager's modules node in the projects window and choose add new. create a new module named customerviewer, with the code name base org.shop.ui. in the projects window, right-click the new module and choose new | window component. specify that it should be created in the editor position and that it should open when the application starts. set customer as the window's class name prefix. use the palette (ctrl-shift-8) to drag and drop a jtextarea on the new window: add this to the end of the topcomponent constructor: entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); query query = entitymanager.createquery("select c from customer c"); list resultlist = query.getresultlist(); for (customer c : resultlist) { jtextarea1.append(c.getname() + " (" + c.getcity() + ")" + "\n"); } note: since you have not set dependencies on the modules that provide the customer object and the persistence jars, the statements above will be marked with red error underlines. these will be fixed in the section that follows. above, you can see references to a persistence unit named "customerlibrarypu", which is the name set in the persistence.xml file. in addition,there is a reference to one of the entity classes, called customer, which is in the entity classes module. adapt these bits to your needs, if they are different to the above. setting dependencies in this section, you enable some of the modules to use code from some of the other modules. you do this very explicitly by setting intentional contracts between related modules, i.e., as opposed to the accidental and chaotic reuse of code that tends to happen when you do not have a strict modular architecture such as that provided by the netbeans platform. the entity classes module needs to have dependencies on the derby client module as well as on the eclipselink module. right-click the customerlibrary module, choose properties, and use the libraries tab to set dependencies on the two modules that the customerlibrary module needs. the customerviewer module needs a dependency on the eclipselink module as well as on the entity classes module. right-click the customerviewer module, choose properties, and use the libraries tab to set dependencies on the two modules that the customerviewer module needs. open the customertopcomponent in the source view, right-click in the editor, and choose "fix imports". the ide is now able to add the required import statements, because the modules that provide the required classes are now available to the customertopcomponent. you now have set contracts between the modules in your application, giving you control over the dependencies between distinct pieces of code. running the prototype in this section, you run the application so that you can see that you're correctly accessing your database. start your database server. run the application. you should see this: you now have a simple prototype, consisting of a netbeans platform application that displays data from your database, which you will extend in the next section. integrating crud functionality in order to create crud functionality that integrates smoothly with the netbeans platform, some very specific netbeans platform coding patterns need to be implemented. the sections that follow describe these patterns in detail. read in this section, you change the jtextarea, introduced in the previous section, for a netbeans platform explorer view. netbeans platform explorer views are swing components that integrate better with the netbeans platform than standard swing components do. among other things, they support the notion of a context, which enables them to be context sensitive. representing your data, you will have a generic hierarchical model provided by a netbeans platform node class, which can be displayed by any of the netbeans platform explorer views. this section ends with an explanation of how to synchronize your explorer view with the netbeans platform properties window. in your topcomponent, delete the jtextarea in the design view and comment out its related code in the source view: entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); query query = entitymanager.createquery("select c from customer c"); list resultlist = query.getresultlist(); //for (customer c : resultlist) { // jtextarea1.append(c.getname() + " (" + c.getcity() + ")" + "\n"); //} right-click the customerviewer module, choose properties, and use the libraries tab to set dependencies on the nodes api and the explorer & property sheet api. next, change the class signature to implement explorermanager.provider: final class customertopcomponent extends topcomponent implements explorermanager.provider you will need to override getexplorermanager() @override public explorermanager getexplorermanager() { return em; } at the top of the class, declare and initialize the explorermanager: private static explorermanager em = new explorermanager(); note: watch top 10 netbeans apis for details on the above code, especially the screencast dealing with the nodes api and the explorer & property sheet api. switch to the topcomponent design view, right-click in the palette, choose palette manager | add from jar. then browse to the org-openide-explorer.jar, which is in platform11/modules folder, within the netbeans ide installation directory. choose the beantreeview and complete the wizard. you should now see beantreeview in the palette. drag it from the palette and drop it on the window. create a factory class that will create a new beannode for each customer in your database: import demo.customer; import java.beans.introspectionexception; import java.util.list; import org.openide.nodes.beannode; import org.openide.nodes.childfactory; import org.openide.nodes.node; import org.openide.util.exceptions; public class customerchildfactory extends childfactory { private list resultlist; public customerchildfactory(list resultlist) { this.resultlist = resultlist; } @override protected boolean createkeys(list list) { for (customer customer : resultlist) { list.add(customer); } return true; } @override protected node createnodeforkey(customer c) { try { return new beannode(c); } catch (introspectionexception ex) { exceptions.printstacktrace(ex); return null; } } } back in the customertopcomponent, use the explorermanager to pass the result list from the jpa query in to the node: entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); query query = entitymanager.createquery("select c from customer c"); list resultlist = query.getresultlist(); em.setrootcontext(new abstractnode(children.create(new customerchildfactory(resultlist), true))); //for (customer c : resultlist) { // jtextarea1.append(c.getname() + " (" + c.getcity() + ")" + "\n"); //} run the application. once the application is running, open the properties window. notice that even though the data is available, displayed in a beantreeview, the beantreeview is not synchronized with the properties window, which is available via window | properties. in other words, nothing is displayed in the properties window when you move up and down the tree hierarchy. synchronize the properties window with the beantreeview by adding the following to the constructor in the topcomponent: associatelookup(explorerutils.createlookup(em, getactionmap())); here we add the topcomponent's actionmap and explorermanager to the lookup of the topcomponent. run the application again and notice that the properties window is now synchronized with the explorer view: now you are able to view your data in a tree hierarchy, as you would be able to do with a jtree. however, you're also able to swap in a different explorer view without needing to change the model at all because the explorermanager mediates between the model and the view. finally, you are now also able to synchronize the view with the properties window. update in this section, you first create an editor. the editor will be provided by a new netbeans module. so, you will first create a new module. then, within that new module, you will create a new topcomponent, containing two jtextfields, for each of the columns you want to let the user edit. you will need to let the viewer module communicate with the editor module. whenever a new node is selected in the viewer module, you will add the current customer object to the lookup. in the editor module, you will listen to the lookup for the introduction of customer objects. whenever a new customer object is introduced into the lookup, you will update the jtextfields in the editor. next, you will synchronize your jtextfields with the netbeans platform's undo, redo, and save functionality. in other words, when the user makes changes to a jtextfield, you want the netbeans platform's existing functionality to become available so that, instead of needing to create new functionality, you'll simply be able to hook into the netbeans platform's support. to this end, you will need to use the undoredomanager, together with the savecookie. create a new module, named customereditor, with org.shop.editor as its code name base. right-click the customereditor module and choose new | window component. make sure to specify that the window should appear in the editor position and that it should open when the application starts. in the final panel of the wizard, set "editor" as the class name prefix. use the palette (ctrl-shift-8) to add two jlabels and two jtextfields to the new window. set the texts of the labels to "name" and "city" and set the variable names of the two jtextfields to jtextfield1 and jtextfield2. in the gui builder, the window should now look something like this: go back to the customerviewer module and change its layer.xml file to specify that the customertopcomponent window will appear in the explorer mode. note: right-click the application project and choose "clean", after changing the layer.xml file. why? because whenever you run the application and close it down, the window positions are stored in the user directory. therefore, if the customerviewer was initially displayed in the editor mode, it will remain in the editor mode, until you do a "clean", thus resetting the user directory (i.e., thus deleting the user directory) and enabling the customerviewer to be displayed in the position currently set in the layer.xml file. also check that the beantreeview in the customerviewer will stretch horizontally and vertically when the user resizes the application. check this by opening the window, selecting the beantreeview, and then clicking the arrow buttons in the toolbar of the gui builder. run the application and make sure that you see the following when the application starts up: now we can start adding some code. firstly, we need to show the currently selected customer object in the editor: start by tweaking the customerviewer module so that the current customer object is added to the viewer window's lookup whenever a new node is selected. do this by creating an abstractnode, instead of a beannode, in the customerchildfactory class. that enables you to add the current customer object to the lookup of the node, as follows (note the "lookups.singleton(c)" below): @override protected node createnodeforkey(customer c) { node node = new abstractnode(children.leaf, lookups.singleton(c)); node.setdisplayname(c.getname()); node.setshortdescription(c.getcity()); return node; // try { // return new beannode(c); // } catch (introspectionexception ex) { // exceptions.printstacktrace(ex); // return null; // } } now, whenever a new node is created, which happens when the user selects a new customer in the viewer, a new customer object is added to the lookup of the node. let's now change the editor module in such a way that its window will end up listening for customer objects being added to the lookup. first, set a dependency in the editor module on the module that provides the entity class, as well as the module that provides the persistence jars. next, change the editortopcomponent class signature to implement lookuplistener: public final class editortopcomponent extends topcomponent implements lookuplistener override the resultchanged so that the jtextfields are updated whenever a new customer object is introduced into the lookup: @override public void resultchanged(lookupevent lookupevent) { lookup.result r = (lookup.result) lookupevent.getsource(); collection coll = r.allinstances(); if (!coll.isempty()) { for (customer cust : coll) { jtextfield1.settext(cust.getname()); jtextfield2.settext(cust.getcity()); } } else { jtextfield1.settext("[no name]"); jtextfield2.settext("[no city]"); } } now that the lookuplistener is defined, we need to add it to something. here, we add it to the lookup.result obtained from the global context. the global context proxies the context of the selected node. for example, if "ford motor co" is selected in the tree hierarchy, the customer object for "ford motor co" is added to the lookup of the node which, because it is the currently selected node, means that the customer object for "ford motor co" is now available in the global context. that is what is then passed to the resultchanged, causing the text fields to be populated. all of the above starts happening, i.e., the lookuplistener becomes active, whenever the editor window is opened, as you can see below: @override public void componentopened() { result = utilities.actionsglobalcontext().lookupresult(customer.class); result.addlookuplistener(this); resultchanged(new lookupevent(result)); } @override public void componentclosed() { result.removelookuplistener(this); result = null; } since the editor window is opened when the application starts, the lookuplistener is available at the time that the application starts up. finally, declare the result variable at the top of the class, like this: private lookup.result result = null; run the application again and notice that the editor window is updated whenever you select a new node: however, notice what happens when you switch the focus to the editor window: because the node is no longer current, the customer object is no longer in the global context. this is the case because, as pointed out above, the global context proxies the lookup of the current node. therefore, in this case, we cannot use the global context. instead, we will use the local lookup provided by the customer window. rewrite this line: result = utilities.actionsglobalcontext().lookupresult(customer.class); to this: result = windowmanager.getdefault().findtopcomponent("customertopcomponent").getlookup().lookupresult(customer.class); the string "customertopcomponent" is the id of the customertopcomponent, which is a string constant that you can find in the source code of the customertopcomponent. one drawback of the approach above is that now our editortopcomponent only works if it can find a topcomponent with the id "customertopcomponent". either this needs to be explicitly documented, so that developers of alternative editors can know that they need to identify the viewer topcomponent this way, or you need to rewrite the selection model, as described here by tim boudreau. if you take one of the above approaches, you will find that the context is not lost when you switch the focus to the editortopcomponent, as shown below: note: since you are now using abstractnode, instead of beannode, no properties are shown in the properties window. you need to provide these yourself, as described in the nodes api tutorial . secondly, let's work on the undo/redo functionality. what we'd like to have happen is that whenever the user makes a change to one of the jtextfields, the "undo" button and the "redo" button, as well as the related menu items in the edit menu, become enabled. to that end, the netbeans platform makes the undoredo.manager available. declare and instantiate a new undoredomanager at the top of the editortopcomponent: private undoredo.manager manager = new undoredo.manager(); next, override the getundoredo() method in the editortopcomponent: @override public undoredo getundoredo() { return manager; } in the constructor of the editortopcomponent, add a keylistener to the jtextfields and, within the related methods that you need to implement, add the undoredolisteners: jtextfield1.getdocument().addundoableeditlistener(manager); jtextfield2.getdocument().addundoableeditlistener(manager); run the application and show the undo and redo functionality in action, the buttons as well as the menu items. the functionality works exactly as you would expect. you might want to change the keylistener so that not all keys cause the undo/redo functionality to be enabled. for example, when enter is pressed, you probably do not want the undo/redo functionality to become available. therefore, tweak the code above to suit your business requirements. thirdly, we need to integrate with the netbeans platform's save functionality: by default, the "save all" button is available in the netbeans platform toolbar. in our current scenario, we do not want to save "all", because "all" refers to a number of different documents. in our case, we only have one "document", which is the editor that we are reusing for all the nodes in the tree hirerarchy. remove the "save all" button and add the "save" button instead, by adding the following to the layer file of the customereditor module: when you now run the application, you will see a different icon in the toolbar. instead of the "save all" button, you now have the "save" button available. set dependencies on the dialogs api and the nodes api. in the editortopcompontn constructor, add a call to fire a method (which will be defined in the next step) whenever a change is detected: public editortopcomponent() { ... ... ... jtextfield1.getdocument().adddocumentlistener(new documentlistener() { public void insertupdate(documentevent arg0) { fire(true); } public void removeupdate(documentevent arg0) { fire(true); } public void changedupdate(documentevent arg0) { fire(true); } }); jtextfield2.getdocument().adddocumentlistener(new documentlistener() { public void insertupdate(documentevent arg0) { fire(true); } public void removeupdate(documentevent arg0) { fire(true); } public void changedupdate(documentevent arg0) { fire(true); } }); //create a new instance of our savecookie implementation: impl = new savecookieimpl(); //create a new instance of our dynamic object: content = new instancecontent(); //add the dynamic object to the topcomponent lookup: associatelookup(new abstractlookup(content)); } ... ... ... here are the two methods referred to above. first, the method that is fired whenever a change is detected. an implementation of the savecookie from the nodes api is added to the instancecontent whenever a change is detected: public void fire(boolean modified) { if (modified) { //if the text is modified, //we add savecookie impl to lookup: content.add(impl); } else { //otherwise, we remove the savecookie impl from the lookup: content.remove(impl); } } private class savecookieimpl implements savecookie { @override public void save() throws ioexception { confirmation message = new notifydescriptor.confirmation("do you want to save \"" + jtextfield1.gettext() + " (" + jtextfield2.gettext() + ")\"?", notifydescriptor.ok_cancel_option, notifydescriptor.question_message); object result = dialogdisplayer.getdefault().notify(message); //when user clicks "yes", indicating they really want to save, //we need to disable the save action, //so that it will only be usable when the next change is made //to the jtextarea: if (notifydescriptor.yes_option.equals(result)) { fire(false); //implement your save functionality here. } } } run the application and notice the enablement/disablement of the save button: note: right now, nothing happens when you click ok in the dialog above. in the next step, we add some jpa code for handling persistence of our changes. next, we add jpa code for persisting our change. do so by replacing the comment "//implement your save functionality here." the comment should be replaced by all of the following: entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); entitymanager.gettransaction().begin(); customer c = entitymanager.find(customer.class, customer.getcustomerid()); c.setname(jtextfield1.gettext()); c.setcity(jtextfield2.gettext()); entitymanager.gettransaction().commit(); note: the "customer" in customer.getcustomerid() is currently undefined. add the line "customer = cust;" in the resultchanged (as shown below), after declaring customer customer; at the top of the class, so that the current customer object sets the customer, which is then used in the persistence code above to obtain the id of the current customer object. @override public void resultchanged(lookupevent lookupevent) { lookup.result r = (lookup.result) lookupevent.getsource(); collection c = r.allinstances(); if (!c.isempty()) { for (customer customer : c) { customer = cust; jtextfield1.settext(customer.getname()); jtextfield2.settext(customer.getcity()); } } else { jtextfield1.settext("[no name]"); jtextfield2.settext("[no city]"); } } run the application and change some data. currently, we have no "refresh" functionality (that will be added in the next step) so, to see the changed data, restart the application. here, for example, the tree hierarchy shows the persisted customer name for "toyota motor co": fourthly, we need to add functionality for refreshing the customer viewer. you might want to add a timer which periodically refreshes the viewer. however, in this example, we will add a "refresh" menu item to the root node so that the user will be able to manually refresh the viewer. in the main package of the customerviewer module, create a new node, which will replace the abstractnode that we are currently using as the root of the children in the viewer. note that we also bind a "refresh" action to our new root node. public class customerrootnode extends abstractnode { public customerrootnode(children kids) { super(kids); setdisplayname("root"); } @override public action[] getactions(boolean context) { action[] result = new action[]{ new refreshaction()}; return result; } private final class refreshaction extends abstractaction { public refreshaction() { putvalue(action.name, "refresh"); } public void actionperformed(actionevent e) { customertopcomponent.refreshnode(); } } } add this method to the customertopcomponent, for refreshing the view: public static void refreshnode() { entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); query query = entitymanager.createquery("select c from customer c"); list resultlist = query.getresultlist(); em.setrootcontext(new customerrootnode(children.create(new customerchildfactory(resultlist), true))); } now replace the code above in the constructor of the customertopcomponent with a call to the above. as you can see, we are now using our customerrootnode instead of the abstractnode. the customerrootnode includes the "refresh" action, which calls the code above. in your save functionality, add the call to the method above so that, whenever data is saved, an automatic refresh takes place. you can take different approaches when implementing this extension to the save functionality. for example, you might want to create a new module that contains the refresh action. that module would then be shared between the viewer module and the editor module, providing functionality that is common to both. run the application again and notice that you have a new root node, with a "refresh" action: make a change to some data, save it, invoke the refresh action, and notice that the viewer is updated. you have now learned how to let the netbeans platform handle changes to the jtextfields. whenever the text changes, the netbeans platform undo and redo buttons are enabled or disabled. also, the save button is enabled and disabled correctly, letting the user save changed data back to the database. create in this section, you allow the user to create a new entry in the database. right-click the customereditor module and choose "new action". use the new action wizard to create a new "always enabled" action. the new action should be displayed anywhere in the toolbar and/or anywhere in the menu bar. in the next step of the wizard, call the action newaction. note: make sure that you have a 16x16 icon available, which the wizard forces you to select if you indicate that you want the action to be invoked from the toolbar. in the new action, let the topcomponent be opened, together with emptied jtextfields: import java.awt.event.actionevent; import java.awt.event.actionlistener; public final class newaction implements actionlistener { public void actionperformed(actionevent e) { editortopcomponent tc = editortopcomponent.getdefault(); tc.resetfields(); tc.open(); tc.requestactive(); } } note: the action implements the actionlistener class, which is bound to the application via entries in the layer file, put there by the new action wizard. imagine how easy it will be when you port your existing swing application to the netbeans platform, since you'll simply be able to use the same action classes that you used in your original application, without needing to rewrite them to conform to action classes provided by the netbeans platform! in the editortopcomponent, add the following method for resetting the jtextfields and creating a new customer object: public void resetfields() { customer = new customer(); jtextfield1.settext(""); jtextfield2.settext(""); } in the savecookie, ensure that a return of null indicates that a new entry is saved, instead of an existing entry being updated: public void save() throws ioexception { confirmation message = new notifydescriptor.confirmation("do you want to save \"" + jtextfield1.gettext() + " (" + jtextfield2.gettext() + ")\"?", notifydescriptor.ok_cancel_option, notifydescriptor.question_message); object result = dialogdisplayer.getdefault().notify(msg); //when user clicks "yes", indicating they really want to save, //we need to disable the save button and save menu item, //so that it will only be usable when the next change is made //to the text field: if (notifydescriptor.yes_option.equals(result)) { fire(false); entitymanager entitymanager = persistence.createentitymanagerfactory("customerlibrarypu").createentitymanager(); entitymanager.gettransaction().begin(); if (customer.getcustomerid() != null) { customer c = entitymanager.find(customer.class, cude.getcustomerid()); c.setname(jtextfield1.gettext()); c.setcity(jtextfield2.gettext()); entitymanager.gettransaction().commit(); } else { query query = entitymanager.createquery("select c from customer c"); list resultlist = query.getresultlist(); customer.setcustomerid(resultlist.size()+1); customer.setname(jtextfield1.gettext()); customer.setcity(jtextfield2.gettext()); //add more fields that will populate all the other columns in the table! entitymanager.persist(customer); entitymanager.gettransaction().commit(); } } } run the application again and add a new customer to the database. delete in this section, let the user delete a selected entry in the database. using the concepts and code outlined above, implement the delete action yourself. create a new action, deleteaction. decide whether you want to bind it to a customer node or whether you'd rather bind it to the toolbar, the menu bar, keyboard shortcut, or combinations of these. depending on where you want to bind it, you will need to use a different approach in your code. read the article again for help, especially by looking at how the "new" action was created, while comparing it to the "refresh" action on the root node. get the current customer object, return an 'are you sure?' dialog, and then delete the entry. for help on this point, read the article again, focusing on the part where the "save" functionality is implemented. instead of saving, you now want to delete an entry from the database. see also this concludes the article. you have learned how to create a new netbeans platform application with crud functionality for a given database. you have also seen many of the netbeans apis in action. for more information about creating and developing applications on the netbeans platform, see the following resources: netbeans platform learning trail netbeans api javadoc
December 8, 2009
·
230,896 Views
·
0 Likes
Comments
May 04, 2015 · Sylwia Kedzia
Dec 27, 2014 · Priyanka Sharma
Many more tutorials on NetBeans plugins here:
https://netbeans.org/features/platform/all-docs.html
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
There's not been a single user of Maven in NetBeans IDE who has ever said: "I wish NetBeans would create artifacts in my source structure to enable it to recognize my source structure as a Maven project."
Jan 31, 2014 · lynk Ho
Oh, I see, sorry. I thought that when you said this that it referred to everything in the article -- but now I see it referred to the Maven point only -- " Otherwise, everything you listed is available in other IDEs as well.. and works seamlessly."
Jan 31, 2014 · lynk Ho
Oh, I see, sorry. I thought that when you said this that it referred to everything in the article -- but now I see it referred to the Maven point only -- " Otherwise, everything you listed is available in other IDEs as well.. and works seamlessly."
Jan 31, 2014 · lynk Ho
Oh, I see, sorry. I thought that when you said this that it referred to everything in the article -- but now I see it referred to the Maven point only -- " Otherwise, everything you listed is available in other IDEs as well.. and works seamlessly."
Jan 31, 2014 · lynk Ho
Oh, I see, sorry. I thought that when you said this that it referred to everything in the article -- but now I see it referred to the Maven point only -- " Otherwise, everything you listed is available in other IDEs as well.. and works seamlessly."
Jan 31, 2014 · lynk Ho
Oh, I see, sorry. I thought that when you said this that it referred to everything in the article -- but now I see it referred to the Maven point only -- " Otherwise, everything you listed is available in other IDEs as well.. and works seamlessly."
Jan 31, 2014 · lynk Ho
And are you saying that you're able to create, out of the box, without any plugins, a PrimeFaces application in the other IDEs too? Aside from that, note that David didn't say that these features don't exist in other IDEs. He simply said what he appreciates about NetBeans.
Jan 31, 2014 · lynk Ho
One aspect of the NetBeans Maven support that is awesome and unique is that NetBeans doesn't throw NetBeans files into your Maven project structure just to make it a NetBeans project. Nothing is added at all. The Maven project you open into NetBeans is the same project that you close, no extra stuff that you don't really need, no stuff to worry about whether to check into versioning or not, no fuss. The POM is the entire project structure and NetBeans is smart enough to need to only work with that file.
By the way Matti from Vaadin says the following (here) very recently on Eclipse/NetBeans in relation to Maven: "From what I have learned, NetBeans excels at least in Maven support and JPA features."
Jan 29, 2014 · Mr B Loid
Try this instead: http://plugins.netbeans.org/plugin/52559/nbscala-1-6-2-1
Oct 30, 2013 · Tony Thomas
Here's my favorite new NetBeans IDE 7.4 feature... Chrome Developer Tools integration with NetBeans! It's really cool and demonstrated here: https://www.youtube.com/watch?v=O85AV406SXI
May 20, 2013 · Geertjan Wielenga
Great article, many thanks for writing it, indeed in the context of maps and globes, this is a great solution.
May 07, 2013 · Tony Thomas
Many thanks! I am now also using this solution in the menu bar.
Feb 15, 2012 · Mr B Loid
Feb 08, 2012 · Tony Thomas
Feb 08, 2012 · Tony Thomas
Feb 08, 2012 · Tony Thomas
Feb 07, 2012 · Tony Thomas
Jan 25, 2012 · nitin pai
Jan 07, 2012 · Tony Thomas
Jan 07, 2012 · Toni Epple
Dec 07, 2011 · peter svensson
Very cool. And here's another Amazon-related project on the NetBeans Platform:
http://netbeans.dzone.com/nb-amazon-web-services-manager
Dec 02, 2011 · Tony Thomas
I imagine Sean's team is doing it differently, but here's one approach described via OfficeBean:
http://platform.netbeans.org/articles/nbm_interview_chuk.html
Nov 28, 2011 · Cesar Rodas
Oct 01, 2011 · Mr B Loid
Sep 27, 2011 · Manuel Jordan
Jul 19, 2011 · Tony Thomas
Jul 19, 2011 · Tony Thomas
Jul 19, 2011 · Tony Thomas
Jun 03, 2011 · Tony Thomas
If sped up development cycle is what you're after, there's nothing better than NetBeans IDE together with Javeleon:
http://www.youtube.com/watch?v=sMz8tRP7JV4
Apr 29, 2011 · Mr B Loid
A better ReloadAction would be like this:
And, in the RootNode:
Apr 12, 2011 · Lebon Bon Lebon
Apr 12, 2011 · Lebon Bon Lebon
Here are 198 pieces of evidence to prove the relevance of the Java desktop.
http://platform.netbeans.org/screenshots.html
I spend pretty much all my time showing developers all over the world about all this. And in the enterprise, the Java desktop is massive. And growing. The web is insecure and unreliable. Not good for the enterprise, e.g., banks, and in the aerospace/military industry "insecure and unreliable" are not strong selling points either.
Feb 15, 2011 · Brian Reindel
That's a really beautiful app, thanks for sharing this info.
Next, your need for project groupings, i.e., different levels of projects that relate to each other, can be handled via the org.netbeans.spi.project.SubprojectProvider class. You first need to create a main project and make it pluggable, as described here. Then read this to use the SubprojectProvider class. It's interesting, but there's a reservoir-related organization that I know of that's using exactly the same functionality to create project groupings in their NetBeans Platform application.
Jan 15, 2011 · Mr B Loid
Dec 08, 2010 · Anis Ahmad
Yeah, there's not much space... except in defense... and in banking... and in oil... and in bioinfomatics... and in healthcare... and in retail... and in... Oh, why not look at the evidence yourself.
Dec 08, 2010 · Anis Ahmad
Yeah, there's not much space... except in defense... and in banking... and in oil... and in bioinfomatics... and in healthcare... and in retail... and in... Oh, why not look at the evidence yourself.
Dec 08, 2010 · Anis Ahmad
Yeah, there's not much space... except in defense... and in banking... and in oil... and in bioinfomatics... and in healthcare... and in retail... and in... Oh, why not look at the evidence yourself.
Nov 27, 2010 · [deleted]
Nov 23, 2010 · Tinu Awopetu
Nov 23, 2010 · Deepak Kumar
Nov 23, 2010 · Deepak Kumar
Nov 23, 2010 · Deepak Kumar
Nov 23, 2010 · Geertjan Wielenga
Nov 23, 2010 · Geertjan Wielenga
Nov 23, 2010 · Geertjan Wielenga
Oct 27, 2010 · Stacy Doss
Sep 11, 2010 · Alex J. Ma
symbol : variable WindowManager
location: class org.sqleditor.branding.Installer
WindowManager.getDefault().inkoveWhenUIReady(
3 errors
From the above, you can see that you need "WindowManager" class. That's part of the Window System API. Add that module as a dependency to your module: go to the Project Properties dialog of the module and add "Window System API" as one of the APIs that the module depends on. Apologies, I should have specified that in the instructions above!
Sep 11, 2010 · Geertjan Wielenga
symbol : variable WindowManager
location: class org.sqleditor.branding.Installer
WindowManager.getDefault().inkoveWhenUIReady(
3 errors
From the above, you can see that you need "WindowManager" class. That's part of the Window System API. Add that module as a dependency to your module: go to the Project Properties dialog of the module and add "Window System API" as one of the APIs that the module depends on. Apologies, I should have specified that in the instructions above!
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Alex J. Ma
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 07, 2010 · Geertjan Wielenga
Sep 03, 2010 · Mr B Loid
Sep 03, 2010 · Mr B Loid
Aug 14, 2010 · Krishna Srinivasan
Aug 14, 2010 · Krishna Srinivasan
Aug 14, 2010 · Krishna Srinivasan
Aug 11, 2010 · Mr B Loid
Aug 11, 2010 · Mr B Loid
Aug 11, 2010 · Mr B Loid
Jul 28, 2010 · Mr B Loid
Jul 28, 2010 · Mr B Loid
Jul 28, 2010 · Mr B Loid
Lots of organizations (military, banking, etc, etc, etc) have created very large scalable pluggable rich-client applications, without ever having needed to touch OSGi, since they use the NetBeans module system which provides very similar features (read the text above, where the author suggests it is even preferable to OSGi in some ways). But, now, if someone does find OSGi to be indispensable, they can use it too, in the NetBeans Platform, without every touching Eclipse RCP or Eclipse IDE. Not saying that that is the ideal solution for everyone (especially if you're using SWT), but to argue that OSGi is indispensable in rich-client applications is clearly false.
Jul 28, 2010 · Mr B Loid
Lots of organizations (military, banking, etc, etc, etc) have created very large scalable pluggable rich-client applications, without ever having needed to touch OSGi, since they use the NetBeans module system which provides very similar features (read the text above, where the author suggests it is even preferable to OSGi in some ways). But, now, if someone does find OSGi to be indispensable, they can use it too, in the NetBeans Platform, without every touching Eclipse RCP or Eclipse IDE. Not saying that that is the ideal solution for everyone (especially if you're using SWT), but to argue that OSGi is indispensable in rich-client applications is clearly false.
Jul 28, 2010 · Mr B Loid
Lots of organizations (military, banking, etc, etc, etc) have created very large scalable pluggable rich-client applications, without ever having needed to touch OSGi, since they use the NetBeans module system which provides very similar features (read the text above, where the author suggests it is even preferable to OSGi in some ways). But, now, if someone does find OSGi to be indispensable, they can use it too, in the NetBeans Platform, without every touching Eclipse RCP or Eclipse IDE. Not saying that that is the ideal solution for everyone (especially if you're using SWT), but to argue that OSGi is indispensable in rich-client applications is clearly false.
Jul 28, 2010 · Mr B Loid
Lots of organizations (military, banking, etc, etc, etc) have created very large scalable pluggable rich-client applications, without ever having needed to touch OSGi, since they use the NetBeans module system which provides very similar features (read the text above, where the author suggests it is even preferable to OSGi in some ways). But, now, if someone does find OSGi to be indispensable, they can use it too, in the NetBeans Platform, without every touching Eclipse RCP or Eclipse IDE. Not saying that that is the ideal solution for everyone (especially if you're using SWT), but to argue that OSGi is indispensable in rich-client applications is clearly false.
Jul 27, 2010 · Mr B Loid
Jul 27, 2010 · Mr B Loid
Jul 23, 2010 · Mr B Loid
No need to wait, Jaideep. Oracle has already made a strong statement of commitment to the NetBeans Platform. Ted Farrell, Chief Architect and Senior Vice President of Oracle: "The NetBeans Platform is very important to a lot of our customers, who are actually building their products on top of the NetBeans Platform. We want to make that the best platform that we can for doing that for you." That's a direct quote from one of the video statements made right after Sun's takeover by Oracle was announced.
And to your question, "Now how does a developer reconcile between two module systems in NetBeans?" The answer is: choose whichever one you like. For your build system, choose Ant or choose Maven, up to you. For module system, choose OSGi or NetBeans module system, your choice. You can even combine OSGi with NetBeans Platform, as the NetBeans Platform EMF integration Tutorial shows.
Finally, your point "the documentation point is debatable; especially because Edvin is ignoring the depth of the platform". Well, you'll find that the NetBeans Platform is pretty deep too. :-)
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 15, 2010 · Steven Sacks
Jul 07, 2010 · Mr B Loid
Jul 07, 2010 · Mr B Loid
Jul 07, 2010 · Mr B Loid
Jul 07, 2010 · Mr B Loid
Jun 06, 2010 · Mr B Loid
Jun 06, 2010 · Mr B Loid
Jun 06, 2010 · Mr B Loid
Jun 06, 2010 · Mr B Loid
Apr 20, 2010 · Poorna Chander Kola
It will be done automatically, Guido, via a wizard. Read here for more info:
http://netbeans.dzone.com/nb-osgi-web-development
Apr 16, 2010 · Mr B Loid
Apr 07, 2010 · Mr B Loid
Apr 01, 2010 · Indroneel Das
Apr 01, 2010 · Geertjan Wielenga
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 30, 2010 · Lebon Bon Lebon
Mar 28, 2010 · Lebon Bon Lebon
Mar 27, 2010 · Mr B Loid
Mar 27, 2010 · Geertjan Wielenga
Mar 25, 2010 · Mr B Loid
Great question.
If you select "User May Select Multiple Nodes" in the first panel of the New Action wizard, the EXACTLY_ONE in the layer is ANY instead, with this being generated as the ActionListener:
Don't know about ALL and SOME though. Will find out (or in the meantime you can read the NetBeans API javadoc for details)!
Mar 24, 2010 · Mr B Loid
Mar 20, 2010 · Gerd Storm
Mar 20, 2010 · Gerd Storm
Mar 20, 2010 · Gerd Storm
Mar 20, 2010 · Gerd Storm
Mar 01, 2010 · Krishna Srinivasan
Feb 19, 2010 · Geertjan Wielenga
Feb 19, 2010 · Geertjan Wielenga
Feb 18, 2010 · Geertjan Wielenga
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 17, 2010 · Mr B Loid
Well, that depends on whether you consider military, banking, and oil applications to be doing heavy duty work or not. Because that's where Java GUIs are being used all the time. Go on, ask me for some examples, I dare you. :-)
Feb 15, 2010 · Mr B Loid
Here's the tutorial on ProjectFactory and Project:
http://platform.netbeans.org/tutorials/nbm-projecttype.html
Dec 30, 2009 · Gerd Storm
Download link works fine for me:
http://netbeans.dzone.com/sites/all/files/CustomerApp_PrimeFaces.zip
Dec 30, 2009 · Christopher Lam
Download link works fine for me:
http://netbeans.dzone.com/sites/all/files/CustomerApp_PrimeFaces.zip
Dec 14, 2009 · Geertjan Wielenga
Hi surajchchetry, that's a great idea. If I understand it correctly. This is the kind of project structure I am creating at the moment, for a new tutorial, based on your suggestion above.
A new tutorial should appear within the next week or two, to explain how to create project structures like the above, with a bunch of additional features too, as described here in my blog!
Dec 14, 2009 · Geertjan Wielenga
Dec 13, 2009 · Geertjan Wielenga
Dec 09, 2009 · Geertjan Wielenga
Excellent feedback, ringerc. That will be fixed. Thank you. One approach is to register actions in the layer file which then enables you to add an attribute to the layer entry. That attribute causes the action to be processed asynchronously, (which is a new feature in 6.8, i.e., the ability to mark an action as being asynchronous). These asynchronous actions can simulate SwingWorker:
class MyAction implements ActionListener, Runnable {
public MyAction(MyContext c) {
assert EventQueue.isEventThread();
// setup inside AWT thread, get what is important from c
}
public void actionPerformed(AE ev) {
assert !EventQueue.isEventThread();
// run off AWT thread
// perform the work
SwingUtilities.invokeLater(this);
}
public void run() {
assert EventQueue.isEventThread();
// finish in AWT and update the UI
}
}
Another approach would be to use SwingWorker. These approaches will be added to the article, though note that threading on the NetBeans Platform is also discussed here: http://wiki.netbeans.org/NetBeansDeveloperFAQ#Threading
Something else that's possible is to integrate with the NetBeans progress bar, which can be achieved with, literally, 3 lines of code.
Dec 02, 2009 · Geertjan Wielenga
Great feedback. Maybe a refcard on modulerization should be created. The basic principles listed above are great starting points. It's also cool to see that various module systems have the same basic rationales underpinning them.
Also, based on the above various comments, could one perhaps say: "when in doubt about whether or not to create another module, go ahead and do so"? I.e., the fact that you're thinking about it is probably a reason to go ahead and follow that impulse, since it is probably appropriate in your context.
Nov 17, 2009 · Geertjan Wielenga
Nov 17, 2009 · Mr B Loid
Nov 16, 2009 · Mr B Loid
Oct 30, 2009 · Mr B Loid
Well, the NetBeans plugin was created 2 days ago...
Oct 30, 2009 · Mr B Loid
Well, the NetBeans plugin was created 2 days ago...
Oct 30, 2009 · Mr B Loid
Well, the NetBeans plugin was created 2 days ago...
Oct 29, 2009 · Mr B Loid
Oct 29, 2009 · Mr B Loid
Oct 29, 2009 · Mr B Loid
Oct 29, 2009 · Mr B Loid
Oct 27, 2009 · Mr B Loid
Oct 27, 2009 · Mr B Loid
Oct 22, 2009 · Dave Booth
Oct 18, 2009 · Mr B Loid
For the record, here's my response to the "JDeveloper _is_ a platform" nonsense:
http://blogs.sun.com/geertjan/entry/is_oracle_s_jdeveloper_a
Oct 08, 2009 · Denis Gobo
Aug 05, 2009 · Geertjan Wielenga
Aug 05, 2009 · Geertjan Wielenga
Aug 01, 2009 · Stacy Doss
Episode 49 was released about 2 or 3 months ago, not December 2008...
Anyway, we're working on getting Episode 50 on iTunes and so on. But, like every episode, it takes some time to publish it in all the various places where it needs to be.
Jul 10, 2009 · Levent Gurses
Jul 10, 2009 · Levent Gurses
Jul 10, 2009 · Levent Gurses
Jun 26, 2009 · Mr B Loid
Jun 08, 2009 · Mr B Loid
So all you want on Javalobby are articles that are uncritical of Java? What qualifies this article for inclusion on Javalobby is the fact that it is about Java. The fact that it turns out that it doesn't FAVOR Java is completely and utterly irrelevant.
Jun 08, 2009 · Mr B Loid
Jun 08, 2009 · Mr B Loid
May 31, 2009 · Brian Reindel
May 27, 2009 · Gill Cleeren
Maybe they were choosing between Flex and SWT?
May 16, 2009 · Mr B Loid
May 16, 2009 · Mr B Loid
May 16, 2009 · Mr B Loid
May 16, 2009 · Mr B Loid
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 15, 2009 · Lebon Bon Lebon
May 14, 2009 · Mr B Loid
I don't think that will ever be the case. It would mean that all NetBeans Platform modules would need to be OSGi bundles, making NetBeans Platform modules unusable for anyone who prefers the NetBeans module system. Wouldn't be very nice in terms of backward compatibility. This hybrid option, i.e., supporting both, giving developers the choice to choose either one, is great and -- at least in my opinion -- even preferable (and as Tom points out above, the whole question of the importance of this question is relative: "I've always felt the module format is little more than an implementation detail, because in the course of developing a platform application, I spend very little time on code which has anything at all to do with the module system. Instead I spend most of my time working on application's business logic and user interface, so the ability to use Swing is much more important to me.")
In other words, the question of using the standard UI toolkit (i.e., Swing) is typically of far greater significance to developers than whether they can use only OSGi or not.
May 13, 2009 · Mr B Loid
Thanks for the questions, Neil. Answers here: http://wiki.netbeans.org/OSGiAndNetBeans. Hopefully Jaroslav Tulach or others will stop by here to fill in other details to questions you've posed.
May 13, 2009 · Mr B Loid
That's a slightly odd paragraph since its content is equally applicable to the NetBeans Platform.
May 13, 2009 · Mr B Loid
That's a slightly odd paragraph since its content is equally applicable to the NetBeans Platform.
May 13, 2009 · Mr B Loid
That's a slightly odd paragraph since its content is equally applicable to the NetBeans Platform.
May 13, 2009 · Mr B Loid
Mar 23, 2009 · Schalk Neethling
Mar 18, 2009 · Vera Tushurashvili
Mar 05, 2009 · Mr B Loid
Mar 05, 2009 · Geertjan Wielenga
Mar 05, 2009 · Geertjan Wielenga
Feb 26, 2009 · Boris Derzhavets
Feb 23, 2009 · Mr B Loid
I've said this before and I'll say it again (and again and again): if you need a framework anyway, why not choose one that has scaleability built into it? Isn't that the point of a framework, i.e., your application is getting slightly larger than "small" and so you want to have some typical concerns handled for you. But, if your application is getting slightly larger than "small", doesn't it follow that it's quite likely that it'll become slightly larger than "medium" too? Then, why aren't you going for a modular framework to begin with?
The only exception I can see to the above principle in the desktop Java world is Griffon: though it isn't modular, it uses Groovy, which is a fair trade off. :-)
Feb 17, 2009 · Mr B Loid
What about Groovy's Ant support? Very cool. You should look at it:
http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-groovy.html
Feb 15, 2009 · Mr B Loid
Feb 14, 2009 · Mr B Loid
Feb 14, 2009 · Geertjan Wielenga
Feb 10, 2009 · Justas Vinevi?ius
Good point. The Java tutorials are there. The Javadoc is there. Why not connect them?
In NetBeans we're trying to do exactly that.
Jan 30, 2009 · Vladimir Carrer
Jan 30, 2009 · Mr B Loid
Jan 30, 2009 · Mr B Loid
Jan 21, 2009 · Mr B Loid
Jan 20, 2009 · Frank Kelly
http://weblogs.java.net/blog/fabriziogiudici/archive/2008/01/beansbinding_no.html
Also, from the next step in this series onwards, I will not be using Beans Binding at all anymore (its future seems fragile, so I'd rather not rely so heavily on it in this series that will hopefully be useful to someone in real life), so questions relating to Beans Binding should not be relevant anymore.
On the JPA side, which will of course continue to be a fundamental part of this application, I will be monitoring the situation, and evaluating the application as it develops, so that any EDT issues, threading issues, and the like, will be identified and openly discussed in this series. For the moment, I won't be discussing these aspects, but will do so one or two topics from now.
Finally, yes, all the code will be made available, from about two topics onwards. Hope that is sufficient response for the moment.
Jan 18, 2009 · Geertjan Wielenga
Jan 17, 2009 · Mr B Loid
I only find a drawback: Whenever I need to make changes to entity library (which is a regular NB IDE Java Library Project), I am then also required to manually copy the new generated .jar file into the NB platform library wrapper module project (step nr. 2 in the post). In fact, I need to copy it directly to the project directory, having to have a knowledge on its filesystem layout.
This makes it not really agile if the above happens often (which, BTW, is my case).
[/quote]
Workaround: create a new Ant target and include it in your build process. During the build, the JAR will be created afresh in the NetBeans module, automatically, without you needing to do anything special (once you've created that Ant target). (See "Updating the Sources" here.)
Jan 17, 2009 · Mr B Loid
I only find a drawback: Whenever I need to make changes to entity library (which is a regular NB IDE Java Library Project), I am then also required to manually copy the new generated .jar file into the NB platform library wrapper module project (step nr. 2 in the post). In fact, I need to copy it directly to the project directory, having to have a knowledge on its filesystem layout.
This makes it not really agile if the above happens often (which, BTW, is my case).
[/quote]
Workaround: create a new Ant target and include it in your build process. During the build, the JAR will be created afresh in the NetBeans module, automatically, without you needing to do anything special (once you've created that Ant target). (See "Updating the Sources" here.)
Jan 17, 2009 · Geertjan Wielenga
I only find a drawback: Whenever I need to make changes to entity library (which is a regular NB IDE Java Library Project), I am then also required to manually copy the new generated .jar file into the NB platform library wrapper module project (step nr. 2 in the post). In fact, I need to copy it directly to the project directory, having to have a knowledge on its filesystem layout.
This makes it not really agile if the above happens often (which, BTW, is my case).
[/quote]
Workaround: create a new Ant target and include it in your build process. During the build, the JAR will be created afresh in the NetBeans module, automatically, without you needing to do anything special (once you've created that Ant target). (See "Updating the Sources" here.)
Jan 17, 2009 · Geertjan Wielenga
I only find a drawback: Whenever I need to make changes to entity library (which is a regular NB IDE Java Library Project), I am then also required to manually copy the new generated .jar file into the NB platform library wrapper module project (step nr. 2 in the post). In fact, I need to copy it directly to the project directory, having to have a knowledge on its filesystem layout.
This makes it not really agile if the above happens often (which, BTW, is my case).
[/quote]
Workaround: create a new Ant target and include it in your build process. During the build, the JAR will be created afresh in the NetBeans module, automatically, without you needing to do anything special (once you've created that Ant target). (See "Updating the Sources" here.)
Jan 17, 2009 · Mr B Loid
I'm also considering filling in a bug report on this, as I do not really happen to see any justification for this fact. Having solved that, one could keep developing a Suite (or NBP-based app.) which does include a "JPA-enabled" module all within the great NB IDE and also let it keep track of all dependencies.
[/quote]
+1 on that! Here's my issue on this, please go in there and agree with me:
http://www.netbeans.org/issues/show_bug.cgi?id=155214
Thanks for liking my humor, nice to hear. :-)
Jan 17, 2009 · Mr B Loid
I'm also considering filling in a bug report on this, as I do not really happen to see any justification for this fact. Having solved that, one could keep developing a Suite (or NBP-based app.) which does include a "JPA-enabled" module all within the great NB IDE and also let it keep track of all dependencies.
[/quote]
+1 on that! Here's my issue on this, please go in there and agree with me:
http://www.netbeans.org/issues/show_bug.cgi?id=155214
Thanks for liking my humor, nice to hear. :-)
Jan 17, 2009 · Geertjan Wielenga
I'm also considering filling in a bug report on this, as I do not really happen to see any justification for this fact. Having solved that, one could keep developing a Suite (or NBP-based app.) which does include a "JPA-enabled" module all within the great NB IDE and also let it keep track of all dependencies.
[/quote]
+1 on that! Here's my issue on this, please go in there and agree with me:
http://www.netbeans.org/issues/show_bug.cgi?id=155214
Thanks for liking my humor, nice to hear. :-)
Jan 17, 2009 · Geertjan Wielenga
I'm also considering filling in a bug report on this, as I do not really happen to see any justification for this fact. Having solved that, one could keep developing a Suite (or NBP-based app.) which does include a "JPA-enabled" module all within the great NB IDE and also let it keep track of all dependencies.
[/quote]
+1 on that! Here's my issue on this, please go in there and agree with me:
http://www.netbeans.org/issues/show_bug.cgi?id=155214
Thanks for liking my humor, nice to hear. :-)
Jan 10, 2009 · Mr B Loid
Jan 10, 2009 · Mr B Loid
Dec 31, 2008 · Tim B
Dec 29, 2008 · Tim B
Dec 29, 2008 · Ben Hosking
Dec 29, 2008 · Ben Hosking
Dec 29, 2008 · Ben Hosking
Oscar, I tried to disable code completion and came to the same result as you. (But why do you want to disable it?) I created an issue, please add your experiences to it:
http://www.netbeans.org/issues/show_bug.cgi?id=156127
Dec 25, 2008 · Z T
Dec 25, 2008 · Z T
Dec 25, 2008 · Z T
Dec 25, 2008 · Z T
Dec 25, 2008 · Z T
Dec 13, 2008 · John Jones III
Dec 11, 2008 · John Jones III
Dec 10, 2008 · Geertjan Wielenga
Dec 10, 2008 · Geertjan Wielenga
Nov 30, 2008 · Lebon Bon Lebon
Nov 30, 2008 · Mr B Loid
Nov 30, 2008 · Mr B Loid
Nov 30, 2008 · Mr B Loid
Nov 30, 2008 · Mr B Loid
Nov 30, 2008 · Mr B Loid
Nov 30, 2008 · Stacy Doss
Nov 30, 2008 · Geertjan Wielenga
Nov 27, 2008 · Lebon Bon Lebon
Nov 26, 2008 · Lebon Bon Lebon
Nov 26, 2008 · Z T
Nov 24, 2008 · Charles Ditzel
Nov 22, 2008 · Z T
Nov 22, 2008 · admin
Nov 21, 2008 · Z T
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 21, 2008 · Z T
[quote=geertjan]Are you serious? 100% of announcements on Javalobby tell you about new releases of products. This is just another release of a product, isn't it? Or do you want a law on Javalobby that says "if the application is about the Bible, it should not be allowed to be published".[/quote]
Yes I would prefer that !
It is getting ridiculous, get that junk out of the way.
How about astrology ? Ridiculous.
[/quote]
Sorry, at Javalobby we respect the opinions of those we disagree with.
Nov 20, 2008 · Z T
Nov 19, 2008 · Charles Ditzel
Nov 19, 2008 · Charles Ditzel
Nov 19, 2008 · Charles Ditzel
Nov 19, 2008 · Charles Ditzel
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 14, 2008 · Z T
if no one at Netbeans or Glassfish or the core JDK team is hit, I think we can maintain a positive outlook.
[/quote]
That's a good way of approaching it.
Nov 13, 2008 · Z T
[quote=rp117107]+1 for in-memory file system. Maybe i missed something, but i don't see any addition value in using of Open IDE API. Usually you test some API depending on JDK abstraction as java.io.File, so classes from org.openide.filesystems do not help at all ;-). [/quote]
Classes from org.openide.filesystems give you an in-memory virtual filesystem.
Nov 13, 2008 · Z T
[quote=rp117107]+1 for in-memory file system. Maybe i missed something, but i don't see any addition value in using of Open IDE API. Usually you test some API depending on JDK abstraction as java.io.File, so classes from org.openide.filesystems do not help at all ;-). [/quote]
Classes from org.openide.filesystems give you an in-memory virtual filesystem.
Nov 12, 2008 · Lebon Bon Lebon
I'm currently on 64-bit 8.04. Is 64-bit 8.10 any different than than the 8.10 that everyone else in this chain is running?
How did everyone upgrade? Did you blow away your current installation or did you upgrade using the update manager? or...what?
[/quote]
I (partly by accident and partly by design) blew away everything I had on my system. Fresh beginning, good thing sometimes.
Nov 12, 2008 · Lebon Bon Lebon
I'm currently on 64-bit 8.04. Is 64-bit 8.10 any different than than the 8.10 that everyone else in this chain is running?
How did everyone upgrade? Did you blow away your current installation or did you upgrade using the update manager? or...what?
[/quote]
I (partly by accident and partly by design) blew away everything I had on my system. Fresh beginning, good thing sometimes.
Nov 12, 2008 · Lebon Bon Lebon
I'm currently on 64-bit 8.04. Is 64-bit 8.10 any different than than the 8.10 that everyone else in this chain is running?
How did everyone upgrade? Did you blow away your current installation or did you upgrade using the update manager? or...what?
[/quote]
I (partly by accident and partly by design) blew away everything I had on my system. Fresh beginning, good thing sometimes.
Oct 21, 2008 · admin
I succeeded, described some problems and solutions here:
http://blogs.sun.com/geertjan/entry/griffon_jdk_6_update_10
Oct 15, 2008 · Nigel Wong
Anyway, in my experience it is usually the fact that NetBeans uses Swing that people don't use it.
[/quote]
But that is also exactly why those who DO use it use it. Every customer I've ever spoken to has mentioned "NetBeans Platform is Swing" as the 1st reason why they chose the NetBeans Platform over Eclipse RCP.
Oct 15, 2008 · Nigel Wong
Anyway, in my experience it is usually the fact that NetBeans uses Swing that people don't use it.
[/quote]
But that is also exactly why those who DO use it use it. Every customer I've ever spoken to has mentioned "NetBeans Platform is Swing" as the 1st reason why they chose the NetBeans Platform over Eclipse RCP.
Oct 15, 2008 · Nigel Wong
Anyway, in my experience it is usually the fact that NetBeans uses Swing that people don't use it.
[/quote]
But that is also exactly why those who DO use it use it. Every customer I've ever spoken to has mentioned "NetBeans Platform is Swing" as the 1st reason why they chose the NetBeans Platform over Eclipse RCP.
Oct 14, 2008 · Nigel Wong
Oct 14, 2008 · Nigel Wong
Oct 14, 2008 · Nigel Wong
Oct 14, 2008 · admin
I think this project could be tackled in the following phases:
Oct 14, 2008 · Nigel Wong
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
My guess is they are after the big companies that use spring all over the place, but avoid paying because of its high quality and low number of issues. To these guys, buying support if they have to is pretty much taken for granted. If they can avoid it, they won't pay. I don't think anyone truly minds big corporations being stung.
Unfortunately, the policy will also necessarily affect even small dev shops using and bundling Spring.
[/quote]
Yes. And that's also where the whole thing confuses me. If the aim is to get money (and, assuming the standard open source model of 'training and support' has been abandoned for whatever reason), then why not provide some 'enterprise features' (like some features related to security and scalability), i.e., features that a large company would have no issues paying for, given that they're committed to Spring already, while the small guys (who wouldn't buy it anyway because they don't need those kind of features as much and are now already looking for alternatives like Guice and so on) would continue using Spring for free. That approach would make much more sense to me, because the basic loyalty to the products would be maintained while probably the same amount of money would be earned, simply by following a more proportionate and (dare I say it) sensible model.
Sep 24, 2008 · Pan Pantziarka
Sep 24, 2008 · Lebon Bon Lebon
Sep 23, 2008 · Erik Thauvin
So what is the issue (except some people having a massive sense of entitlement and wanting everything for free, always)?
I expect there to be no such issues whatsoever.
[/quote]
If I give you an ice cream and then, while you're in the middle of eating it, I say to you: "By the way, after you've licked your ice cream three more times you're going to have to start paying me...", wouldn't that be very odd?
Sep 23, 2008 · Erik Thauvin
So what is the issue (except some people having a massive sense of entitlement and wanting everything for free, always)?
I expect there to be no such issues whatsoever.
[/quote]
If I give you an ice cream and then, while you're in the middle of eating it, I say to you: "By the way, after you've licked your ice cream three more times you're going to have to start paying me...", wouldn't that be very odd?
Sep 23, 2008 · Erik Thauvin
So what is the issue (except some people having a massive sense of entitlement and wanting everything for free, always)?
I expect there to be no such issues whatsoever.
[/quote]
If I give you an ice cream and then, while you're in the middle of eating it, I say to you: "By the way, after you've licked your ice cream three more times you're going to have to start paying me...", wouldn't that be very odd?
Sep 23, 2008 · Erik Thauvin
So what is the issue (except some people having a massive sense of entitlement and wanting everything for free, always)?
I expect there to be no such issues whatsoever.
[/quote]
If I give you an ice cream and then, while you're in the middle of eating it, I say to you: "By the way, after you've licked your ice cream three more times you're going to have to start paying me...", wouldn't that be very odd?
Sep 23, 2008 · Erik Thauvin
Sep 18, 2008 · Stefan Saasen
Thanks all for the support for the perspective address in this article. Maybe a way forward is to create a JSR for a standardized layout manager? Sun takes JSRs very seriously. On the other hand, why not look for avenues into the OpenJDK? How open is it if the most popular layout manager (maybe not now, but only not now, if not now, because not enough actual developers know about it) is not part of the "Open"JDK? Just two thoughts, take them as you want them. One can play victim to your feelings about company XYZ, or you could take the bull by the horns yourself. Either see Sun as the guardian of Java, and feel yourself to be submissive to it (e.g., "why does Sun not blablabla" fits into this line of thinking), or consider yourself equal partners and push your own line, via the OpenJDK, or some other route.
Secondly, thanks Sidewinder and Andrew McVeigh for supporting my articles on JL. Re your comments about a book, Andrew, I think a very practical book like Jason Rudolph's one for Grails should be written for Griffon (once all the dust settles, of course).
Sep 16, 2008 · Andres Almiray
Sep 15, 2008 · Mads Kristensen
Sep 07, 2008 · admin
Me thinks everything Google does is geared towards discovering what my personal proclivities are so that Google can sell that data to those who make profit from that knowledge. Me thinks that Microsoft's upcoming browser, which will let the user erase his/her footprint on the web, is scaring the sh%$ out of Google. Me thinks Google desperately needs a browser that it alone has control over. Me thinks Google is the Big Brother George Orwell would have written about if he had written 1984 today. Me thinks that explains Chrome.
Sep 05, 2008 · Lebon Bon Lebon
How does your approach differ to mine here:
http://blogs.sun.com/geertjan/entry/generate_uml_diagrams_into_javadoc
Also, it would be cool if the target could be set on the suite and then all Javadoc for all modules would be created, so that the new target would be added in the suite's build.xml only, and not in each of the potentially many modules within it. Do you have any thoughts on that?
Sep 05, 2008 · admin
Aug 27, 2008 · admin
Aug 22, 2008 · Ben Hirsch
In the same site, there is this other poll, which seems to indicate massive use of Tomcat. But... Tomcat don't have support for EJB3! [snipsnipsnip]
[/quote]
Really? Depends. http://java.sys-con.com/node/487561
Aug 22, 2008 · Ben Hirsch
In the same site, there is this other poll, which seems to indicate massive use of Tomcat. But... Tomcat don't have support for EJB3! [snipsnipsnip]
[/quote]
Really? Depends. http://java.sys-con.com/node/487561
Aug 22, 2008 · Ben Hirsch
In the same site, there is this other poll, which seems to indicate massive use of Tomcat. But... Tomcat don't have support for EJB3! [snipsnipsnip]
[/quote]
Really? Depends. http://java.sys-con.com/node/487561
Aug 21, 2008 · Lebon Bon Lebon
An excuse for all seasons...
[/quote]
But in and of itself how can "the use of open source code" directly lead to an impact on the quality of software?
Aug 21, 2008 · Lebon Bon Lebon
An excuse for all seasons...
[/quote]
But in and of itself how can "the use of open source code" directly lead to an impact on the quality of software?
Aug 21, 2008 · Lebon Bon Lebon
An excuse for all seasons...
[/quote]
But in and of itself how can "the use of open source code" directly lead to an impact on the quality of software?
Aug 18, 2008 · Stacy Doss
P.S. "Enterprise" also stands for "Expensive" :-)
[/quote]
Yeah, like the "E" for "Enterprise" in the 100% free "Java EE".
Aug 18, 2008 · Stacy Doss
P.S. "Enterprise" also stands for "Expensive" :-)
[/quote]
Yeah, like the "E" for "Enterprise" in the 100% free "Java EE".
Aug 18, 2008 · Stacy Doss
P.S. "Enterprise" also stands for "Expensive" :-)
[/quote]
Yeah, like the "E" for "Enterprise" in the 100% free "Java EE".
Aug 18, 2008 · Stacy Doss
That really slams it home for me. Excellent point.
Aug 10, 2008 · Rushabh Joshi
Jul 21, 2008 · Daniel Spiewak
Jul 19, 2008 · admin
Jul 19, 2008 · Geertjan Wielenga
Jul 18, 2008 · Geertjan Wielenga
Jul 18, 2008 · Geertjan Wielenga
Jul 17, 2008 · Vladimir Carrer
Jul 04, 2008 · Vera Tushurashvili
Jul 03, 2008 · Vera Tushurashvili
Thanks again for this info, I'm learning a lot from it. However, I want to comment on this paragraph:
I like Spring RCP a lot (and am working on a second part to "Getting Started with Spring RCP", which should be published on Javalobby either today or tomorrow), but to say that with NetBeans RCP you "have to learn new stuff (from ground up) and you should forget nearly all things you learned for Swing", is simply untrue. It is 100% false, in fact. You can use Swing as much as you like. Yes, you can use JOptionPanes, though NetBeans RCP offers its own alternatives, you are right about that. However, similarly, with Spring RCP you can continue using the standard Swing dialogs, even though Spring RCP has its own alternatives that it recommends you use. That's great isn't it, both offer additional Swing components. Not bad in either case. I must say that I'm spending the same amount of time learning Spring RCP as I did when I started learning NetBeans RCP.
The real difference between them is that NetBeans RCP is modular, letting you create applications that can be extended via plugins, while Spring RCP doesn't let you do that. Nothing wrong with that. It only means that NetBeans RCP is more suited to very large applications than Spring RCP is. It would be completely impossible, for example, to have created NetBeans IDE on top of Spring RCP. (Plus, I can create my own independent plugins for any application based on top of NetBeans RCP... but how would I create a plugin for the application you are building in this series of articles? And how would you install that plugin into your application?) Since NetBeans RCP is modular, it was perfect for NetBeans IDE, since the IDE is created by many different people in an extremely distributed environment, so that a modular approach fits very well with the distributed workplaces, as well as resulting in very clean code (i.e., no spaghetti code across modules). Therefore, I believe Spring RCP is closer in intention to JSR-296 than it is to NetBeans RCP (actually, it is called "NetBeans Platform") and Eclipse RCP.
Jul 02, 2008 · Dietrich Kappe
Jul 02, 2008 · Mads Kristensen
Here are some other articles on this topic that might be found useful:
http://www.netbeans.org/community/magazine/html/03/schliemann/
http://www.netbeans.org/community/magazine/html/04/schliemann.html
http://platform.netbeans.org/tutorials/60/nbm-prolog.html
Jul 02, 2008 · Jordi R Cardona
Here are some other articles on this topic that might be found useful:
http://www.netbeans.org/community/magazine/html/03/schliemann/
http://www.netbeans.org/community/magazine/html/04/schliemann.html
http://platform.netbeans.org/tutorials/60/nbm-prolog.html
Jul 02, 2008 · admin
Jul 01, 2008 · admin
Jul 01, 2008 · admin
Yes, but let's face it....since the project lead left to join Adobe, JSR-296 seems to be as dead as the dodo, if I recall correctly.
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1567
The last release is from Nov 2007 when Hans was still employed with Sun...doesn't exactly install confidence in the long term viability of this JSR. Say what you want about Spring, but at least it has a large active community.
[/quote]
True enough, except that Spring RCP hasn't existed in any real form over the past years. Now it's back but there's no guarantee that it'll go anywhere. (The 1.0.0 release just came out, after two years, and so who knows when the next release will be with us?) I would personally like it to do so (hence this article and hence the tooling I'm providing, should you need evidence), but there's no guarantees (hard to argue with Kirill's comments here). In that sense, depending on Spring RCP is as problematic as depending on JSR-296, but for different reasons. (And that's why I focused only on the technology in this article without being distracted by the politics around it.)
Jul 01, 2008 · admin
Yes, but let's face it....since the project lead left to join Adobe, JSR-296 seems to be as dead as the dodo, if I recall correctly.
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1567
The last release is from Nov 2007 when Hans was still employed with Sun...doesn't exactly install confidence in the long term viability of this JSR. Say what you want about Spring, but at least it has a large active community.
[/quote]
True enough, except that Spring RCP hasn't existed in any real form over the past years. Now it's back but there's no guarantee that it'll go anywhere. (The 1.0.0 release just came out, after two years, and so who knows when the next release will be with us?) I would personally like it to do so (hence this article and hence the tooling I'm providing, should you need evidence), but there's no guarantees (hard to argue with Kirill's comments here). In that sense, depending on Spring RCP is as problematic as depending on JSR-296, but for different reasons. (And that's why I focused only on the technology in this article without being distracted by the politics around it.)
Jul 01, 2008 · admin
Yes, but let's face it....since the project lead left to join Adobe, JSR-296 seems to be as dead as the dodo, if I recall correctly.
https://appframework.dev.java.net/servlets/ReadMsg?list=users&msgNo=1567
The last release is from Nov 2007 when Hans was still employed with Sun...doesn't exactly install confidence in the long term viability of this JSR. Say what you want about Spring, but at least it has a large active community.
[/quote]
True enough, except that Spring RCP hasn't existed in any real form over the past years. Now it's back but there's no guarantee that it'll go anywhere. (The 1.0.0 release just came out, after two years, and so who knows when the next release will be with us?) I would personally like it to do so (hence this article and hence the tooling I'm providing, should you need evidence), but there's no guarantees (hard to argue with Kirill's comments here). In that sense, depending on Spring RCP is as problematic as depending on JSR-296, but for different reasons. (And that's why I focused only on the technology in this article without being distracted by the politics around it.)
Jul 01, 2008 · admin
Jun 27, 2008 · Lebon Bon Lebon
Jun 25, 2008 · Vera Tushurashvili
Jun 23, 2008 · Vera Tushurashvili
Hi Joshua! Those red error marks indicate that some of the classes in those packages are unable to compile for some reason. You should try to expand those packages and find those classes, which will also have those red error marks. Maybe you're missing a library in your migrated application? It's possible that you migrated your application, but somehow failed to include the libraries on which the application depends.
The second question can partly be explained by the fact that you're using different look and feels. Try running the 6.1 version with the Metal look and feel, which is what you seem to have used for the 5.5 screenshot.
Jun 19, 2008 · Geertjan Wielenga
Jun 18, 2008 · Stacy Doss
Jun 16, 2008 · Trevor Sullivan
Edit: Oh looks like the blog to javalobby stripped all the generic info form the code
[/quote]
Thanks, fixed that.
Jun 16, 2008 · Trevor Sullivan
Edit: Oh looks like the blog to javalobby stripped all the generic info form the code
[/quote]
Thanks, fixed that.
Jun 16, 2008 · Trevor Sullivan
Edit: Oh looks like the blog to javalobby stripped all the generic info form the code
[/quote]
Thanks, fixed that.
Jun 12, 2008 · adam bien
Jun 10, 2008 · admin
Jun 09, 2008 · admin
Jun 06, 2008 · admin
Jun 04, 2008 · Dieter Komendera
Jun 03, 2008 · admin
[quote=zynasis]yeh, this is pretty useless[/quote]
?
Jun 03, 2008 · admin
[quote=zynasis]yeh, this is pretty useless[/quote]
?
Jun 03, 2008 · admin
[quote=zynasis]yeh, this is pretty useless[/quote]
?
Jun 02, 2008 · admin
May 28, 2008 · Mads Kristensen
May 26, 2008 · Guy -
[quote=em109342] except that it leaves you where you are? [/quote]
That's the point. It leaves you where you are. Very handy when you're working on a line of code and you quickly want to add a semicolon without going to the end of the line. Try it.
May 26, 2008 · Guy -
[quote=em109342] except that it leaves you where you are? [/quote]
That's the point. It leaves you where you are. Very handy when you're working on a line of code and you quickly want to add a semicolon without going to the end of the line. Try it.
May 26, 2008 · Guy -
[quote=em109342] except that it leaves you where you are? [/quote]
That's the point. It leaves you where you are. Very handy when you're working on a line of code and you quickly want to add a semicolon without going to the end of the line. Try it.
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
OK, you normally need some sort of IDE metadata. If this is the point .. why not unify these metadata over different IDEs?
[/quote]
Exactly. Right now, you can extend Eclipse by providing OSGi bundles, you can extend GlassFish by providing OSGi bundles, etc. The most common way of extending Java applications today is via OSGi. So why not make this possible for NetBeans and IntelliJ too?
May 26, 2008 · admin
May 26, 2008 · admin
@Ian: Great to meet you too. Sorry for the delayed response, was hoping more people would respond first. Hope to meet you again somehow!
@Toni: That would be cool. I'm sure there'll be some kind of OSGi interaction at some point.
@ James: I agree.
@Michael: Yes, of course, use Java for reusable code. But how do you share it between different applications, e.g., between Eclipse and NetBeans? You need some kind of distribution format that is understood by both, as well as by IntelliJ. That would seem to be OSGi bundles. If my plugin for NetBeans contains business logic and external libraries that I could use in my IntelliJ or Eclipse plugin, it would be very cool if there was a shared distribution mechanism like that.
May 25, 2008 · Bernhard Kappe
May 23, 2008 · Hooman Taherinia
May 23, 2008 · Lebon Bon Lebon
May 22, 2008 · Jamie
[quote]As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.[/quote]
+1. I think that more people who hold this view should come forward, because at the moment the main discussion seems to be "which of the various Closures proposals should be included in Java 7?" Seems to me that the "let's not clutter Java" (LNCJ) camp has been too quiet. Maybe because Neal Gafter et al are pretty authoratative voices? Well, the LNCJ camp includes Josh Bloch, so that can't be bad...
May 20, 2008 · Mr B Loid
May 20, 2008 · Mr B Loid
May 20, 2008 · Mr B Loid
May 17, 2008 · Lebon Bon Lebon
Personally, I believe the Jemmy/Jelly support for NetBeans RCP applications is better to use, because there are mock objects for the typical NetBeans RCP objects, such as TopComponents. I.e., the NetBeans team has really tailored this support to their specific needs, while Fest is more generic. Have a look at this, for an example:
http://blogs.sun.com/geertjan/entry/gui_testing_on_the_netbeans1
May 11, 2008 · admin
May 10, 2008 · admin
May 10, 2008 · Alex Johnson
May 09, 2008 · Alex Johnson
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.
[/quote]
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.
May 09, 2008 · Alex Johnson
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.
[/quote]
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.
May 09, 2008 · Alex Johnson
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.
[/quote]
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.
May 02, 2008 · Vera Tushurashvili
May 01, 2008 · Geertjan Wielenga
May 01, 2008 · Vera Tushurashvili
Apr 27, 2008 · Schlawack
Apr 22, 2008 · admin
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
And I'm off now to look at my home heating system and see whether I can monitor / control it in the same way.
[/quote]
I tried the same thing yesterday, but failed. Maybe Adam can give us a hint about how to make that first fundamental connection from Java to a home heating system. Or, at least, how to figure out whether that is possible with one's home heating system.
Apr 21, 2008 · admin
Please, from what I can see here there is hardly anything to this.
Polling, making adjustments and reporting/control via a web page.
Most semi serious applications already do this in one way or another.
[/quote]
So, you agree that the application does what it is meant to do. How is that "average"? Isn't that at least "good"? Is complexity a required attribute for something being "good"? So, Adam should make his application much more complex and only then would his application be worth mentioning? He needed an application to control his heating system. It does that in a very ingenious way, leveraging a wide range of technologies. I'd be very happy to interview you, zynasis, about the applications you've made. :-) Really.
Apr 21, 2008 · admin
Please, from what I can see here there is hardly anything to this.
Polling, making adjustments and reporting/control via a web page.
Most semi serious applications already do this in one way or another.
[/quote]
So, you agree that the application does what it is meant to do. How is that "average"? Isn't that at least "good"? Is complexity a required attribute for something being "good"? So, Adam should make his application much more complex and only then would his application be worth mentioning? He needed an application to control his heating system. It does that in a very ingenious way, leveraging a wide range of technologies. I'd be very happy to interview you, zynasis, about the applications you've made. :-) Really.
Apr 21, 2008 · admin
Please, from what I can see here there is hardly anything to this.
Polling, making adjustments and reporting/control via a web page.
Most semi serious applications already do this in one way or another.
[/quote]
So, you agree that the application does what it is meant to do. How is that "average"? Isn't that at least "good"? Is complexity a required attribute for something being "good"? So, Adam should make his application much more complex and only then would his application be worth mentioning? He needed an application to control his heating system. It does that in a very ingenious way, leveraging a wide range of technologies. I'd be very happy to interview you, zynasis, about the applications you've made. :-) Really.
Apr 21, 2008 · admin
Apr 20, 2008 · Lebon Bon Lebon
Hi Alex, I will come to your session and I look forward to meeting you. I've also made a Fest plugin for NetBeans IDE:
http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=7964
Hope to meet up with you,
Geertjan
Apr 17, 2008 · Lebon Bon Lebon
@Shay: wow that stuff in JDeveloper looks cool. I think I might take JDeveloper for a spin soon especially for that reason.
@shaulgo: you're right, without the sources debugging would be problematic. However, I really like the idea of being able to look at the internals of a Swing app where I would simply have the JAR and nothing else. Just for the fun of it, but I'm guessing there'd be practical reaons too.
@Maxim, congrats with this cool tool and hope to catch up with you at JavaOne!
Apr 17, 2008 · Geertjan Wielenga
@Shay: wow that stuff in JDeveloper looks cool. I think I might take JDeveloper for a spin soon especially for that reason.
@shaulgo: you're right, without the sources debugging would be problematic. However, I really like the idea of being able to look at the internals of a Swing app where I would simply have the JAR and nothing else. Just for the fun of it, but I'm guessing there'd be practical reaons too.
@Maxim, congrats with this cool tool and hope to catch up with you at JavaOne!
Apr 16, 2008 · Lebon Bon Lebon
Apr 16, 2008 · Geertjan Wielenga
Apr 13, 2008 · Dietrich Kappe
Apr 11, 2008 · Geertjan Wielenga
Apr 11, 2008 · Michal Talaga
Apr 10, 2008 · Ben Hosking
Apr 10, 2008 · Marco Sordi
Apr 10, 2008 · Geertjan Wielenga
Apr 08, 2008 · Geertjan Wielenga
Apr 08, 2008 · Lebon Bon Lebon
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · Lebon Bon Lebon
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · Lebon Bon Lebon
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · Geertjan Wielenga
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · Geertjan Wielenga
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · Geertjan Wielenga
This whole thing is such a bad idea on so many levels. If you have a good UI design, why do you want to move stuff around?
[/quote]
As pointed out by one or two people above, maybe you have different end users and the person doing the packaging is not a Java programmer. The Spring config file would be a way for the assembler, a non Java programmer, to assemble an application from the decoupled Swing components provided by the programmer.
[quote=cm38280]
How do people maintaining your code figure out where some panel class MyPanel exists within your application?
[/quote]
Most IDEs (at least NetBeans does, for sure) have support within Spring config files exactly for that purpose. You can click on a reference to a Java source file and then the source file in question opens. You also have code completion for the value of the "class" attribute, so that can be used for filling in the values and verifying that the referenced class actually exists.
[quote=cm38280]
Spring is fantastic at configuring "service" classes which can be accessed from within an app but it is not an appropriate XML description on so many levels for configuring instances of any old POJO (whether that be data classes or GUI components).
[/quote]
I agree that this approach is probably atypical. But at the same time there could be scenarios out there where this could be useful. And the XML would not necessarily be reams and reams of tags either -- possibly you'd have three or four panels that could be exchanged with each other and the assembler would do this via the Spring config file. Again, I'm not making this scenario up myself -- look at the comments above where at least one respondent sees this as being applicable to their real life needs.
[quote=cm38280]
I see "bean, I see "property", I see "value" and I see "list" but nowhere do I get a feel for what the panel contains nor its layout.
[/quote]
In the scenario of there being an assembler of the application, that's not relevant, they don't need to see the panel (or other decoupled Swing component) in question. However, if they do want to see the layout or other content, they can simply click to it from the Spring config file (as pointed out above).
[quote=cm38280]
Just take one step back and look at the sheer awfulness of the XML you've posted above!
[/quote]
I think I've responded to these points. I'm not arguing that this is useful for each and every Swing app, I'm just pointing out that this is possible in those cases where it makes sense.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 08, 2008 · admin
I'm not saying that closures are essential to the survival of Java, but the question should be asked about whether it would make solving problems easier moving into the future. As the types of problems being solved evolve, the tools in the toolbox need to evolve too.
[/quote]
I agree. But there are two ways in which tools in a toolbox can evolve. Let's take a handsaw as an example. You discover that your handsaw is not helpful when you want to chop down trees. You realize your tool needs to evolve. So, what do you do? Do you bolt the capabilities of a chainsaw onto your handsaw? No. You simply get a chainsaw in addition to your handsaw. You put them in the same toolbox and whenever you need to chop trees, you use your chainsaw, while for other work you continue using your handsaw.
Apr 07, 2008 · admin
My concern is that closures, in each of the various variations presented thus far, are really complex. That's okay, even. However, each closure proposal is interpreted in different ways by different people. These complexities and ambiguities are not going to be doing Java any favors. If, every time a language comes up with a new structure or a new approach to doing something, Java responds by finding a way of replicating that functionality or approach... isn't there going to come a point where it, in addition to the problems of complexity and ambiguity, also will find itself simply being bloated? How far can we keep twisting Java in new directions?
This is not a case of advocating "starvation" of Java, as Serge, in the previous response, suggests. But an argument in favor of... simplicity. Let's let Java do what Java does. Let's not add layers of complexity. If you find Java limiting, if you really can't do without something that is found in another language, then USE that other language, whatever it is. Don't try to shoe horn their crown jewels into Java.
Now, the second element of my argument, which is separate from the above, is: Java has a young, modern, and hip cousin. Its name is Groovy. It does all the things that Java does, but it does them in a cooler way. It will never replace Java and no one is seriously arguing that it will. However, sometimes it would like to be around to lift Java up to the places where it can't reach. One of these places is closures. And, guess what? They can work perfectly together. You can mix and match Java at will. So, why not move Groovy into the house where Java has been living for so long? They'll be fine together and complement each other's strengths while helping to overcome each other's weaknesses. They're logical extensions of each other. Should you want flexibility and dynamic behavior... you'd have Groovy. Eventually, you'll have speed there too. (That's the next item on the Groovy team's wishlist.) Should you want heavy lifting and low level processing, you'd have Java.
Apr 07, 2008 · Lebon Bon Lebon
Apr 07, 2008 · Geertjan Wielenga
Apr 07, 2008 · jim
I believe you. Personally, I simply feel it's odd to have two articles in a row on EclipseZone which are essentially about migrating away from Eclipse to other IDEs (IntelliJ and NetBeans respectively). It almost seems like a trend, and I doubt it's of much interest to an Eclipse developer. I'm sure it is of interest to an IntelliJ or a NetBeans developer but there are other Zones for that.
[/quote]
Again, to me, these articles are not about moving away from Eclipse. They are about using Eclipse together with other IDEs. That's, after all, what developers out there often do. Many companies have some Eclipse users, some NetBeans users, and some IntelliJ users. That's not going to change. Therefore, this article makes perfect sense within EclipseZone.
Apr 07, 2008 · jim
I believe you. Personally, I simply feel it's odd to have two articles in a row on EclipseZone which are essentially about migrating away from Eclipse to other IDEs (IntelliJ and NetBeans respectively). It almost seems like a trend, and I doubt it's of much interest to an Eclipse developer. I'm sure it is of interest to an IntelliJ or a NetBeans developer but there are other Zones for that.
[/quote]
Again, to me, these articles are not about moving away from Eclipse. They are about using Eclipse together with other IDEs. That's, after all, what developers out there often do. Many companies have some Eclipse users, some NetBeans users, and some IntelliJ users. That's not going to change. Therefore, this article makes perfect sense within EclipseZone.
Apr 07, 2008 · jim
I believe you. Personally, I simply feel it's odd to have two articles in a row on EclipseZone which are essentially about migrating away from Eclipse to other IDEs (IntelliJ and NetBeans respectively). It almost seems like a trend, and I doubt it's of much interest to an Eclipse developer. I'm sure it is of interest to an IntelliJ or a NetBeans developer but there are other Zones for that.
[/quote]
Again, to me, these articles are not about moving away from Eclipse. They are about using Eclipse together with other IDEs. That's, after all, what developers out there often do. Many companies have some Eclipse users, some NetBeans users, and some IntelliJ users. That's not going to change. Therefore, this article makes perfect sense within EclipseZone.
Apr 07, 2008 · jim
I believe you. Personally, I simply feel it's odd to have two articles in a row on EclipseZone which are essentially about migrating away from Eclipse to other IDEs (IntelliJ and NetBeans respectively). It almost seems like a trend, and I doubt it's of much interest to an Eclipse developer. I'm sure it is of interest to an IntelliJ or a NetBeans developer but there are other Zones for that.
[/quote]
Again, to me, these articles are not about moving away from Eclipse. They are about using Eclipse together with other IDEs. That's, after all, what developers out there often do. Many companies have some Eclipse users, some NetBeans users, and some IntelliJ users. That's not going to change. Therefore, this article makes perfect sense within EclipseZone.
Apr 07, 2008 · Lebon Bon Lebon
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Lebon Bon Lebon
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Lebon Bon Lebon
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Lebon Bon Lebon
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Geertjan Wielenga
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Geertjan Wielenga
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Geertjan Wielenga
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 07, 2008 · Geertjan Wielenga
Making sure that your components are decoupled and easy to test is all very well, but you don't need to use Spring to achieve that. You could just as easily use all of the decoupled classes that you have written but wire them together in some Java code.
I fail to see the advantage of 100s of lines of XML, several JAR dependencies and moving errors from compile time to runtime, over a much more concise Java wiring of the components.
[/quote]
I think there might be several reasons why one would take this approach. A simple usecase might be if the developer/s is/are already familiar with Spring in the context of the web/Java EE world. In that context, it would be nice to continue using the same framework within the desktop space.
Secondly, imagine that, instead of 4 or 5 Swing components as in this example, you had dozens, or even hundreds or thousands. Having one centralized location where you manage the interactions between these components can only be a good thing, right? Because in that case your wiring code would be spread across MANY Java classes, I don't believe having a single Java class handling all the interactions of thousands of Swing components would be conceivable.
Apr 04, 2008 · admin
[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]
Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.
Apr 04, 2008 · admin
[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]
Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.
Apr 04, 2008 · admin
[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]
Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.
Apr 04, 2008 · admin
[quote=jsbournival]In that optic, I think JSR 241 would help Groovy's case ...[/quote]
Yes, though that's something that confuses me about the Groovy community: there doesn't seem to be much desire to work on their JSR. If their work were to be treated as just another JSR, the chances of inclusion in the JDK would be many times larger I believe. Look at JSR 295 and JSR 296 and the several other JSRs that are lining up to be integrated in JDK 7. The JSR process would give everyone the opportunity to look at Groovy as just another JSR and go through the same process of evaluation and discussion. The JSR process has defects, sure, but also benefits in that regard.
Apr 04, 2008 · admin
Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project? IMO, this makes a lot of sense.
[/quote]
And that, to the very last letter, is exactly the argument made in this article.
Apr 04, 2008 · admin
Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project? IMO, this makes a lot of sense.
[/quote]
And that, to the very last letter, is exactly the argument made in this article.
Apr 04, 2008 · admin
Let's say for a moment you are developing a Java class that needs to use closures (or any dynamic language feature), wouldn't it be nice to just write just this particular class in Groovy seamlessly without having bring extra jars to your project? IMO, this makes a lot of sense.
[/quote]
And that, to the very last letter, is exactly the argument made in this article.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
[quote=mark haniford]I wouldn't go as far to say that Groovy is a huge step backwards for Java. But I think there's a bit of a backdoor insinuation that Groovy should be the successor to Java in this post, and that's just not going to happen.[/quote]
Don't confuse your interpretation with my insinuation. :-) I didn't insinuate anything at all. I suggested that instead of bending Java in wacky angles to introduce closures, why not promote Groovy to be Java's official scripting language so that, if someone were interested in using closures, they'd be able to do so. In Groovy.
Apr 04, 2008 · admin
Groovy is sometimes touted as being Java plus stuff, but in fact it's more like Java minus stuff.
int i="hello"; is valid Groovy code, but fails at runtime. Why would we want to step backwards by introducing runtime errors?
[/quote]
Is that really your argument against Groovy? FYI, int i = "hello" doesn't fail at runtime.
Apr 04, 2008 · admin
Groovy is sometimes touted as being Java plus stuff, but in fact it's more like Java minus stuff.
int i="hello"; is valid Groovy code, but fails at runtime. Why would we want to step backwards by introducing runtime errors?
[/quote]
Is that really your argument against Groovy? FYI, int i = "hello" doesn't fail at runtime.
Apr 04, 2008 · admin
Groovy is sometimes touted as being Java plus stuff, but in fact it's more like Java minus stuff.
int i="hello"; is valid Groovy code, but fails at runtime. Why would we want to step backwards by introducing runtime errors?
[/quote]
Is that really your argument against Groovy? FYI, int i = "hello" doesn't fail at runtime.
Apr 04, 2008 · admin
[quote=jordanz]Another Java is dead post. Java is doing just fine thank you. There will be no successor to Java. Java will be around for quite a long time.[/quote]
Nope. I didn't say that. :-) Does it make a difference that I didn't say that? I guess not. Just because I'm saying that maybe Java has reached its limit in terms of growth, doesn't mean I'm saying it's dead does it? (Myself, physically, I stopped growing a few years ago. And I'm certainly not dead.) All I'm saying is -- let's stop bending Java out of shape: let's enrich it by making Groovy available to the JDK.
Of course, you're free to go on suggesting that I said that Java is dead. That's up to you. It's not supported by anything I actually believe (in fact, I love Java, it's by far my favorite language).
Apr 04, 2008 · admin
[quote=jordanz]Another Java is dead post. Java is doing just fine thank you. There will be no successor to Java. Java will be around for quite a long time.[/quote]
Nope. I didn't say that. :-) Does it make a difference that I didn't say that? I guess not. Just because I'm saying that maybe Java has reached its limit in terms of growth, doesn't mean I'm saying it's dead does it? (Myself, physically, I stopped growing a few years ago. And I'm certainly not dead.) All I'm saying is -- let's stop bending Java out of shape: let's enrich it by making Groovy available to the JDK.
Of course, you're free to go on suggesting that I said that Java is dead. That's up to you. It's not supported by anything I actually believe (in fact, I love Java, it's by far my favorite language).
Apr 04, 2008 · admin
But if you want to augment Java syntax without breaking anything, with something that actually works and people like, Groovy is the obvious choice I think.
[/quote]
Well said!
Apr 04, 2008 · admin
But if you want to augment Java syntax without breaking anything, with something that actually works and people like, Groovy is the obvious choice I think.
[/quote]
Well said!
Apr 04, 2008 · admin
But if you want to augment Java syntax without breaking anything, with something that actually works and people like, Groovy is the obvious choice I think.
[/quote]
Well said!
Apr 04, 2008 · admin
But if you want to augment Java syntax without breaking anything, with something that actually works and people like, Groovy is the obvious choice I think.
[/quote]
Well said!
Apr 04, 2008 · Rebecca
Apr 04, 2008 · Rebecca
Apr 04, 2008 · admin
Apr 02, 2008 · Mr B Loid
Apr 02, 2008 · DeveloperZone PR
Thanks. :-)
Part 2 was published sometime ago already:
http://java.dzone.com/news/how-add-resize-functionality-v
Apr 02, 2008 · Geertjan Wielenga
Thanks. :-)
Part 2 was published sometime ago already:
http://java.dzone.com/news/how-add-resize-functionality-v
Apr 02, 2008 · Vincent Stoessel
Apr 01, 2008 · jim
No, I'm not "a Sun employee and a NetBean's evangelist".
I'm a Sun employee and a technical writer. I'm not an evangelist at all. And I'm only a blogger because I like recording the things I learn. I'm a person with my own opinion. I don't think pretending that one IDE is the best at everything makes much sense. Each IDE has its strengths and weaknesses, everyone knows that. Many people out there use many IDEs at the same time. Personally, I've contributed a plugin to the IntelliJ repository recently.
From another perspective, I'm an advocate of the NetBeans Platform. The NetBeans Platform is a Swing application framework that can be used from any IDE. Unfortunately only NetBeans IDE provides productivity tools for the NetBeans Platform, like wizards. So, from that perspective I'm IDE-agnostic too.
Anyway, I'm not much of a fan for long discussions. You can either believe me or not. My blog is full of evidence, should you need it, that I prefer common sense over marketing speak.
Apr 01, 2008 · jim
Apr 01, 2008 · Vera Tushurashvili
Apr 01, 2008 · Vera Tushurashvili
Apr 01, 2008 · Vincent Stoessel
Sounds like a good idea. I will make a plugin soon that does this. Also, you can add an enhancement request here:
http://www.netbeans.org/community/issues.html
Mar 30, 2008 · Geertjan Wielenga
Mar 30, 2008 · Lebon Bon Lebon
Mar 26, 2008 · Danger Canty
Mar 25, 2008 · Peter Stofferis
Mar 18, 2008 · Peter Stofferis
Mar 16, 2008 · Alex Johnson
Here are some alternatives: eye vinegar, eye acid, eye poison. I especially like "eye poison". And isn't "poison" more or less the exact opposite of "candy"?
Mar 09, 2008 · Lebon Bon Lebon
Paul, what you describe shouldn't be happening. Yes, you should certainly try 6.1 Beta. But if the problem persists, then there's something wrong with your set up that we need to look at. I'd be very happy to help you. Maybe you're using an old user directory, for example. I'd recommend using a completely new user directory (just copy the old one somewhere) when encountering performance problem while trying out a new version.
Mar 06, 2008 · Dietrich Kappe
Jeroen, read the pattern in which the leaves fall from the trees, the shape of the clouds at midday, and the dewdrops in the morning, which I have to assume are there for a reason, and I can only conclude that etc. etc. etc.
You are drawing so many baseless conclusions, that I don't know where to begin to help you. :-)
PS: The fact that you think Sun would actually put a stop to a blog, any blog, shows how far off base you are.
Mar 06, 2008 · Dietrich Kappe
Mar 05, 2008 · Peter Stofferis
Mar 04, 2008 · Mr B Loid
Mar 04, 2008 · Geertjan Wielenga
Feb 29, 2008 · admin
I made something similar, but not nearly as good, sometime ago:
http://blogs.sun.com/geertjan/entry/source_file_visualizers
Why don't you try to make yours part of the official distribution?
Feb 22, 2008 · Srirangan Srinivasan
Feb 22, 2008 · Geertjan Wielenga
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Srirangan Srinivasan
Feb 21, 2008 · Geertjan Wielenga
Feb 21, 2008 · Srirangan Srinivasan
Here are some tips for Hermien:
http://www.techienuggets.com/Comments?tx=2752
Feb 21, 2008 · Geertjan Wielenga
Here are some tips for Hermien:
http://www.techienuggets.com/Comments?tx=2752
Feb 21, 2008 · Srirangan Srinivasan
Feb 21, 2008 · Geertjan Wielenga
Feb 21, 2008 · Lebon Bon Lebon
Feb 19, 2008 · Lebon Bon Lebon
Feb 19, 2008 · Aaron Korver
Feb 19, 2008 · Geertjan Wielenga
Feb 13, 2008 · Lebon Bon Lebon
Feb 12, 2008 · Erik Thauvin
"My point about 'sensible' is that if you're to bind a property to UI elements through the beans binding then the wizards should be smarter about creating said fields."
Wait a minute: you need to read the article again. The wizards didn't create any fields at all. I first created a JTextField and a JTextArea myself. I named them jTextArea1 and JTextField1. My bad. Don't blame the IDE. Then I bound them to each other. So, are you saying the field names should have changed once I bound them together? That doesn't seem right to me.
Feb 11, 2008 · Erik Thauvin
Feb 11, 2008 · admin
Feb 10, 2008 · admin
Feb 10, 2008 · admin
Feb 10, 2008 · admin
Feb 10, 2008 · Marc Chung
For example, here is VeraSeBd.tiff in action:
Feb 10, 2008 · Marc Chung
For example, here is VeraSeBd.tiff in action:
Feb 10, 2008 · Marc Chung
For example, here is VeraSeBd.tiff in action:
Feb 10, 2008 · Marc Chung
For example, here is VeraSeBd.tiff in action:
Feb 08, 2008 · Marc Chung
Feb 07, 2008 · Peter Stofferis
Feb 06, 2008 · Lebon Bon Lebon
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Lebon Bon Lebon
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Lebon Bon Lebon
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Lebon Bon Lebon
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Geertjan Wielenga
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Geertjan Wielenga
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Geertjan Wielenga
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 06, 2008 · Geertjan Wielenga
Jacek, I agree with you that not everything must be in Java. However, on the other hand, I find these arguments from the Lobo page pretty convincing in this regard, under the heading "Why a Pure Java Browser?":
There are a number of advantages to be derived from a browser that is written in Java as opposed to a language compiled into native code, namely:Feb 01, 2008 · Erik Thauvin
Jan 17, 2008 · Lebon Bon Lebon