Discussions

News: Codeguide 7: Back-in-time debugging becomes mainstream

  1. Last week, Omnicore released Codeguide 7.0. This latest version of their IDE integrates advanced debugging features as back-in-time debugging into a convenient and full-featured development tool.
    "Imagine using a debugger to step through some code looking for a bug. Suddenly you find out that the bug must have been caused by a method invocation you just stepped over. To investigate the bug you would need to go back in time and step into the method.

    Conventional debuggers do not allow that. CodeGuide 7 does.
    You can step back, step into the method and investigate what
    exactly caused the problem."
    It seems that this technology comes from earlier research projects such as Lambda. It's nice to see experiments like this finally end up in commercial and polished applications.

    Other features of CodeGuide 7 include:

    * Full support for all Java 1.5 language features
    * "Compatibility compilation" to develop and deploy Java 1.5
    programs on Java 1.4 VMs
    * JSP debugging (with Tomcat 5)

    More information about it can be found at http://www.omnicore.com

    Threaded Messages (16)

  2. I've used CodeGuide for a while now and I think it's quite nice. Especially for the backwards compatible Java 1.5 features. I've been using that FOREVER waiting for everyone to catch up. Omnicore is also very good to their users. They have a public bugtracker and are very responsive. All in all, it's one of, if not the best Java IDEs I've used.
  3. Support for JDK1.4[ Go to top ]

    I've used CodeGuide for a while now and I think it's quite nice. Especially for the backwards compatible Java 1.5 features.
    You do know that you can't legally deploy your code if you're using their "backwards compatibility feature", right? CodeGuide uses the JSR14 prototype to provide "backwards compatibility" - http://forum.java.sun.com/thread.jsp?forum=316&thread=503547&tstart=0&trange=15

    I'd love to see support for 1.4 targets in IDEs, but what CodeGuide is doing is wrong.
     
    God bless,
    -Toby Reyelts
  4. Correction[ Go to top ]

    This is not true. CodeGuide does not require the JSR 14 prototype for backwards compilation. It just needs generic type information that it can compile against. This information can be provided by JDK 1.5.0beta or the JSR 14 prototype. But in contrast to the .class files compiled with JSR 14 prototype javac .class files compiled with CodeGuide do not require gjc-rt.jar or anything else from the JSR 14 prototype in the classpath or boot classpath. Thus there is no legal obstacle to deployment.

    In fact the generated .class files are probably quite similar to those generated by Retroweaver. We have supported this way of compilation (including support for enums) since summer last year.


    Best regards,

    Hans
    --
    Omnicore Software
  5. Correction[ Go to top ]

    In fact the generated .class files are probably quite similar to those generated by Retroweaver. We have supported this way of compilation (including support for enums) since summer last year.Best regards,Hans--Omnicore Software

    Hi Hans,

    Thank you for posting some clarification on this issue. Your website is very light on details. In case you didn't read the link, I was basing my post on this information from Neal:
    Read the CodeGude docs. They just allow you to use the jsr14 prototype. That's all.
    I did read the documentation from your IDE, and it says:
    If you want to use the generic collection API you have to download the prototype implementation of javac for generic types. The prototype implementation can be downloaded from http://developer.java.sun.com/developer/earlyAccess/adding_generics/. After downloading and unpacking you have to adjust the Path to this package in the Integration section of the Preferences Dialog.
    I'm still a little confused about exactly what CodeGuide is doing. I hope you won't mind answering some questions for me. You said,
    This information can be provided by JDK 1.5.0beta or the JSR 14 prototype.
    Your IDE documentation states that you must have the JSR14 prototype. Perhaps you're saying that you can use JDK1.5, but only when you're targetting the 1.5 VM - or maybe your documentation is just out of date? What happens if the type signatures of the prototype differ from the 1.5 JDK? What happens if you want to continue to target 1.4, but the prototype is no longer available?

    What features of 1.5 do you support in 1.4? How do you handle serialization for enums? How do you handle enums? (For example, you can't subclass from java.lang.Enum) How do you handle annotations?

    It seems like there would be problems with providing support for 1.5 without a runtime library. For example, how do you do efficiently autobox small values? How do you efficiently handle class literals? How can you have a common base class for all enums?

    I'm glad to see that you really are supporting 1.4, without the prototype compiler, and I'm sorry that there has been some misunderstanding. Hopefully, you can clear all of it up. It would be nice if this information was posted to your website, so others could also see it.

    God bless,
    -Toby Reyelts
  6. Correction[ Go to top ]

    Our documentation is a bit outdated. Sorry about that. The most recent documentation for compatibility compilation (currently incomplete as well) is available here: http://www.omnicore.com/newlanguage.htm
    Neal Gafter: Read the CodeGude docs. They just allow you to use the jsr14 prototype. That's all.
    This is not correct. The JSR 14 prototype is no longer required since the JDK 1.5.0 was released. CodeGuide never used the prototype's javac compiler either. Instead it includes an incremental compiler which can either use JDK 1.5.0 to compile against or the prototype's classes.zip and gjc-rt.jar. The support for the JSR 14 prototype is provided for Mac OS X where no JDK 1.5 is available and is likely to be retired when JDK 1.5 is released for Mac OS X.

    I will happily answer all your questions about compatibility compilation and put more information on our website and into the documentation afterwards. Most of the questions can probably be answered by saying that CodeGuide's incremental compiler really does support "-source 1.5 -target 1.4" in a way similar to Retroweaver.
    How do you handle serialization for enums? How do you handle enums? (For example, you can't subclass from java.lang.Enum)

    How do you handle annotations?It seems like there would be problems with providing support for 1.5 without a runtime library. For example, how do you do efficiently autobox small values? How do you efficiently handle class literals? How can you have a common base class for all enums?I'm glad to see that you really are supporting 1.4, without the prototype compiler, and I'm sorry that there has been some misunderstanding. Hopefully, you can clear all of it up.
    I will try. ;-)

    The following statements apply to compatibility compilation only. When using "-target 1.5" CodeGuide produces code quite similar to JDK 1.5 javac.

    Enums: Codeguide generates a synthetic Enum class from which all enums compiled with compatibility compilation inherit. We have not tested serialization of enums and make no guarantee that it works on JDK 1.4 or that it is compatible with JDK 1.5 but it might just work.

    Annotations: Since annotations just compile to attributes in the .class files there is no problem writing them with compatibility compilation.

    Efficient autoboxing/.class literal: No optimization are done in compatibility compilation mode to make those efficient. But at least autoboxing could be enhanced. If you joined the CodeGuide preview earlier and pointed us to that we might have implemented it. ;-)

    The main caveat of backwards compilation is that libraries compiled with it can not be used with JDK 1.5 javac.

    If you want to play with CodeGuide's compiler without using the IDE you can try the standalone version (called cgjavac) which is included in the CodeGuide package. The commandline options are compatible with javac.

    All in all compatibility compilation is meant as a pragmatic way to allow using 1.5 language features with 1.4 VMs until JDK 1.5.0fcs is available on all platforms.


    -- Hans
  7. Correction[ Go to top ]

    Hans,

    Thanks for the info.

    I can't seem to find it here, but I thought that someone had said that CodeGuide doesn't require users to deploy a runtime library to use -source 1.5 -target 1.4. Perhaps I misunderstood them or some documentation I was reading... In any case, I now see that CodeGuide does indeed generate enum and iterable classes (in other words, a runtime library) which must be deployed with your other classes. That clarifies questions I had concerning your enum support.
    No optimization are done in compatibility compilation mode to make those efficient. But at least autoboxing could be enhanced. If you joined the CodeGuide preview earlier and pointed us to that we might have implemented it. ;-)
    You still can. :) In regards to autoboxing efficiency, I would suggest you re-review the boxing spec.

    <blcokquote>The main caveat of backwards compilation is that libraries compiled with it can not be used with JDK 1.5 javac.I can't see why anybody would want to release a 1.4 library when they're trying to target 1.5, but why does this restriction exist? The 1.5 compiler should see the 1.4 library like any other 1.4 library.
    All in all compatibility compilation is meant as a pragmatic way to allow using 1.5 language features with 1.4 VMs until JDK 1.5.0fcs is available on all platforms.
    Retroweaver is intended for use for as long as people are unable to migrate off of the 1.4 platform - maybe their application server doesn't support 1.5, maybe their customers only have 1.4 VMs, etc... These cases are quite common. For example, I've had several queries from people asking if Retroweaver also supports 1.3 VMs. (The answer is, yes).

    God bless,
    -Toby Reyelts
  8. Preview functionality[ Go to top ]

    Can TSS please get some preview functionality?

    God bless,
    -Toby Reyelts
  9. Correction[ Go to top ]

    You still can. :) In regards to autoboxing efficiency, I would suggest you re-review the boxing spec.
    Considering that Sun's J2SDK 1.5.0beta1 behaves similarly and that the spec is not yet final we think that creating new primitive wrapper instances when boxing is OK for now. Currently it is not even possible at all to implement a working Java 1.5 compiler (and especially compatibility compilation) while strictly following the JSR-14/JSR-201 specs. But we will look this issue again when Sun's J2SDK 1.5.0 is in RC state at the latest.
    I can't see why anybody would want to release a 1.4 library when they're trying to target 1.5, but why does this restriction exist? The 1.5 compiler should see the 1.4 library like any other 1.4 library.
    You are correct in that it works fine in most cases. Only enum and Iterable support does not work since enums and custom Iterables with compatibility compilation derive from java$lang$Enum and java$lang$Iterable. Therefore they can not be properly used in the API with JDK 1.5.0 javac.


    Best regards,


    Hans
  10. Correction[ Go to top ]

    Considering that Sun's J2SDK 1.5.0beta1 behaves similarly and that the spec is not yet final we think that creating new primitive wrapper instances when boxing is OK for now.

    Sure, I know what you mean. For example, the boxing spec seems to have a bug in the range of values it says you should cache. Anyway, my point was that the caching behavior has already been dictated in a specification - you don't need me to describe it to you.

    God bless,
    -Toby Reyelts
  11. I tried Codeguide 7 for a while (evaluation) and what I really like is that it is so lightweighted if you compares it with eg. Idea. I successfully started last build of Codeguide on JDK 1.5 beta, Tiger's support is really great. But it is really light IDE. I had to create my own tools as Compile file, Run file, etc (great for experiments). Maybe I missed something, but what I miss most on Codeguide are things like support for more ant files, more flexible code completion (again Idea's Basic completion is powerful - or just does more often what I want)... But... finally I have to say, that for 6M (or so) package it's a really great stuff.
  12. CodeGuide has an integrated incremental compiler and support for starting the VM so you were probably missing all the good stuff. ;-)

    Actually the only requirements for using the incremental compiler and starting points is that a project needs to be created. Thus creating a project using one of the templates or the "Import existing" function should be the first step when evaluating CodeGuide.


    -- Hans
  13. plugin for Eclipse[ Go to top ]

    Are there any plans to develop and sell "back-in-time debug" plugin for Eclipse?
  14. CodeGuide[ Go to top ]

    Just tried CodeGuide. Neat, but when I set the project source and build folder to the same directory, and attempted a Clean build, it deleted all my sources :-( Be careful with the Clean build functionality.

    The "Build automatically on source modification" feature could be easier to set up.

    Still, it is the only Java IDE with full 1.5 support -- congrats on that.
  15. CodeGuide[ Go to top ]

    Neat, but when I set the project source and build folder to the same directory, and attempted a Clean build, it deleted all my sources

    If you want to compile sourcecode into the same directory please leave the Destination field empty. CodeGuide actually warns when doing a clean build that everything in the destination directories will be deleted.

    Nevertheless this behavior is clearly way to aggressive and will be changed in the next maintenance build. Bug tracker reference:

    http://jira.omnicore.com/secure/ViewIssue.jspa?key=CG-547


    -- Hans
  16. How practical is this?[ Go to top ]

    Ok, so a method that I have just stepped over had the bug. But
    - I committed a transaction. Will codeguide undo the transaction?
    - I wrote stuff to a file
    - I sent packets over a network
  17. How practical is this?[ Go to top ]

    Ok, so a method that I have just stepped over had the bug. But- I committed a transaction. Will codeguide undo the transaction?- I wrote stuff to a file- I sent packets over a network
    No, CodeGuide will not undo anything. It will just replay what happened. Here is an example why this is useful: An exception occurs in the program. When debugging it with CodeGuide you can just set a breakpoint on the exception handler and then use step back to find out what exactly caused the problem. Or imagine stepping through some code and accidently stepping over the method which caused faulty behavior. With CodeGuide you can step back and step into the missed method.

    I hope this clears things up.


    -- Hans