Related
Basically, I do lots of one-off code generation, large-scale refactorings, etc. etc. in Java.
My tool language of choice is Python, but I'll take whatever solutions you can offer.
Here is a simplified illustration of what I would like, in a pseudocode
Generating an implementation for an interface
search within my project:
for each Interface as iName:
write class(name=iName+"Impl", implements=iName)
search within the body of iName:
for each Method as mName:
write method(name=mName, body="// TODO implement this...")
Basically, the tool I'm searching for would allow me to:
parse files according to their Java structure ("search for interfaces")
search for words contextualized by language elements and types ("variables of type SomeClass", "doStuff() method calls on SomeClass instances")
to run searches with structural context ("within the body of the current result")
easily replace or generate code (with helpers to generate, as above, or functions for replacing, "rename the interface to Foo", "insert the line Blah.Blah()", etc.)
The point is, I don't want to spend a lot of time writing these things, as they are usually throwaway. But sometimes I need something just a little smarter than what grep offers. It wouldn't be too hard to write up a simplistic version of this, but if I'm going to use something like this at all, I'd expect it to be robust.
Any suggestions of a tool/library that will help me accomplish this?
Edit to add some clarification
Python is definitely not necessary; I'll take whatever is that. I merely suggest it incase there are choices.
This is to be used in combination with IDE refactoring; sometimes it just doesn't do everything I want.
In instances where I'm using for code generation (as above), it's for augmenting the output of other code generators. e.g. a library we use outputs a tonne of interfaces, and we need to make standard implementations of each one to mesh it to our codebase.
First, I am not aware of any tool or libraries implemented in Python that specifically designed for refactoring Java code, and a Google search did not give me any leads.
Second, I would posit that writing such a decent tool or library for refactoring Java in Python would be a large task. You would have to implement a Java compiler front-end (lexer/parser, AST builder and type analyser) in Python, then figure out how to integrate this with a program editor. I'm not surprised that nobody has done this ... given that mature alternatives already exist.
Thirdly, doing refactoring without a full analysis of the source code (but uses pattern matching for example) will be incapable of doing complex refactoring, and will is likely to make mistakes in edge cases that the implementor did not think of. I expect that is the level at which the OP is currently operating ...
Given that bleak outlook, what are the alternatives:
One alternative is to use one of the existing Java IDEs (e.g. NetBeans, Eclipse, IDEA. etc) as a refactoring tool. The OP won't be able to extend the capabilities of such a tool in Python code, but the chances are that he won't really need to. I expect that at least one of these IDEs does 95% of what he needs, and (if he is realistic) that should be good enough. Especially when you consider that IDEs have lots of incidental features that help make refactoring easier; e.g. structured editing, undo/redo, incremental compilation, intelligent code completion, intelligent searching, type and call hierarchy views, and so on.
(Aside ... if existing IDEs are not good enough (#WizardOfOdds - only the OP can make that call!!), it would make more sense to try to extend the refactoring capability of an existing IDE than start again in a different implementation language.)
Depending on what he is actually doing, model-driven code generation may be another alternative. For instance, if the refactoring is happening because he is frequently creating and recreating his object model(s), then an alternative is to code the models in some modeling language and generate his code from those models. My tool of choice when doing this kind of thing is Eclipse EMF and related technologies. The EMF technologies include generation of editors, XML serialization, persistence, queries, model to model transformation and so on. I have used EMF to implement and roll out projects with object models consisting of 50 to 100 distinct classes with complex relationships and validation requirements. EMF's support for merging source code edits when you regenerate from an updated model is a key feature.
If you are coding in Java, I strongly recommend that you use NetBeans IDE. It has this kind of refactoring support builtin. Eclipse also supports this kind of thing (although I prefer NetBeans). Both projects are open source, so if you want to see how they perform this refactoring, you can look at their source code.
Java has its fair share of criticism these days but in the area of tooling - it isn't justified.
We are spoiled for choice; Eclipse, Netbeans, Intellij are the big three IDEs. All of them offer excellent levels of searching and Refactoring. Eclipse has the edge on Netbeans I think and Intellij is often ahead of Eclipse
You can also use static analysis tools such as FindBugs, CheckTyle etc to find issues - i.e. excessively long methods and classes, overly complex code.
If you really want to leverage your Python skills - take a look at Jython. Its a Python interpreter written in Java.
Does anybody know of GUIs for generating XMLs? This means the user will not be presented with an IDE with support for XML for him to type XML codes. This would be helpful for non-technical people using the system.
I know this sounds easy, given many libraries that can help in generating XMLs. The issue here is that the schema is really that flexible rather than being straightforward like representing books in a library with their properties.
Imagine HTML, where we can create font tags inside a body, a table, a div, or nested even within itself. The solution is a WYSIWYG application that allows user to generate html codes (XML). However, that is good for XML applied in webpages since they involve visual aspect and design. My application of XML would focus on representing some conceptual and computational definitions, much like sql-like syntax, but more than that.
I'm actually after the approach or previous works done or tried, although having a library/working framework for that would be better. Btw, I'm using Java for this project. Currently, I'm just thinking of presenting element tags where user will be able to drag and drop them and nest them with each other. And perhaps, assist them through forms in inputing values for XML attributes. I'm still hoping if there are better ideas from the community.
Thank you.
I think you need to separate the eventual representation (XML) from the abstraction presented to your users. Is your information presented to the user in tree form? If not, do what is convenient for the users and sweat the XML conversion yourself.
There are many tree-based editors that use "meaningful tiles and icons" instead of XML. For example, look at how Eclipse's plug-in editor does the extension of existing points. You get a tree view and can add properties (typically in a separate group box). But you could write a smarter editor that has everything in the tree.
On the other hand, sometimes the XML representation should really be hidden despite its flexibility. A good example is the plugin.xml for Eclipse-plugins. Look at how the editor for that file looks nothing like XML. It is structured logically for the needs of the user, and the code in the background generates the XML.
I looked for this exact thing a couple of months ago. The only one I found was at http://www.jaxfront.org/pages/. It is Java based.
Note that I ended up going with Actipro Software's SyntaxEditor for .NET WinForms which, although does not give me a GUI, gives the app good IntelliSense-like prompting (derived from an underlying XSD) when editing XML.
The W3C answer to your question is XForms. Unfortunately XForms is not directly supported by browsers, although there is a Mozilla plug-in (show and edit even local files, but only in Mozilla). Many XForms solutions are available, an interesting and free one is XSLTForms (http://sourceforge.net/projects/xsltforms/) which translates XForms into HTML Forms (works with every major browser, but local files can only be shown, not edited due to the limitations of Javascript).
Also take a look on Altova Authentic.
I know it is sometimes hard for non technical people to get familiar with a tool like eclipse, but it comes with very good and easy to use XML editors. Supporting auto-completion, validation, verification. I am not sure if there is a pre configured eclipse derivate which is focused on xml editing, but you could configure such a thing quite easily.
I need to develop some java gui using swing.
A few years ago I did develop a bit with swing.
But it was pretty exhausting, you see, back than there weren't much tools to help you.
But I do believe today it should be easier, there must be tools.
I would like to use some kind of a generator or maybe a utility or even a framework.
I know Eclipse has a few plugins and Netbeans has a nice built in tool. I have also heard good things about Jide framework.
But still, I don't really know any of them.
Is there a tool/Utility/Generator/Framework that you have used and really helped you?
Obviously I would prefer something that is free, but if you know something that is really really good and cost money, that could work too.
Thank you.
Actually the faster way to write Swing frames that I've found so far is to use Groovy SwingBuilder but you have to include groovy's jar inside your project to use it. This is an example taken from their website, it's mainly synctactic sugar but it helps:
def frame = swing.frame(title:'Frame', defaultCloseOperation:JFrame.EXIT_ON_CLOSE, pack:true, show:true) {
vbox {
textlabel = label("Click the button!")
button(
text:'Click Me',
actionPerformed: {
count++
textlabel.text = "Clicked ${count} time(s)."
println "Clicked!"
}
)
widget(sharedPanel())
widget(sharedPanel())
}
}
Otherwise there are some "visual" approach to the problem but they don't let you integrate so quickly with the interface you wrote (for example jvider), NetBeans and Eclipse have some plugins to do the dirty work but as before: you can't integrate so seamlessy.
For quite a few years I've used NetBeans built in "Matisse" form editor. It's got the advantage of being built into the IDE, so that the form editing and code generation is rather seamless. If you're new to Swing it can be a big boost (as long as you continue to use NetBeans as your IDE).
There are some issues, however:
You can't easily move a form to another IDE. The generated code may work, but the form data itself is stored an XML file.
If two more people edit a form at the same time, conflicts can arise in SVN/CVS that are nearly impossible to reconcile. The XML is not really human readable.
In the past I found the form XML file to corrupt itself, which would lead to form generation errors.
The form editor can get a mind of its own sometimes, destroying your arrangement when you do something as simple as resize a control.
In spite of all the above, I've continued to use it as nothing else has seemed appealing to me.
My suggestion would be WindowBuilder Pro. It's a GUI designer that comes as a plugin for the Eclipse IDE.
You can use it to generate Swing, SWT or GWT GUIs and even generate some Eclipse RCP code if you need to. I must say that it works quite well for me. I haven't used it to generate any Swing code, though, as I prefer to work with SWT instead.
In terms of GUI Builders, NetBeans and IDEA (now going open source with the 9.0 Beta) both have free GUI Builders.
GUI Builders have all the kinds of downsides that Jason spoke to. If you want good control over what is going on, but still want something sane to write a complex GUI by hand, check out MigLayout.
Eclipse's Visual Swing is a promising upstart. It isn't the most stable thing in the world, but it does all the form stuff in code, so there are no separate files which are hard to read and merge in source control. When you first try it, it takes some getting used to. But once you learn to work around the bugs you pretty rapidly develop Swing GUIs.
I would go w/ matisse if you wnat to use a gui builder, and there are shortcomings as Jason mentioned, but you also need to include a jar file that is used by the matisse layouts, this may or may not be a problem.
But if you are going to be developming UI's in swing, you will soon come to find out most of the gui builders have many shortcomings, and when you have to change something the generated code is not always clear and is bloated. You will also find that once you become proficient you can write a ui much faster by hand than the gui builder, and you will really understand what is going on.
So I say stay away from gui builders, you will create better and more maintainable UI's, and w/ some time and experience will not want to use a gui builder. Just start w/ some of the basic Swing tutorials on layout.
May I humbly suggest Metawidget?
It takes a different approach to UI development - removing much of the error-prone, tedious work whilst still retaining the flexibility of traditional toolkits. It integrates with your existing front-end (Swing, in your case) and back-end (Java, I'm guessing), and works at runtime (no code generation).
There's a few short intro videos here:
http://metawidget.org/videos.html
If you get chance to take a look, I'd be most grateful for your feedback.
Regards,
Richard.
You can avoid GUI builders generated code by using ReflectionUI.
Advantages: you instantly generate your GUI and then you customize it visually (or with few code if you need something very specific).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What mechanism do you prefer for building a GUI: from scratch or using GUI-building software?
If the question is about GUI development using Swing then IMO it is best to code everything manually without a WYSIWIG tool.
In order for a manual UI design/coding to be efficient a really good layout manager should be used. MigLayout is one of such layout managers. Since I've started using it I have never looked back at WYSIWIG tools -- a sheet of paper, a pencil, MigLayout and you get a full control over your design and code.
Also tools like Balsamiq simplify making GUI mock ups for quick prototyping if the paper and pencil approach is not suitable.
My personal opinion is never use visual editors. Until there is a single standard for GUI-building in Java you will find yourself tied to an IDE. The best IDE for building Java GUI has switched around quite a bit in the last 10 years (I wonder how many projects were hit by a massive maintenance overhead from switching away from JBuilder for example).
For most applications, the actual layout of GUI code is probably something like 5-10% of the total amount of time you are likely to spend writing the app as a whole. Therefore even halving this by using a designer is not really saving you very much in the grand scheme of things.
Taking this together with the lack of flexibility and more complicated maintenance, it's almost always better just to write the GUI by hand.
I actually enjoy building GUIs with the NetBeans GUI Builder; the thing is, it is fairly customizable - it allows you to change the code used for auto-generation and the auto-generated code [no pun intended] (which is necessary for custom components), it also allows "easy" event-handling and binding. And NetBeans GUI Builder is not restricted to GroupLayout but rather allows you to choose which LayoutManager to use (a somewhat hidden setting in the form's properties dialog).
But it is not always the best choice; as others already said: MiG Layout is a good choice when you need to have full control of your application, knowing every single JLabel, every JButton etc.
I must confess I prefer Netbeans' GUI builder for the ease of use and WYSIWYG view.
But I also think that it does not even matter if you have created the GUI-Code by hand or with a GUI-Designer; adding Controls / custom Components dynamically works with both, doing this and that works with both etc.. The only thing that matters is that it works.
(From my point of view I do not see a point in coding a GUI manually if it can be done faster with a GUI-Builder, as I do not see why one should bother coding it by hand without some kind of benefit)
I use GUI builders to rapidly prototype designs and stuff like that. But when it comes down to building the actual production GUI, I code it from scratch. I'm not morally opposed to GUI builders, but I prefer the greater control over my code I get from writing it by hand.
Like any code generator tool, IMHO, you shouldn't use a GUI builder until you at least understand the concept - in this case, the Swing layout managers are particularly tricky.
If you give me the choice between NetBeans and by-Hand I'd definitely choose by-Hand. I was never really convinced by the NetBeans GUI builder's approach. At least the last time I used it, it relied on some proprietary sidecar files...
Look at Visual Editor for for Eclipse
You will still want to understand what the editor is doing for you.
You need to know how Swing works to be able to make things work properly. Nothing like building by hand to learn that :)
THEN the Netbeans GUI builder is rather nice.
Edit: I would strongly recommend going through the Java Tutorial Swing Trail - http://java.sun.com/docs/books/tutorial/ui/index.html
Both - use a WYSIWYG editor to get the ball rolling, but at the end of the day you'll need to manipulate your controls and in some cases create them programmatically at run time. Eclipse has a variety of free editors as plugins. Go to eclipse.org and look through the plugins listing.
Depends on your requirements. Some GUI building software work really well with simple applications, however, if your client requires many custom components the third party GUI builders may not work.
Also, it depends on the amount of forms and the complexity of them. If you need to build a form for each table in the database, for example, a third party GUI builder may be faster and cheaper.
In my experience, it really varies from project to project.
If you want a complex gui, then use something like netbeans to build it and create all of the events. If you're looking for a fairly simplistic gui, then building one by hand is still an option.
My company uses Netbeans for GUIs and eclipse for the regular programming.
We have looked but we haven't found any other (free or at least cheap) tool that does GUIs as good as NetBeans.
I used to write them from scratch with a plain text editor...
That depends what the reasons you're making the UI for,
I found that there are two reasons to make UI:
First is for clients, in these cases you want to UI to be polished and to handle really well in projects like this the core or essence of the project is the UI itself.In these cases it's usually the best to hand-craft the code for your UI because it's probably non-trivial code.
Second reason is usually quick & dirty UI where the core of the program is something else and the UI is created usually for Control aspects on your main application and you are the main client. In these cases the best thing to do is make the UI as quickly as possible as you don't want to "waste" time working on it and its more legitimate to use WYSIWYG editors.
I always find a GUI builder to be a good idea to begin with and then I end up in a situation where I am wasting my time fixing things to my own ways rather than that of the IDE and making them actually suit. And don't get me started on the messy code that GUI builders generate! Hence, it's often more efficient to build from scratch; at least for me...
I prefer hand coding the GUI myself so I can have complete control. For complex layouts I will use JGoodies Form Layout. Their syntax for specifying the layout makes it easy to draw the GUI on paper then transfer this to code.
I tried the Netbeans GUI builder and was impressed by how easy it was to use. Then I looked at the code it generated using GroupLayout and decided that by going that way you were basically locking yourself into Netbeans which was something I did not want to do.
I started by coding it manually using Swing. Now I use WYSIWYG editors, but I think it's important to know what's behind the editor. Also you might need to update the code manually, WYSIWYG editors often can't do exactly what you want.
Having created Java GUI's extensively, I can assure you the process is quite often painful. I'm well aware that Java's strength does not lie in it's GUI, but I'm surprised that a decent free interface builder tool hasn't been released.
Sometimes I'll use Eclipse's Visual Builder tool for quick and dirty mock-ups. It's code generation is a bit scary IMHO. I believe Netbean's Visual Editor is the best available at the moment (for free anyway); however, I find myself hand rolling GUI code for consistent cross-platform layouts. If your disapointed with these free GUI editors (like me), quite honestly, just use a layout library (like MIG) and just do it yourself. It'll be slow at first, but you'll have a lot more control and less editor newonses.
It really does depend on what you are trying to accomplish with the GUI. When I was tossing together ideas for a Computer Science class and testing functionality, the Netbeans WYSIWYG editor was great since it automatically generates a lot of the code for you. However, I found you tend to get better control with doing it by hand (in Java) than learning Netbeans.
I tried to use Eclipse's Visual Swing plugin, but on some occasions, the code it generated just disappeared, and I was left with a screen full of errors. In all the GUI apps I write, I use Netbeans, even though I hate the code generated when using GroupLayout. However, if layout code is not your concern, I think you'll be very pleased with the development speed it offers you. The only thing you'll have to do is implement the event logic and other logic you may require.
Eclipse's Visual Editor is a great choice, because the code that it generates is very straightforward and there's no hidden magic. Plus, you can make changes by hand and the editor will reflect them.
I test-drive the model of the UI, so that I have the functionality of the UI enclosed in a class that is completely decoupled from the GUI library and can be easily tested in isolation. Then I create a thin wrapper layer on top of the model, so that the GUI's event handlers are mostly one-liners that delegate to the UI model.
I've been using mostly IntelliJ IDEA's GUI builder (using the JGoodies Forms layout manager). It has been quite handly for laying out components in a static layout. But I think that for example with MiGLayout it's quite easy to write the GUI layout code by hand, so a GUI builder is not necessarily needed, and it helps to avoid tool lock-in. And dynamic layouts will anyways need to be written by hand.
But before writing any code, I first design and test a paper prototype of the UI, so as to have a clear vision of what needs to be done.
If you aim to create the final Java GUI, I recommand the Eclipse plugin named "Jigloo GUI Builder", which can generate clean and maintainable Java code.
If you just want to create the GUI quickly for review, you can try the UI prototyping tool like "ForeUI".
There's nothing wrong with using a GUI Designer when :
You understand what the IDE does and what it generates, how to customize the IDE output
You understand the code actually generated by IDE
Understanding at least the basics of Swing is important. Imagine the following scenario which happens just too often.
Q:"I have 10 years of experience writing swing applications"
A:ok
Q:How would you debug this code
A:Oh wait, there's no Netbeans form file??? You guys are not high tech!
Q:Hum.. you don't understand it?
A:Of course not, it's like machine code, you need to refractor it all and use an IDE!
I find that GUI builders can often complicate things and I'd rather know what was going on when the GUI was built than just use the variables created. I think because I don't know everything about Swing and layout managers as well, I am afraid to generate code that I have no conception of or don't know truly how it works.
When I was doing simple scripting using AutoIt that I knew would only be used on machines that had big enough screens I would use the GUI form editor. However, with commercial applications and those which may run on machines with any specifications I would generally shy away from GUI builders.
That said I think my decision may be influenced by my lack of knowledge regarding layout managers and maybe in the future I will start to embrace them more, as I can see nothing wrong with using them when you have a full understanding. Unlike some programmers may state, it is only a lazy way of building a GUI if you use the software with lazy intentions, and not for efficiently as the applications were written for.
To answer the original question directly, 99.5% of the time I will write the GUI from scratch!
Between Eclipse/SWT or Netbeans/Matisse, what does either Java GUI editor give you in terms of rapid development and maintainability?
You are really asking two different questions: SWT vs Swing, and Eclipse GUI Editor vs Netbeans GUI Editor (Matisse).
First, the difference between SWT and Swing is that they are two fundamentally different GUI libraries. This akin to asking the difference between Tk and Win32, or Java Swing vs .NET Forms (not to say that SWT is .NET). There are a lot of discussions out there discussing SWT vs Swing--I don't know enough about SWT to summarize the differences.
First, let me say my bias is in favor of Netbeans and I have spent 10 years learning the IDE from its days as Forte.
As far as the GUI editor, Eclipse and Netbeans have functionally similar products, but implement the code in very different ways.
My observation is that Matisse behaves, functions, and produces code that's reminiscent of Visual Studio .NET code. There are clear initialziation sections and custom behaviors for certain objects (such as the JTable). You can "Customize" an object and add your own arbitrary code via the GUI editor very easily for everything from initialization to setting individual properties. For event handling, it defaults to replicating "delegates" in .NET by using anonymous inner classes and invoking a stand-alone method. The GUI editor itself provides detailed access to the form object model and has a rich set of customizations. You also have the freedom to drop non-GUI beans into the form for use by GUI components, such as models (tablemodel, listmodel, etc), JPA-related objects, Workers, etc. What used to take a week to produce with hand-coded SWING takes a day with Matisse (though you have to really learn Matisse to do this). If you've been hand-coding swing for many years, then relearning to use a GUI editor effectively is going to be a long, hard lession.
The code is highly maintainable from within Matisse; it is NOT intended to be edited outside of Matisse, but the code is suitable for editing if you needed to (many folks I know use Netbeans GUI and then copy the source into Eclipse).
The Eclipse GUI editor is a very different creature. The GUI editor(s) are roughly the same in terms of overall capability, but I have found them to be less polished. The layout capabilities are about equal, though errors are a bit less forgiving at times. Some customizations required me to go to the source file and edit the file directly, rather than getting access to code customizations through the GUI. The code produced is very different than Matisse. GUI Components are added and initialized through "getters" and is scattered throughout the file; this good because each component is isolated/grouped into a single function, but troublesome when you need to diagnose bad interactions between component initialization. The same goes with the event handlers--very different than matisse.
Eclipse also did not provide any protections from me editing/breaking/tampering with the produced GUI file where as Netbeans was almost obnoxious with its protections. As far as maintainability, the Eclipse code is probably a little closer to the way a human would produce Java code... personally, I find the code it produces harder to maintain, but I've been looking at Matisse generated code since the first beta so my opinion is hardly objective on this issue.
Netbeans also has the capability of using the same editor for building Swing framework applications, Netbeans RCP, etc... I am unsure if Eclipse does the same.
This is definitely subjective -- we use both, Eclipse and Netbeans. I think it comes down to a matter of preference.
No one can tell you which is better. This is completely subject to change per developer. Here's a google search for "Eclipse vs Netbeans" and you can look at some pros and cons which others have poured their thoughts into already. Eclipse vs. NetBeans
I think you should put more research into whether you want the resulting application to be SWT or Swing-based. Which IDE to use should be the least important factor.
I'm personally an Eclipse user, but I heard very good things about Matisse, so I would probably consider it if I had to build a Swing UI. BTW, if you buy MyEclipse, it integrates Matisse.
Some may contend that the end product you want to use actually depends on how easy it is to use - which is hinted at in the question.
This article suggests that the Netbeans/Matisse editor is easier to use - and so you should use it on your projects.
http://cld.blog-city.com/netbeans_matisse_versus_eclipses_visual_editor__no_contest.htm