Your Five Favourites Features For 4.0 Follow
What would change your java programmer's life, and how can IDEA make it
With 1110 features requests currently open/submitted in the tracker, the
voting system won't do any good at hinting IDEA people about what we
What does your wish list look like. No, what are the 5 first items on
your wish list?
Don't think too much, don't search : what do you miss today?
(Keep the lists short : no need the replicate the features tracker!)
Please sign in to leave a comment.
>> * Format Code __before__ checking out from cvs
On Thu, 19 Dec 2002 09:01:15 -0500 Jon Steelman <email@example.com> wrote:
>>> * Format Code __before__ checking out from cvs
>> why would you do it?
I understand why one could want to reformat before check in
I understand why one could want to reformat after check out
What I don't understand is why one could want to reformat before check out
anyway, it's obviously a mistake, so I was just kidding :)
>>>> * Format Code __before__ checking out from cvs
>>>why would you do it?
I guess it should instead have been written more like--
Format Code while checking out from cvs
This is number 1 on my list.
I won't touch any web framework/J2EE app server that doesn't have good XDoclet support. That's my first question to vendors (Do you have XDoclet support?). I'd like to use the EJB and Web app support in Idea, but I don't since I'm using XDoclet everywhere.
I'm generating my ejb-jar.xml, jboss.xml, struts-config.xml, web.xml and taglib.tld's with XDoclet in my ant scripts.
I don't maintain any XML (except application.xml) by hand, it's all in my code and ant scripts.
#2 on the list is Maven support. Ant is showing it's limitations. Maven on the other hand is taking the Open Source Java world by storm. It is much easier to write plugins for, has a Jar repository that would be great for developers with multiple apps. It also has a real scripting engine for writing plugins and build scripts (logical operators, etc.) where Ant refuses to even do an if/else. Maven can use any Any task and has a plugin that will generate an Ant build file from the Maven project.xml and build scripts.
#3 is pluggable AOP support. I don't ever want to touch AspectJ, but I want to do AOP everywhere. AspectJ is a bad idea. I write code in Java, not some other language. Rickard Oberg is working on another AOP framework, to be released soon that doesn't involve any new psuedo-Java language and the JBoss guys have implemented another AOP framework in their container. I'm going to be doing AOP all over the place, but AspectJ is not the way I'm doing it.
#4 is performance analysis and better JBoss+Tomcat support. I see these two as related since it deals with integrating with the debug facilites.
#5 is VIM key bindings. I'm sure I'm in a small crowd that wants this, but I'm so much more productive typing in VIM. IDEA's other tools and completion parts (things not related to text editing) are great, but I could double my productivity with VIM support.
I'd have to say overall, I want better integration with many of the Open Source and eXtreme Programming tools and libraries available. I use idea as an editor to help me write code, I manage my build process, testing, code generation and project management with Open Source tools.
I would like to see idea allow me to maintain everything in a non-idea specific way for the following tools: Struts, Ant, Maven, JUnit, Cactus, XDoclet, Middlegen, Jelly, Jakarta Tag Libraries. I know idea has some support for some of these, but I want full support and integration. Help me to use the tools I want better, and don't get in my way. This is what I've always liked about idea, but now my tools are getting more complex and I need idea to help me out more to manage that complexity, without hiding it or getting in my way.
Anyway, that's just my 2c. I'm also assuming that OS X support will be coming and idea will always improve performance and reduce bugs.
Forget Ant, check out Maven
Real scripting, Jar repository, project website/documentation generation, plugins such as ant build file generation and idea project config generation, plugins are more like JSP taglibs, so they're easier to write than Ant tasks. Maven is also more stable and has a better class loader than Ant.
Maven makes programmers happy.
Huh? Letting us users advocate heavily for better XDoclet integration? hehe.
+1 for Jelly Swing.
I'm with you on the Jelly Swing stuff. That would be an awesome way to do a GUI builder. If they integrate Jelly all over the place that should make a lot of features easier. You could have Jelly act as a sort of VBA for idea, then all those guys screaming for stuff that Visual Studio has could get it easily.
My wish list:
1) Project metrics (scoped by package, class, method) -- as plugin
Included in standard metrics are detection/reporting on patterns and anti-patterns, leading to better usage of refactoring tool and resulting project API and code.
2) a smart XSLT editor -- as plugin
3) hot swap debugging
4) A matured, common plugin API or adapters from other plugin APIs to OpenAPI.
I'd like to be able to drop plugins for other IDEs into IDEA.
5) Basic requirements management plugin
The TODO feature is pretty cool. Extend this (don't replace) as a plugin to include basic use case and requirement management and manage separate requirement doc files. This could also factor into some automatic JUnit test generation...or at least stubbing.
Many of my requests are specified as plugins. I like the small footprint of IDEA (compared to NetBeans and TogetherJ) and wish IDEA to stay that way. I see the plugin market as really heating up for the IDEs, and several really robust standard plugins would help IDEA and OpenAPI really make a statement and help push OpenAPI.
2) jsp/html formatting
3) project metrics (scoped by package, class, method)
4) issue tracking
I would like for Ctrl-F12 to work in Ant build files. It should show a
list of build targets.
Alain Ravet wrote:
1. Ability to have multiple windows (not panels) rather than tabs when editing classes. This option (which many developers would want to turn off) would be like the Class Hierarchy Browsers of Smalltalk or VisualAge for Java.
2. Ability to write and execute arbitrary code while debugging. (Again a Smalltalk/VA feature.) This is very productive for programming, as you can watch your program and not only fix your bugs in the program, but execute code to, say reset database connections. Kind of like the current Evaluate expression functionality, but to allow any compilable Java to be run in the middle of running your program.
3. GUI builder that supports cross-platform development. Mac OS X (for one) has a single menu bar, eschews MDI, and has different control keys. The GUI builder should generate truly platform independent code, or allow templates/preferences/refactoring or other ways of supporting these platform differences.
Also, in designing this, please look at environments like VisualBasic or Delphi, which have well regarded GUI builders (whatever other faults they may have)
Smalltalk/VA feature.) This is very productive for programming, as you can
watch your program and not only fix your bugs in the program, but execute
code to, say reset database connections. Kind of like the current Evaluate
expression functionality, but to allow any compilable Java to be run in the
middle of running your program.
Something like that already exists: Run->Evaluate Expression
You can call static methods in classes or instance methods on any variable
The missing thing is reloading changed/recompiled code, but this should be
here soon - 1.4 already has this possibility.
I didn't express myself clearly enough. I would like something that allows you to type a fragment of code that will be executed in the current (this is happening while we are stopped in the debugger, having found a bug) context. The code doesn't exist in any class, because it's not part of the programming -- I wan't to be able to 1) fix my bug, 2) clean up the program's state (reinitialize a couple of variables, reset a connection, etc), 3) continue my execution from some point on the stack picking up the code fix and clean up.
1. ability to change development environment "on fly" (develop ad hoc plug-ins), i.e. smth like this:
- each plug-in may be represented as bean_shell (beanshell.org) script or smth like this
- there should be several predefined variables available to script that, i guess, are availbale thru Open API now
- there should be ability to bind keys to scripts
- scripts should be HEAVILY isolated from core IDE
maybe written above is a crap since i didn't develop plugins for 3.0 since as for me it requires a lot of effort to develop one. i want it to be much more easy. and i also want it to be safe, because now, as for me, it is impossible to use plug-ins since they often crash IDE.
2. integration with JSTL (jakarta.apache.org)
3. integration with maverick (mav.sf.net)
1 ad on.
- of course ability to change script should be integrated to core IDE (with code completion, error highlights, etc. ;))
- changes to scripts should be applied right after save, there should be no need to reload anythig (ide, project or even file being edited)
1 - Ant
The support for Ant is great, but I find that some elements found in Ant 1.5 are not being recognized. Also, even if a project whose build.xml file is in the project root, I still have to manually add the file to the Ant Build list.
2 - XDoclet Integration
I agree with all who want support for XDoclet.
3 - Code Formatting
Already good, but it could use more configurability.
4 - 5 Don't put GUI/Wizard features
A more advanced project concept like the one in Eclipse.
It's really nice to be able to split your code into more projects and set the relations between the code at the prjoect level. This among other things helps us to make sure that our programmers doesn't make references to the UI layer in the BL layer, cause it's simply not possible, cause the BL project doesn't know the UI project at that level, but the UI project knows the BL layer (as it should).
Refactoring should ofcourse work between projects according to the references (so refactoring in the BL layer can change code in the UI layer, since the UI layer project has a refrence to the BL project).
Wow! I just downloaded the IDE and after day of playing around have decided to switch. I've tried the other major ones (NetBeans, Eclipse, JEdit, JBuilder). The reason I tried was the Refactoring ability and I was sold on the easy of use......
I'm in a lot of agreement with functionality others have stated above. It's pretty clear some of the major items people want: better integration with the major open source projects particulary maven (although an industrious person could probably write a good plug-in), aspectJ, ......
I would request a lot of new functionality for client side development (and plugins would be great as long as they were fully integrated when turned on). It sounds like the Java community, at least here, needs to decide if they want to play on the client side or not. I just finished reading an article (http://www.microsoft.com/resources/casestudies/casestudy.asp?Casestudyid=13648) about .NET that most here will discount one way or another. The scary thing is that MSFT will capture a lot more of the market if Java doesn't have a good GUI tool. To that end:
1. Integration with Java Server Faces. Would like my developers to be able to create web pages using a drag/drop interface. If not JSF than at least a smart JSP editor (able to understand taglibs and display pages in a preview mode)
2. An XML editor for creating XSLT/Schemes. Debugging is difficult to say the least in the current world.
3. GUI builder. If Java wants to play in the client space in a meaningful manner, we need an editor as easy to use as VB.
There are a lot of developers out there who are more productive in a drag/drop GUI builder environment and need tools to support them.
>3. GUI builder. If Java wants to play in the client space in a meaningful manner, we need an editor as easy to use as VB.
No. If you need a crowd of ugly JAVA programs like those built by
unexperienced VB or Delphi developers, than you need a GUI builder.
There is no connection between a GUI builder and client applications
Following your logic, there's no connection between IDEs and applications in Java. Notepad is sufficient enough to write code in any programming language. Command prompt is sufficient to execute commands and scripts that build your project. Why do you not refactor by hand? It's only a matter of careful copypaste & searchreplace.
I've seen brilliant Java programs, written in vi. I've seen a plenty of ugly programs written using IDEs (incl. IDEA). There's no such programming language that disallows a programmer to write ugly code. And the ugliness of the resulting code does not depend on whether that programmer is equpped with IDE or not.
I understand that I am in the minority here, but I'm tired of these never-ending claims that "we do not need GUI Builder, because all GUI builders we've previously seen were crap and produced crap". I do desperately need a smart enough GUI designer. I have to work with very large and complex forms, consisting of several dozens of components and subpanels. It's not me who tells how the form must look like, but it's me who needs to layout all components and adapt to constant changes in layout. I don't like doing this all by hand, it's much like refactoring by hand.
So, if we return back to the main topic, smart GUI designer is #1 of "My Five Favourite Features For 4.0".
Maybe I just expressed my opinion not clearly. I meant, that even if
there would be a good GUI designer, it would be hard (maybe even
harder) to create a good GUI.
I do not say, that I'm a GUI expert, but I have some years of
experience in creating Swing-GUI's. When I started to develop in JAVA,
I started with JBuilder and Netbeans. Both have a GUI-builder, but
using it did not helped me in any case creating a good GUI. From my
experience I must say, that a GUI designer diverts you from the real
problem. You tweak here and there some pixels and get very easily lost
in all the options and time.
But I also know, that nearly all self-proclamed reviewers pegged IDEA
as unusable for desktop application development, because it does not
contain a GUI builder. Because you cannot change these people, it
seems to be important for JetBrains to integrate a GUI builder, even
if it does not makes really sense.
Creating a good GUI is a non-trivial task by itself and requires good artistic skills. There were a lot of people who painted pictures, but only few of them created masterpieces.
I currently use JBuilder's GUI designer, because it does a lot work for for me and lets me instantly see the final result without the need to run the app (the app establishes several network and database connections, so the startup time is quite long). I do not like JBuilder's GUI designer, because it is sometimes not "intellectual" enough. But if I had not it at all, I'd spend a lot more time supporting my GUI code.
That's why I am asking for GUI designer in IDEA. I believe that IntelliJ team can do something outstanding here as well.
In general, I think that IDEA is too code-centric. Additional WYSIWIG editing features and visualizations would be extremely helpful. For the hardcore users these features could be implemented as optional plugins.
Jeppe Cramon wrote:
It would be great to be able to enforce the compile time relationships
between various modules. I don't completely like the way eclipse does
this however. The problem is that all projects in eclipse are peers and
need to be in seperate directory structures. There's no way to create a
project of projects as such.
I don't think, "it would be nice". I think, this is a must-have for
This shouldn't be too demanding ;)
1) A standalone DIFF tool. The only one I've seen is the one used w/ the CVS integration.
2) Faster printing. The print jobs produced are enormous in size, hence, take a long time to print. I'm exporting the HTML and printing that way right now but...
3) I'd like more control over my "export to HTML". Pluggable/configurable style sheets. I think green is the current background color...yuk.
4) To be able to select multiple files from the project window or commander and open them all at the same time. Currently, it seems as if I have to open files individually. If I can close them all at a time, I should be able to open many at a time.
5) I'm just learning about AOP, but a pluggable AOP framework would be cool. This may be a larger undertaking, but AOP support in the future would be great. If anything, syntax support for AspectJ would be nice.
IntelliJ is the first editor in a long time that is really worth using. It is the only one I've been willing to actually pay for. Every day I miss the following things though, and I have to open up other editors because of it. Here are 5+1 things worth thinking about for the next version.
1. Full macro support. It would be great if these macros were generated into an in-memory file that could be edited or ultimately saved to disk. BeanShell seems to be a good tool for implementing macros -- jEdit (www.jedit.org) has implemented great macro support with using it.
2. On CVS toolbox, add the ability to flatten the list. I don't want to navigate a bunch of tree views to check in a file. This is another one of those things that emacs does well. Check out the pcl-cvs mode. Given a directory, this tool gives a list of files that are "modified", "out-of-date", "removed", etc and gives you the option to diff, commit, add, remove, or roll back each file.
3. Multiple windows and/or panes viewing the same or different files. That is, I'd like to split a window in two and see a different file in the lower pane. I'd also like to see a different file in another window entirely.
4. Fully document the open api. There are a lot of plugins already that look pretty good, but better documentation seems like it would take the concepts much further. I've tried to stop griping and fix some of these things myself, but the OpenAPI is still lacking a lot of critical documentation.
5. IntelliJ has an excellent diff facility. Please round this off by adding a merge facility, preferably integrated with CVS.
6. CVS Annotate - preferably integrated into the "gutter" of the normal editor.
1. GUI designer
2. More inspections, refactorings
3. More intentions, more code generation, smarter code completion
4. More code formatting options
5. Better external VCS integration
The reason Vincent's explaination doesn't help is because describing aspects is really difficult. Like you, I'm way to busy to read the aspectj documents fully. But I did spend some time reading the AspectJ Programming Guide and tried to use aspects in a project. After a week of groping around in the dark I think I have a reasonable idea of how aspects work. The documentation is particularly confusing because it talks about concepts that don't seem to relate to Java in any way. They mention cross cutting issues and join points, pointcuts and advice. I found myself hopelessly lost.
Think of aspectj as an extension to java that allows you to selectively weave bits of code into existing code. When, where and why the code is woven is defined by a relatively simple but also powerful selection mechanism.
I still don't fully grok aspects but I do think they are a powerful mechanism. Sometime when I find some better documentation and the time to read it properly I'll revisit aspects.