Has SlickEdit abandoned Java?

[crygaard]

Are the folks at SlickEdit abandoning Java?

One one of my projects, I use C++.  For that project, the various SlickEdit features work quite well, including refactoring.

On my other project, I'm using Java extensively.  SlickEdit is becoming a real problem on that project.  (I'm use SlickEdit only because it is so difficult to switch between editors when I switch between projects.)

Examples include:
- Class name completion worked on earlier releases, but no longer works.
- Compilation errors from Java 1.4 and 1.5 are not properly parsed when I press <ctrl><shift><down> or <ctrl><shift><up>.
- The folks at SlickEdit don't even bother with Java refactoring, but they really advertise their C++ refactoring.
- On another thread on this forum, another user pointed out that the Java UI builder has been dumped in V11.

It's pretty clear that they are no longer maintaining Java-specific features, and they are not adding features to support Java.  The only Java features in the editor are those V8.0 features that happen to still work properly.

This is rather frustrating, because I have been faithful to SlickEdit since V1.2, when Borland killed Brief.  Now I'm looking for a different editor that supports both C++ and Java.

Chris

[dsharp]

I'm not sure it's appropriate to mention another editor on this forum, but Netbeans has recently released their C++ language pack, so assuming the C++ language pack meets your needs for C++ development, you could use Netbeans.

Dave

[Dennis]

With respect to the class name completion issue, I encourage your to put together a small (but complete!) example and submit it to support@slickedit.com.  At this time, I am not aware of any existing issues with symbol completion in Java.

[Clark]

next and prev error should work for you.  Make sure you are using Sun's javac and not Eclipse's javac (which I think is Jikes).  The command "javac --version" will tell you what version of the compiler you are using.  I think Eclipse's javac pukes on this command.

Under Linux, I noticed that "/usr/bin/javac" is eclipse's javac which does not give compiler output that slickedit uderstands.  Jikes used to have an option for a different error message format but it seems to have been removed.

[Clark]

The eclipse java compiler is NOT jikes.  It's the JDT compiler which is written in Java.  It's compiler output is like Jikes and is not yet support.  Install any version of Sun's compiler.  You may need to select the "Java Options..." from the "Build" menu and set the JDK installation directory to "/usr/java/jdk1.XXX".  SlickEdit does attempt to use a Sun compiler instead of the one in /usr/bin automatically.

[ScottW, VP of Dev]

Hi Chris,

Thanks for the feedback and the chance to address your concerns. I wasn't able to reproduce the errors you listed. Class name completion works great on all of my projects.  next-error and prev-error work just fine, too. Have you contacted support about these problems? If not, please do so and I'm sure we can help you resolve them.

It's kind of funny, because I get emails like this occasionally from both C++ and Java users, each feeling that the other is receiving more attention. In our release plans we work to make sure each constituent group benefits from new capabilities. Very often, the new capabilities we develop work across languages and are not specific to a single language.

Since version 8, we have developed the following features for Java users:

• v9.0.2 (I think that was the release number) was released specifically to address the new language features in Java 5.0.
• Java GUI Builder, subsequently removed for reasons stated in this thread: http://community.slickedit.com/index.php?topic=109.0. Please don't underestimate the amount of effort that went into that feature. It was a difficult decision to remove it, but it allowed us to put time into features we felt would be more important to our Java customers.
• Organize Imports, added in v10.
• Java Live Errors, also added in v10, we based our implementation on the Jikes library, which has a few bugs and is not keeping up with the language changes in Java 5.0. We're experimenting with using javac to provide the same capabilities.
• JUnit support was added in v10.
• J2ME support was added in v10.
• Updates to the debugger to support Hot Swap was added in v10.
• v10 also included updates to Javascript and JSP support, used heavily in Java projects.
• Quick Refactorings were added to provide support for those who are not using C++ or when our C++ refactoring engine cannot process your codebase. Java was one of our key focuses on this feature.
• Auto-Generation of JavaDoc comments was greatly enhanced in v11.
• Comment Wrapping was introduced in v11, making it very easy to edit JavaDoc comments without concerning yourself with formatting issues.
• Code Templates, introduced in v11, includes extensive samples in Java. Again, Java's unique requirements consumed a great deal of time in this feature.

So, I don't think it's accurate to say that we are not putting effort into Java. It's true that we don't have a full Java refactoring engine, but the Quick Refactorings handle many of the most common operations and I think you are underestimating the complexity involved with developing a full Java Refactoring engine.

RefactorIT, one of the leading commercial Java refactoring tools, sells for $134.44 for the Developer edition, which is limited to projects of 500 files or less. The Enterprise Edition with no project size limitation sells for $400.61.  I think you can see that it would be hard to add a capability like this to SlickEdit, which sells for $284 for electronic distribution, without increasing the price. Though we did that with C++ Refactoring, we are still working to make it reach its full potential.

I hope this posting helps you to understand our Java strategy. We are very interested in continuing to be a great Java editor. Even lacking a full refactoring capability, I think you'll find that you can write code faster with SlickEdit than any of our competitors. If you've got ideas for additional Java features, I'd love to hear them.

--Scott

[buggyfunbunny]

I too find that error processing doesn't work:  win2K, 11.0.1, jdk1.4.2._11 & 1.5.X.  I remember it working, always before. 
As to sending any more info into Support, I'm not sure what any of us could send. 

As to java/jsp:  it's never going to work very well.  As explained to me by a (V)SE support person lo
those many years ago (I tried to use it immediately, as I was working with jsp from .9):  SE can keep
track of but two syntaxs (language and embedded language).  The problem is that jsp involves lots more;
html (which counts as a language, though it's not really a programming one), javascript, java, stl, user tags,
xml (and all of its mutants), etc.  In order for any editor to work, it needs a stack of language context, and
resolve tags back up.  A tall order.

It also puzzles me that, given the primacy of OO languages overall, that Defs only carries class members, and
not inherited ones too.  This is a "feature" that seems a no-brainer, but still hasn't happened.  The info is
clearly available, since right-click menu has Show Call Tree:  make those members display in Defs by default,
at user choice.

In general, though, java is a server side language.  Toss AJAX and the Google Toolkit into the mix.  my, my.

On the other hand, SE is seeing the wisdom of Ruby (not all java folks agree, of course.)  Given the choice, I'd
rather the effort go to Ruby/Python/database(of your choice). 

[ScottW, VP of Dev]

When reporting problems, it's best to treat this just like you would a defect in your own system and provide the info you'd like to see if you were working on it. The problem you are seeing is very clear to you, but we can't really work on a problem when all we have is a one line statement of the problem. Most don't even tell us what language they are working with.

We've got someone working on the error processing issue, but so far we can't reproduce it and no one has sent us any details to help us track this down. I've got 11.0.1 installed on Win2k and error processing works great on jdk1.5.0_06 and jdk1.4.2_10.

Here's the info we find useful:
1) Platform
2) Version
3) A description of the problem including the steps you performed and the behavior you observed.
4) If the problem is language-specific or language-related, provide the language you are working in. Which compiler are you using?
5) Did it work in the last version?
6) If you can provide a piece of sample code that reproduces the error, please include that.
7) If the problem is related to output, please include a sample of the output, such as the errors output by the compiler you are using in this case.
If the problem involves any keystrokes, what emulation are you using?
9) Does the problem occur on a default configuration? Copy the contents of your config directory to a safe place and start SlickEdit with an empty config directory. For 11.0.1, you would leave the 11.0.1 directory in place but remove the contents. If you delete the directory, it will create a config directory based on your last version. We want to see what happens in a default config?

Many of these can be answered by selecting Help > About SlickEdit and clicking the "Copy To Clipboard" button. In some cases we may ask you to send in your state file, but don't send that until we ask for it...it's wicked huge.

If you'd like to help us get to the bottom of this one, please send that information to support@slickedit.com.

On your other points, we have Change Requests filed for enhancing the embedded languages and adding inherited members to the Defs tab. I'm not sure I follow what you mean by "Toss AJAX and Google into the mix." Are you saying that this just makes Java a hard language to support?

Thanks for your help!

--Scott

[buggyfunbunny]

>>I'm not sure I follow what you mean by "Toss AJAX and Google into the mix." Are you saying that this just makes Java a hard language to support?

yes.  and let's do a smiley:   

[mrothman]

I've upgraded to 11 and the patch for 11 on both linux and win32 and I haven't seen any degradation of Java capabilities.  I'm working in Java all the time.  And I sure make plenty of errors, so I know that compilation errors are correctly parsed. 

One java capability that's been in for a while and is very useful is the special facilities for JavaDoc editing.  I've noted the improvements that Scott mentioned in v11.  One thing I haven't seen mentioned is that Doxygen (for documenting C++) accepts the JavaDoc syntax, so it's great if you're doing C++ also.

I also turned on comment wrap right away, and I'm thrilled - this has been bugging me for years.

There are some minor quirks in v 11, but overall it seems very cool.  One of my favorite things is that I finally seem to be able to work seemlessly with exactly the same workspace on both linux and win32: that is, if I have a shared network drive, I can just point either version of SlickEdit at a workspace I created with either version of SlickEdit, and it just works, including the project tag file.  I used to have to make a special configuration as part of the workspace to get this to work.

I think I've stuck with SlickEdit these many years because it has a kind of gestalt that's specific to a certain kind of programming.  It's very hands on, oriented towards developers who are working with the language features very closely (as opposed to things which generate templates for you, such as GUI builders, not that they don't have their place elsewhere), and towards multiple-platform / multiple-language work.  I like that it hews to that audience and doesn't try to be everything to everybody.

[pchandra]

I hate to join the chorus of "next/prev errors no longer work in Java", but I just noticed that is the case for me as well after installing the 11.0.1 patch. I can't use the next-error command, nor can I double-click the line in the .process buffer to have it take me to the appropriate line in the source. I am using RIM's compiler (rapc.exe) at the moment to compile for BlackBerry; however, I was using this compiler w/o problems under 11.0 and I believe the error format is pretty standard. Here is what a sample error looks like:

C:\st\DateTime.java:2168: ')' expected
                buffer.append(formatYear(atoms.length());
                                                           ^


-Parag

UPDATE: Just found a suggestion in another thread that seems to fix it for me: run 'reset-next-error' each time you startup SlickEdit. Is there an 'autoexec.bat' sort of macro file that I could put this command into so that it is run for me automatically? Thanks.

[hs2]

Try Project -> Properties -> Open Tab
and just enter the macros ( e.g. reset-next-error ) / shell commands you want to execute each time the project is opened / activated.
Note: These lines are imm. executed when quitting the dialog ('OK') ! I already did a related bug report ...
HS2

[Dan]

UPDATE: Just found a suggestion in another thread that seems to fix it for me: run 'reset-next-error' each time you startup SlickEdit. Is there an 'autoexec.bat' sort of macro file that I could put this command into so that it is run for me automatically? Thanks.

The VSLICK environment variable will be added as an invocation option to the editor.  So setting it to "-#reset-next-error" will do it (I just tested this).  This may be a suitable workaround until we can reproduce/fix this here.

[jph]

I use Java extensively at work and am generally pretty happy with Slickedit.  My biggest complaint at the moment is the lack of support for JDK 1.5 language features in Live Errors.  I really like the idea of Live Errors, and when I work on projects that can't use 1.5, I turn it on, but otherwise I've been forced to leave it off, since it just doesn't work very well for 1.5.  I was really surprised that Slickedit 11 didn't fix that, since JDK 1.5 has been out for several years now.  Worse than not working, it frequently crashes the editor when I have Live Errors turned on, so I have to be very careful.

[ScottW, VP of Dev]

I couldn't agree more. Live Errors is one of those features that is hard to live without once you get used to using it. Unfortunately, writing the kind of Java parser necessary to do this is a bit more than we have time for.

Our implementation is based on Jikes, an open source Java compiler that offers some really interesting capabilities. Unfortunately, Jikes has a few bugs, and it is not keeping up with the language changes in Java. We're experimenting with using the compiler in the JDK to provide the same kind of functionality. If we can get that to work we will be including it in a future release. Using the same compiler for Live Errors that you use to build your code is the best solution for making sure that the information is accurate and keeps pace with future changes in the language.

--Scott