Answers in this category:
How do I uninstall JBuilder 6?
On Mac OS X: Unable to open '/Applications/JBuilder6/JBuilder.framework/bin/jbuilder.config
MobileSet 1.03 won't install on JBuilder6.
I don't like the modal behavior of JBuilder's online help. How can I launch it as a separate process from the IDE?
I'm trying to install JBuilder 6. I can't launch JBuilder to enter my key because it dies with an error message that says "Unknown license file format." How can I get past this?
Can JBuilder6 integrate with Oracle 9iAS?
I've upgraded from JB5 to JB6. I'm trying to start Appserver 5.0 with JB6 and I'm getting an error: "Exiting! Could not find a valid product license."
I have both JBuilder5 and JBuilder6 on my machine. MobileSet is installed and running on JB5, but I installed it for JB6, it won't activate.
I have some JUnit test cases for an application. When I pull up the test's context menu, JBuilder doesn't offer the 'run test' or 'debug test' items. Tests I create with the New Test wizard do get these items, so why don't mine?
JB6's CVS Checkin/Checkout isn't updating jpx files. Is this a bug, or a feature?
How do I use JBuilder to migrate EJB 1.1 beans to EJB 2.0?
I want to use JNDI naming in Tomcat4, but JBuilder 6 turns it off. How can I turn naming back on?
There's an uproar on ShashDot about a new 'right to audit' clause in the JB6 license. What's up with that?
I'm having trouble with JBuilder 6's new build process. Is there anything I can try?
IDE stops accepting keyboard input in JB6 linux & windoze
Why is Borland imposing a 'no spaces in install path' rule on users? It's not necessary!
The JavaDoc Wizard fails when I try to document projects using the assert keyword.
Do I have to install Borland Enterprise Server to use JBuilder 6's Enterprise features?
I'm trying to install MobileSet 2.0 on my Windows Machine. I have JDK 1.4 installed.
I'm trying to install both JBuilder 6 and MobileSet 2.0 on my machine, but the MobileSet installer is failing.
I'm trying to create a GUI with the Designer, and my GUI uses JDK 1.4's new logging api. When I try to open the GUI in the designer, I get a class java.lang.SecurityException Prohibited package name: java.util.logging exception.
I want to provide an overview section in my project's JavaDoc, but I can't figure out where to put the html file where the JavaDoc wizard can find it.
License corrupt
JBuilder 6 doesn't work with my duo or multiple monitor display.
Why I can't uninstall Jbuilder 6?
How do I access a bean within a bean
JBuilder6 and MobileSet 2.0: The palette is not properly set up on a Non-English version of JBuilder

  http://community.borland.com/article/0,1410,28127,00.html

JBuilder 6 Enterprise on Linux has an UninstallEnterprise directory which contains an uninstaller tool. See also the JBuilder 6 release notes in file JBuilder6/release_notes.html, or under Help | Release Notes, under the section "Uninstalling JBuilder 6."

2001-Dec-18 12:11pm gyles19@visi.com

Rohan Lloyd writes:

Since UFS is case sensitive (unlike HFS+ which is only case preserving) it fails to find the file. This would work fine if I installed it on an HFS+ partition.

Simple fix is to create a symbolic ink:

  ln -s JBuilder.config jbuilder.config

Eric Trepanier writes:
You could also correct the bug by editing the file

  /Applications/JBuilder6/JBuilder.app/MacOS/JBuilder.config 

  include ../../../JBuilder.framework/bin/jbuilder.config

  include ../../../JBuilder.framework/bin/JBuilder.config

This way, you don't need to create the symlink. Either way is perfectly acceptable though...

2001-Dec-19 8:10am gyles19@visi.com

   http://community.borland.com/article/0,1410,28041,00.html

  #!/bin/bash
  JB="/usr/local/JBuilder6"
  JAVA="$JB/jdk1.3.1/bin/java"
  JBL="$JB/lib"
  JBD="$JB/doc";
  CP="$JBL/dx.jar:$JBL/dt.jar:$JBL/jbuilder.jar:$JBL/help.jar"
  MC="com.borland.primetime.help.viewer.ViewerFrame"

  $JAVA -cp "$CP" $MC $JBD/ jbuilder qs/shortcuts.html

For launching JBuilder3's help, see here:

  http://www.drbob42.com/jbuilder/jbjar047.htm

Since this might be useful for Windows users too, Windows users can use the following Windows batch file version:

-------------------------START OF BATCH SCRIPT------------------------

@echo off

::----------------------------------------------------------------------
:: JBuilder6 Help Startup Batch-file based on Joi Ellis Unix BASH script
::----------------------------------------------------------------------

:: ---------------------------------------------------------------------
:: Before you can run the JBuilder Help, please, specify the location of
:: the directory JBuilder6 is installed on your system.
:: The JBuilder6 supplied JDK will be used to start the JBuilder Help.
:: ---------------------------------------------------------------------

set JBHOME=D:\JBuilder6

:: ---------------------------------------------------------------------
:: If you have correctly set the JBuilder HOME path, then in most cases
:: you will not need to change the settings below.
:: ---------------------------------------------------------------------

set JAVARUNTIME=%JBHOME%\jdk1.3.1\bin\java
set JBLIB=%JBHOME%\lib
set JBDOC=%JBHOME%\doc
set CLASSP=%JBLIB%\dx.jar;%JBLIB%\dt.jar;%JBLIB%\jbuilder.jar;%JBLIB%\help.jar
set MAINCLASS=com.borland.primetime.help.viewer.ViewerFrame
%JAVARUNTIME% -cp "%CLASSP%" %MAINCLASS% %JBDOC%\ jbuilder qs/shortcuts.html

You can run the Help Viewer in a separate VM, so you can access help while in a modal dialog is being displayed.  Add the line of code to the JBuilder.config file located in the JBuilder/bin directory:


  vmparam -Dcom.borland.jbuilder.help.vm=true


If you prefer to not edit JBuilder.config, try placing the line in a failed named lib/ext/help.config instead.

  [user_home]/.borland/borland.lic

On recent versions of Windows, [user_home] is your

  C:\Documents and Settings\[username]

directory. On Unix-like platforms (Linux, Solaris) it's your home directory.
2002-Apr-15 7:19am gyles19@visi.com

It may be downloaded from CodeCentral here:

  http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=17136
  

  http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=17029

The command line for starting up Borland Enterprise Server has changed. If you are working with an older project :

  Project | Project Properties | Servers
  Edit the server definition for Borland Enterprise Server 5.0
  Click [OK]

This will update your current project with the server settings.
2002-Mar-04 3:47pm gyles19@visi.com

The MobileSet add-on looks in the registry to know whether or not to install MobileSet to JB5 (if it exists) or JB6 (if no JB5). You can work around the problem by temporarily editing your registry.

  start|run|regedit
  HKEY_LOCAL_MACHINE | SOFTWARE | Borland | JBuilder |
  rename 5.0 to something else, like 25.0.
  Reinstall MobileSet.
  Rename registry (back to it's original name).

http://community.borland.com/article/0,1410,28218,00.html
2002-Jan-16 9:13am gyles19@visi.com

JUnit's own test runners use reflection to decide what is a test and what is not, and they look for test*() and suite() method signatures, not the class/interface parentage. So, anything which provides a suite() method is treated as a suite(), regardless of the classes it extends or the interfaces it implements.

JBuilderTestRunner demands that a test extend TestCase or Test. (I forget which.) This same logic is used when building the context menus, so only classes which extend the correct parent are viewed as test cases.

I think this is bad design. Even JUnit's own test cases fail to meet JBuilderTestRunner's parentage assumptions, and they don't appear as Tests in the context menu, either.

So, for my own bastard test cases, I just create a main() class in each one that invokes a JUnit Test Runner. I usually use something like this:

  public static void main( String[] argv ) {
    junit.textui.TestRunner.main( new String[]{"com.aravox.cocoa.MainTest"} );
  }

This is the main class from com.aravox.cocoa.MainTest.java. It lets me just use the context menu's Run command from the context menu to run the tests via the text runner. Output goes into the message pane.

2002-Jan-05 10:37am gyles19@visi.com

When you check in/out a project using the obvious Team | Check* items, JBuilder 6 forcibly excludes the jpx files from the checkin. There is now a 'Sync Project Settings' item in the Team Menu which *SELECTIVELY* updates properties in the jpx files. It doesn't just check in jpx files, it picks and chooses information to update and ignores the rest. This selective update crap really wreaks havoc with my own projects, and I filed it as a bug. I was told it was not a bug and working as designed, so wouldn't be fixed.

I've had so much trouble using this that I no longer use the team menu for much at all, I've resorted to a cvs command line tool instead. I configure the project to support cvs for the stuff in the source pane, and I sometime use the project update/diff stuff, but I almost never use checkin/checkout at all now.

2002-Jan-05 10:40am gyles19@visi.com

Try following these steps:

1. Rename any methods in your session beans that may be mistaken for getter/setter methods of any fields in those session beans (otherwise the EJB designer screws up your code - we had one example where the ordering of two lines of code were reversed, with one statement being moved to the line after the return).

2. Recompile project.

3. Take a copy of your project - both for emergencies and because you will need to cut & paste from it later.

4. Use the Deployment descriptor (DD) migration wizard in the app server console to migrate your DDs from J2EE 1.2 to 1.3, saving the generated jar.

5. In your project, delete the existing EJB group (ejbgrp) files.

6. In your project, create a new EJB module.

7. Cut & paste the XML from the deployment descriptors generated by the console migration wizard (see point 4 above) into the "DD source" of your new EJB module.

8. Manually edit the new XML Deployment descriptors to remove any mention of the entity beans (remove everything in the each of the entity tags).

9. Import a database schema into the EJB designer.

10. From the lower left pane in JBuilder, right click on a table and choose 'create new entity bean', overwriting the existing bean in the process (hence the backup in step 3).

11. Use the tools in the EJB designer to set properties, etc for that bean.

12. Cut & paste any code from your original entity beans from the copy of your project that you made in step 3. Be sure to press save on a regular basis - it seems to reduce the chances of JBuilder deleting or rejigging your code.

13. Repeat steps 10-12 for each of the entity beans in your project. This should put the entity beans into your deployment descriptors.

I haven't mentioned BMP beans - I guess you just manually edit the XML of the DD.

Throughout and afterwards, you should be vey wary of the EJB designer changing your code. I look forward to Borland releasing a patch to the EJB designer shortly (an EJB migration wizard would also be useful).

PS: If you have a multiple field primary key, don't change the class from that generated by the EJB designer or it sends its code generator into overdrive - we had it put the same class defintion into the file that it wanted to use 3 times aswell as the code from the primary key class that we had produced ourselves.

2002-Jan-09 8:42am gyles19@visi.com

You can simplify steps 6 and 7 by using the "Create EJB Module From Descriptors" wizard and selecting the converted descriptors.

Another thing to beware of when hand-rolling the XML is that, if you make a mistake that violates the DTD in some way, the EJB designer may still look like it's parsing the files but you'll start to see some really weird behaviour between the designer and the code (code not being generated is the most frequent problem we found).

To determine if the XML is parsing correctly, install JBLogger from http://www.jpmcgrath.net/opentools/jblogger/, start the log, and watch the output as you open the EJB group and move around. It took us a week before we figured out that we had messed up the XML and the JBuilder was NOT reporting any error.

2002-Jan-11 6:35am gyles19@visi.com

  1. Close JBuilder if it is open.
  2. Go to your user home directory (On NT/2000, it's under Documents and Settings)
  3. In the .jbuilder6 directory, edit the user.properties file
  4. Add the line:

  tomcat40;use.naming=1

http://codecentral.borland.com/codecentral/ccweb.exe/listing?id=17777
2002-Apr-11 7:51am gyles19@visi.com

http://community.borland.com/article/0,1410,28243,00.html
2002-Jan-16 10:34am gyles19@visi.com

   vmparam -Duse.old.bmj

Now restart JBuilder and try rebuilding your project. This only works in JBuilder 6.

2002-Jan-17 10:22am gyles19@visi.com

The problem is the huge number of sloppy developers of those third party products who themselves did not consider the problem.

It isn't specifically java related, either, and it's a long-standing issue on unix.

Here's an example... Say I want to contatenate two files into a third and the new file has a space in its name, 'foo bar'. Now say one types it like this:

cat file1 file2 >foo bar

The user's shell (bash, csh, sh, ksh, whatever) is going to look at this and use spaces to separate the parameters, just as Windows and Dos also does.

What will end up happening?

  [joi@artoo /tmp]$ cat file1 file2 >foo bar
  cat: bar: No such file or directory

The shell looked at the command and pull out the redirection first. Since it's using space delimiters, it pulls out ">foo" and decides that's supposed to be the new output file, 'foo'. The command string now looks like:

  cat file1 file2 bar

And there is no file bar. Hence the error message. The correct way for me to write this command is:

  [joi@artoo /tmp]$ cat file1 file2 >"foo bar"

  [joi@artoo /tmp]$ ls -la foo*
  -rw-rw-r--    1 joi      joi             0 Jan 17 08:46 foo
  -rw-rw-r--    1 joi      joi             0 Jan 17 08:48 foo bar

So, if I remember to always surround that filename with quotes, life is good. However, now I want to write a script.... Say I do something like this:

  #!/bin/bash
  f1=$1
  f2=$2
  out=$3
  cat $1 $2 >$3

Now if I call this with

  myscript file1 file2 "foo bar"

The shell that parses this command sees the quotes and says "oh, there's a naughty space, I'll strip those quotes and build a execv command for my child shell" like this (in pseudo-c):

  parms[0]="file1";
  parms[1]="file2";
  parms[2]="foo bar";
  execv("myscript", *parms)

So the child shell runs, and it gets those parameters already parsed, and it's happy. But, that 'foo bar' doesn't have quotes in its data stream, it's just foo bar. So when the script runs, it ends up using those parms exactly as provided, and it builds its final cat command like this:

  cat $f1 $f2 >$out
  cat file1 file2 >foo bar

And we're right back to the same problem.

Now, if I was paranoid, I'd have written my script's cat command like this:

  cat "$f1" "$f2" >"$out"

And then I'd be fine.

The problem is, there are way too many apps out there that aren't this paranoid, and those still break when used with multi-word parameters.

There is more than just the one example already given in this thread. One of the big Application Servers JB supports doesn't support them either, and it's commonly whined about around here as well. It became such a problem that people actually suggested Borland prevent users from installing in space-laden directories, just because it caused so many questions from users with that Application Server package.

The problem isn't Borland arbitrarily deciding spaces were evil just to make your life difficult. This issue have been around for decades, and I think it just became too much of a support headache. I know it comes up often, and its in my FAQ just for that reason.

If all programmers were willing to write the extra 2-3 lines of code to handle space-laden command parameters, everything would be fine. But most programmers, being human, are either lazy or uninformed, and don't write them. Hell, most of the time I don't write them, either! Much of the code I write is for myself, and since I never put spaces in my own filenames, I don't waste my time handling a condition I will never create for myself.

See Also: I installed JBuilder in C:\Program Files, and I'm having trouble with my project's classpath. How can I fix this?
2002-Jan-17 9:16am gyles19@visi.com

See this Bug Parade Item for details:

  http://developer.java.sun.com/developer/bugParade/bugs/4492054.html

No, JB6 EE comes complete with the necessary jars so you only have to install BES if you are going to use it for your application server.

There is a minor complication that the default project setting is BES, so for convenience you should change that default in

  Project | Default Project Properties | Servers 

to whatever your application happens to be. That way when you create a new project, the application server will be already set.
2002-Feb-05 9:20am gyles19@visi.com

2002-Apr-02 6:37am gyles19@visi.com

You can compile and run against 1.4, but the Designer has a number of issues with 1.4, because JBuilder itself runs on a 1.3 VM. One of them is that if your classes use the new logging API's (or any other new java.* packages, I suspect), the 1.3 VM will throw a security exception, because you aren't allowed to load new classes under the java.* hierarchy.

You might be able to fix it using the proxy class technique described in the release notes under "Red Beans," but I suspect that you'll need to temporarily remove any references to the logging package if you want the Designer to run.

You could also try temporarily changing JBuilder's own VM to 1.4, but that causes other problems (especially with the debugger) that are probably worse.
2002-Apr-03 9:30am gyles19@visi.com

I experimented with this. I put an HTML file at the root of my project source directory. I added a

 -overview MySummary.html

in the "additional options" of the Javadoc Wizard (in the Doclet options page). I right-clicked on the Javadoc node in the Project Pane and did a Make. I double-clicked on the index.html node under the Javadoc node.

The index.html page was generated with an "Overview" at the top of the page (next to the normal "Package" and "Class"), and all the HTML pages for the individual classes had an "Overview" hyperlink. At the bottom of the index.html was the actual content of MySummary.html. Looking at the source of index.html, I can see that allclasses-frame.html and overview-summary.html are being shown by index.html in separate frames.

Here is the Sun documentation:

"Specifies that javadoc should retrieve the text for the overview documentation from the "source" file specified by path\filename and place it on the Overview page (overview-summary.html). The path\filename is relative to the -sourcepath. "
"While you can use any name you want for filename and place it anywhere you want for path, a typical thing to do is to name it overview.html and place it in the source tree at the directory that contains the topmost package directories. In this location, no path is needed when documenting packages, since -sourcepath will point to this file."

http://java.sun.com/products/jdk/1.2/docs/tooldocs/win32/javadoc.html

2002-Apr-15 6:54am gyles19@visi.com

Question/Problem:
JB6 does not work with duo monitor.

I added the line vmparam -Dsun.java2d.pmoffscreen=false

in both JBuilder.config and jdk.config for JB6 and it still does not work.

However, JB4 works with my duo monitor set up. What's the work around for
JB6?

Answer:
This isn't a JBuilder issue, it's a JVM issue.  JB4 used IBM's 1.3.0,
but JB6 is using Sun's 1.3.0_02.  I'd check Sun's Bug Parade and see if you
can find a reference to dual monitor bugs.  Perhaps they've been fixed in
a later release of 1.3.0, or in 1.3.1.  Or  you can try running JB6 on
IBM's most recent 1.3.0.

Edit JBuilder6/bin/jdk.config appropriately.  (Make a backup copy, and don't
erase the bundled JVM.)

        at ZeroGhw.a(Unknown Source)
        at com.zerog.ia.uninstaller.UnInstaller.e(Unknown Source)
        at com.zerog.ia.uninstaller.UnInstaller.init(Unknown Source)
        at com.zerog.ia.uninstaller.UnInstaller.main(Unknown Source)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.zerog.lax.LAX.launch(Unknown Source)
        at com.zerog.lax.LAX.main(Unknown Source)