Sorry, the IDE won't make your code better-all it can do is make you more productive. Seriously, this is a very difficult problem in principal for Java, because no two VMs actually exectute the same Java code the exact same way. So, if I'm developing in VisualAge for Java (or JDK for that matter), and the code that I develop is being executed Netscape's (or Internet Explorer's, or Java Plugins)'vm, there could very well be a difference that could cause a problem, or reveal a bug in your code that was not encountered in the development process. No substitute for QA, I'm afraid. No big application is portable in the absolute sense of the word, rather it is a matter of degrees.
My company uses VisualAge almost exclusively for Java development. I happen to like it a lot. Here are some pros and cons: Pros: 1) Object Browser code viewer encourages good object-oriented development. 2) Powerful interactive compiler, which means new code you write is parsed directly into the running application vs haveing to edit-recompile-restart an application to see changes you have made in code. 3) Excellent runtime inspector and debugger - far more advanced than what I have seen from the competition. 4) Scrapbook to execute arbitrary snippets of code easily.
Cons: 1) Uses an old (1.1) JDK (unless this changed in the 3.0 version). Not a big issue for me because I want my Java code to be availible on many different platforms, and "Java 2" apps are restricted to Windows and Solaris (yes, I know there is a beta 1.2 for Linux but we can't require our customers to use beta software, and anyway we need to support Macintosh and several other UNIXes). 2) Object Browser interface will be unfarmiliar to someone who is used to other tools e.g. Visual Studio that present a file based vs object based view of the code. Everyone I know has complained about this at first, and later decided that it is really better this way (but maybe that is because only people who are inclined to liking it continue to use the tool). 3) Very big footprint; requires a fairly powerful computer to run it (I would say *at least* 64 megs of RAM, 96 for a comfortable experience). 4) GUI builder has some bugs in it.
It reads like a "Buffer overrun HOWTO". I was curious to see exactly how this sort of thing can be achived-I had heard about this type of exploit but had never actually seen one. I certainly have to hand it to the guy for the meticulusness (sp?) of his work. This should be manditory reading for all UNIX webmasters, IMHO.
It is not possible to use swing1.1, however the API has not changed much from 1.0.3 which is included. You should try the following (which worked for me):
in VisualAge Java, make a project called "JDK1.2 kluge". In this project, make empty projects called javax.swing and javax.swing.event.
Then, after the import javax.swing.* statements in your code, add a line: import com.sun.java.swing.*
[ditto for the swing.event package]
then try to import the package, and chances are it will work. To compile the same project using JDK1.2, you will have to export from VisualAge (obviously). Again, make dummy packages
com.sun.java.swing and com.sun.java.swing.event
This will allow you to compile the same code base with either VM.
It uses its own VM, because it has to. VisualAge is dynamically compiled, which means that changes to the code are automatically parsed into the running application, rather than save-compile-run like most tools. For this reason, the tool needs to have special hooks in the Java engine.
VisualAge for Java features an interactive compiler, which means that code changes are directly parsed into a running application rather than having to recompile-this is a BIG timesaver. For someone from a C/C++ background, the object browser interface is a little odd at first, but after you get used to it you will think it seems weird to use a file-based interface like most java IDEs.
Lots of other features as well, including the ability to execute arbitrary code snippets on the fly, a powerful versioning system, and so on.
No, I don't work for IBM, I just really dig this tool.
Boise has had a good trial, but he missed the bus here. The difference in modem speeds had nothing to do with how long it takes to connect to the internet. He should have pressed the witness on what programs were being used to configure the connection. I wouldn't be surprised if the PPP-configuration software would still work after the browser-remover program thing had been run.
Slashdot Mirror
...was my response!
:-P
Sorry, the IDE won't make your code better-all it can do is make you more productive.
Seriously, this is a very difficult problem in principal for Java, because no two VMs actually exectute the same Java code the exact same way.
So, if I'm developing in VisualAge for Java (or JDK for that matter), and the code that I develop is being executed Netscape's (or Internet Explorer's, or Java Plugins)'vm, there could very well be a difference that could cause a problem, or reveal a bug in your code that was not encountered in the development process.
No substitute for QA, I'm afraid.
No big application is portable in the absolute sense of the word, rather it is a matter of degrees.
My company uses VisualAge almost exclusively for Java development. I happen to like it a lot. Here are some pros and cons:
Pros:
1) Object Browser code viewer encourages good object-oriented development.
2) Powerful interactive compiler, which means new code you write is parsed directly into the running application vs haveing to edit-recompile-restart an application to see changes you have made in code.
3) Excellent runtime inspector and debugger - far more advanced than what I have seen from the competition.
4) Scrapbook to execute arbitrary snippets of code easily.
Cons:
1) Uses an old (1.1) JDK (unless this changed in the 3.0 version). Not a big issue for me because I want my Java code to be availible on many different platforms, and "Java 2" apps are restricted to Windows and Solaris (yes, I know there is a beta 1.2 for Linux but we can't require our customers to use beta software, and anyway we need to support Macintosh and several other UNIXes).
2) Object Browser interface will be unfarmiliar to someone who is used to other tools e.g. Visual Studio that present a file based vs object based view of the code. Everyone I know has complained about this at first, and later decided that it is really better this way (but maybe that is because only people who are inclined to liking it continue to use the tool).
3) Very big footprint; requires a fairly powerful computer to run it (I would say *at least* 64 megs of RAM, 96 for a comfortable experience).
4) GUI builder has some bugs in it.
hope this helps.
It reads like a "Buffer overrun HOWTO". I was curious to see exactly how this sort of thing can be achived-I had heard about this type of exploit but had never actually seen one. I certainly have to hand it to the guy for the meticulusness (sp?) of his work. This should be manditory reading for all UNIX webmasters, IMHO.
Sun should bundle StarOffice with JDK, and claim that it is "integrated" with java. See how that affects MS Office sales...
;-)
bye-Ben
It is not possible to use swing1.1, however the API has not changed much from 1.0.3 which is included. You should try the following (which worked for me):
in VisualAge Java, make a project called "JDK1.2 kluge". In this project, make empty projects called
javax.swing
and
javax.swing.event.
Then, after the
import javax.swing.*
statements in your code, add a line:
import com.sun.java.swing.*
[ditto for the swing.event package]
then try to import the package, and chances are it will work. To compile the same project using JDK1.2, you will have to export from VisualAge (obviously). Again, make dummy packages
com.sun.java.swing
and
com.sun.java.swing.event
This will allow you to compile the same code base with either VM.
hope this helps.
bye-Ben
It uses its own VM, because it has to. VisualAge is dynamically compiled, which means that changes to the code are automatically parsed into the running application, rather than save-compile-run like most tools. For this reason, the tool needs to have special hooks in the Java engine.
VisualAge for Java features an interactive compiler, which means that code changes are directly parsed into a running application rather than having to recompile-this is a BIG timesaver. For someone from a C/C++ background, the object browser interface is a little odd at first, but after you get used to it you will think it seems weird to use a file-based interface like most java IDEs.
Lots of other features as well, including the ability to execute arbitrary code snippets on the fly, a powerful versioning system, and so on.
No, I don't work for IBM, I just really dig this tool.
Boise has had a good trial, but he missed the bus here. The difference in modem speeds had nothing to do with how long it takes to connect to the internet. He should have pressed the witness on what programs were being used to configure the connection. I wouldn't be surprised if the PPP-configuration software would still work after the browser-remover program thing had been run.