The BlueJ team does not have a privacy policy, because we do not collect any personal information.
BlueJ does collect some non-personal or anonymous information, first, as detailed in the README file:
When you use BlueJ, some anonymous non-personal information (BlueJ version, Java version, Operating System, interface language, etc) is sent to the BlueJ maintainers, to help with development planning. This can be disabled by adding a "bluej.uid=private" setting to your bluej.properties file.
Second, when BlueJ is first started it presents the user to opt-in to a more involved data collection. The user may elect not to opt-in, but even if they do opt-in BlueJ does not collect personal information. A full explanation of what data is collected and answers to related questions can be found in the Blackbox FAQ.
There are no terms of use, except that you must obey the license requirements for redistribution. Specifically, BlueJ is distributed under the GPLv2 with Classpath Exception.
You can call a main method in the same way as you call any static method in Java - by right-clicking on the class in the class diagram, and selecting the method from the pop-up menu.
When you call the main method from a class, you will see a parameter entry field that prompts you for the array of strings that the main method takes as a parameter.
By default, the parameter is
{ }(an empty array, no parameters). If you want to pass, say, three parameters, from a command line you would write
java MyClass one two threeIn BlueJ, you use the following parameter for "main" in the dialog text field:
{ "one", "two", "three" }This passes an array of the three strings, just as the command shell does.
There are two different ways to clear the terminal in BlueJ. You can get BlueJ to automatically clear the terminal before every interactive method call. To do this, activate the 'Clear screen at method call' option in the 'Options' menu of the terminal. You can also clear the terminal programmatically from within your program. Printing a formfeed character (unicode 000C) clears the BlueJ terminal, for example: System.out.print('\u000C');
This will work in the BlueJ terminal, but is not guaranteed to have the same effect in all terminals.
Sometimes, you may want to make your own libraries generally available in the same style as the Java standard libraries. For example, you may have your own package called "simpleIO" that you want to use. Then you may want to be able to write import simpleIO.*; without the need to copy all the simpleIO classes into every project.
There are actually three ways of doing this in BlueJ.
The first way is via the "Preferences" dialog. Open the "Preferences" dialogue and select the "Libraries" tab. Then add the location where your classes are as a library path. Restart BlueJ - done. The selected libraries will now be available in all projects that you open.
One small thing to look out for: if the classes are in a jar file, select the jar file itself as the library. If your classes are in a named package directory structure (for example in a directory named "simpleIO"), choose the directory that contains simpleIO (not the simpleIO directory itself) as the library!
The second way is via the "userlib" directory, found at <bluej-dir>/lib/userlib (that is, inside the "lib" folder which is itself found inside the folder in which BlueJ was installed). Any libraries placed in this directory will be loaded by BlueJ. This is intended to be a "system wide" method to use custom class libraries as it will apply to all users using the same installed copy of BlueJ, so it can be used for instance in a lab environment to make the libraries available to all students. These libraries must be .zip or .jar archives.
Naturally, to put a library in a "userlib" directory, a person must have write access to the directory.
Libraries loaded via this second method are listed in the "Libraries" tab of the "Preferences" dialog also, but libraries cannot be added to or removed from the userlib directory via the dialog. These libraries will be available in all projects.
The third way is via the "+libs" directory. If a directory called "+libs" is found inside a project when it is opened by BlueJ, then all the class libraries inside it will be on the classpath (and therefore available for use in the project). This is a convenient way to allow libraries to be loaded on a project-by-project basis. This comes in handy if you want to distribute a project with any libraries that might be needed for it to function. You can simply zip up the project directory and distribute the project.
So in summary there are three ways that custom class libraries can be made available inside BlueJ. For system level access (all users and all projects) you can use the "userlib" directory. For user level access (all projects for a single user) you can use the Preferences Dialogue to add a library, and for accessibility from a single project you can create or add an archive to a project's "+libs" directory.
It can be very useful for educational or testing purposes to instantiate library classes. For example: Do you want to play around with a String object? Do you want to see how java.awt.Point behaves? In BlueJ, you can do this.
Select "Use Library Class..." from the tools menu. Then type in (or select from the popup menu) the full class name of the class you want to instantiate. Hit enter, and you will see a list of all constructors and static methods. Select one - and you're done!
You can, in the same way, call static methods of library classes. For example, select java.lang.Math, double-click the "random()" method and - voila - you got a random number!
BlueJ 4.0.0 and later versions have support for running JavaFX applications. If you have a subclass of JavaFX's Application class, you can right-click on it and select "Run as JavaFX application". Since version 4.1.1, BlueJ will also prompt you to ask if you always want to run this project's code on the JavaFX thread, which is required if you want to interactively invoke code that manipulates the JavaFX GUI.
If you want to run JavaFX code without writing your own Application subclass (or you are using BlueJ 3), you must initialise JavaFX in your code (e.g. by creating a new JFXPanel) and use Platform.runLater to wrap any JavaFX-related code.
Support for creating and running applets was removed in BlueJ 4.0 (as noted in the version history). This change is in line with the deprecation of applet technology within the Java runtime environment, as announced by Oracle. Many of the web browsers have also removed support for running applets.
An alternative, for those wishing to create simple GUI-based applications in BlueJ, is to use the JavaFX API. There are various tutorials for JavaFX available on the web — see for example this one at tutorialspoint.com, or use a web search to find others.
If you really need support for applets in BlueJ, your only option is to use an older version of BlueJ (3.1.7 is the last version to support applets).
The latest versions of BlueJ (4.2.0+) require Java 11. Most BlueJ installers now ship with the correct version of the JDK included.
Older versions of BlueJ (4.1.4 and earlier) require Java 8.
For other languages, you will have to make your own translation. All labels, menus and dialogues have to be translated. We are looking for volunteers to do that. Here is how.
In the lib directory, you will find subdirectories named "english", "german" and "swedish" and so on. These contain all the language dependent texts. Create a new directory for the language you want. Let's say you want to make a language setting for Elvish. In that case, make a directory named "elvish". Then copy all the files out of one of the other language directories into your new language directory. They are all text files. Edit each of those files and translate all the texts in them to Elvish (keeping the format of the files as it is), then run the "native2ascii" utility that comes with the JDK to convert the files to the correct format. Once you have done that, you can switch the Elvish language setting on as described above, using the property setting: bluej.language=elvish If you do this, we would be very grateful if you would send us your language files for inclusion into the BlueJ distribution. Someone out there might just be looking for a translation into your language, too.
url.javaStdLib with the path of the documentation (where "index.html" is located).doctool.linkToStandardLib with either true or false, which indicates whether to use the selected path to generate documentation.BlueJ has two files in which in stores its configuration properties.
Properties set in bluej.properties override those in bluej.defs.
You can edit both of these files using a standard text editor.
On Windows you can use the Notepad application to edit the files, but you will need to select "All files" as the file type in the "Open file" dialog. Furthermore, you may need to save the file to a different location (using "save as") and then copy it over the original file using the Windows Explorer if you are unable to save over the original file directly.
BlueJ actually runs two Java VMs: One is for BlueJ itself, and the other runs user code (for instance if you instantiate a class the resulting object is created in the user VM).
To specify arguments for the user VM, use the bluej.vm.args property in bluej.defs (see where BlueJ stores its configuraiton).
To specify VM arguments for the primary VM, you need to do something different according to the operating system you are using:
Be warned that changing the Java VM arguments is generally unnecessary and if done improperly can prevent BlueJ from functioning correctly.
Since BlueJ 3.0.5, encoding is maintained per-project and defaults to UTF-8 for new projects. The encoding is specified in the 'project.charset' setting of the package.bluej file (in the project root), and determines both the encoding used by programs run under BlueJ as well as the encoding used for Java source files within the project.
For older versions of BlueJ (before 3.0.5):
You need to change the "file.encoding" property to a supported character encoding name ("UTF-8" or "ISO-8859-1" for example - a list of character set names is available here, though java does not support them all).
You can do this by passing -Dfile.encoding=UTF-8 (for example) as an argument to the Java Virtual Machine. See the FAQ question above for how to do this. You should probably specify the same encoding on both the main and the user VM.
BlueJ uses TCP/IP socket communication as part of its normal operation. The communication occurs between two processes running on your computer - one is for BlueJ itself, and the other is for a "debug VM" which runs your program. Although this communication doesn't go over the network, some firewall software will block this communication which inhibits BlueJ operation. (On Windows, recent BlueJ versions instead use a communication method called "shared memory", however, BlueJ will fall back to using TCP/IP if shared memory fails for some reason.)
Firewalls generally take one of two approaches to blocking network traffic. The first approach is to block traffic based solely on the source/destination IP address (and/or port number). The second approach is to block traffic on a per-program basis. A common combination approach is to allow setting specific source/destination rules on a per-program basis. Some firewalls only block incoming connection attempts while other firewalls may also block outbound connections.
For BlueJ to work, communication must be allowed when both the source and destination IP address is 127.0.0.1, which is the "loopback" address (i.e. it refers to the local machine, not a machine on the network). Note that BlueJ must be allowed to make outbound connections (or "act as a client") as well as receive incoming connections (or "act as a server").
On Windows:
If your firewall sets rules on a per-program basis, the program you should apply the rules to will usually be the bluej launcher (bluej.exe) - however you may also need to specify rules for the Java executable ("java.exe") as well or instead. There are actually multiple copies of the java.exe executable installed as part of the JDK or J2SDK on Windows - you may need to change the rules for them independently. You may also need to change the rules for the "javaw.exe" files.
If you use the standard Windows firewall, you can use the following pages to help you configure the firewall:
If you use 3rd party security software, you will need to consult the documentation for that software.
If you have adjusted or disabled your firewall but BlueJ still does not run, you could try performing a clean boot. If BlueJ runs after a clean boot, you can then determine which service prevents BlueJ from running (see the instructions on the "clean boot" page). You may be able to leave the service disabled, or contact the vendor for support.
On Linux:
On Linux, the firewall will normally be configured correctly, unless you are using custom firewall rules. However, Security Enhanced Linux (SELinux) can also prevent TCP/IP communication which will prevent BlueJ from functioning correctly. You should consult your distribution's documentation to determine how to disable or correctly configure both the firewall and SELinux (or, try doing a web search or consulting an appropriate user forum).
Recent Debian systems change the kernel's default network settings in a way which Java doesn't seem to like. You may be able to overcome this by editing the file "/etc/sysctl.d/bindv6only.conf" and changing the setting "net.ipv6.bindv6only" from 1 to 0, and restarting your system.
Some information on why you are seeing the error might be found in BlueJ's debug log, which you can normally see by typing:
cat ~/.bluej/bluej-debuglog.txt... in a terminal window.
Other Systems:
You will need to consult your system documentation or 3rd-party software documentation for information on how to configure your firewall software.
Since Java 7u6, the Java accessibility tools are included with Java as standard -- but they are disabled by default.
To enable the Java accessibility tools, follow these instructions. You may need to restart your machine afterwards. With the Java Access Bridge enabled, BlueJ should work with your installed screen reader (it was tested with NVDA).
Screen reader support was significantly improved in version 3.1.0 of BlueJ (and improved again in version 3.1.1), so we recommend upgrading to at least version 3.1.1.
BlueJ does not have a dark theme as such, but you can change many of the colours that it uses in order to reduce visual brightness.
For the editor, first copy the file lib/stylesheets/java-colors.css to your BlueJ user directory (e.g. on Windows this is typically C:\Users\your-username\bluej). This copy of the file will take preference, and you can edit the colours there. One important set are the foreground text colours which are specified as -fx-fill in the ".token-XXX" blocks at the top, especially .token-default. The main background colour, and other background colours for scope highlighting, are specified in the .scope-colors block. There is presently no way to change the colours that BlueJ uses for other parts of the interface, such as the package diagram.
BlueJ uses JavaFX for UI rendering. The style of most UI elements in BlueJ can be changed via CSS, a common practice with JavaFX.
The CSS files used by BlueJ for style rendering are located in the lib/stylesheets folder, located into the BlueJ user directory (e.g. on Windows this is typically C:\Users\your-username\bluej).
Where it applies, a font family can be provided to the right class using the CSS property name -fx-font-family. For further details about how CSS is used with JavaFX, refer to the offical documentation (JavaFX 11).
We also advise the use of ScenicView to ease the exploration of the JavaFX objects styling in BlueJ, for example to check the CSS class names.
It possible to set a default location for BlueJ projects to be saved to (or opened from).
However, this default location will be overwritten as soon as the user choose a different location in BlueJ.
In order to specify a default location, uncomment and/or change the property bluej.projectPath with the desired location value in the BlueJ settings. (Note that ':' and '\' need to be escaped with '\' in the settings files.)
See how to access the BlueJ settings files.
During the installation process, BlueJ needs to write some files. It attempts to write those to the /tmp directory. The error may indicate that you do not have write permission to that directory.
If this is the case, you can start java and tell it to use a different directory for temporary files:
java -Djava.io.tmpdir=/something/something -jar bluej-200.jarAnother possibility is that you are out of disk space altogether.
This is not a BlueJ-specific issue, but a problem with Windows Installer mechanism, which maybe fixed by one of the following ways:
Various strange problems may occur when installing BlueJ on Windows; mostly, these problems are due to issues with the Windows installer framework rather than with BlueJ. Some examples:
Using the CCleaner tool has been reported to solve some issues (this tool is published by a third party and the BlueJ team can not take responsibility for any problems its use may cause nor provide support for this tool).
To diagnose these problems, you should install BlueJ with Windows Installer logging enabled:
You can now try to read the log file yourself, or send it to the support team. To do the latter, use the support request form, and then send the log as an email attachment when you receive a response from a team member. Do not attempt to attach a Windows Installer log when initially submitting the form, as it is only designed to accept BlueJ debug logs.
Recent versions of BlueJ (4.0+) are bundled with the JDK. These versions require Mac OS X 10.7.3 or later, and do not require the JDK to be installed separately.
For older versions of BlueJ:
Versions 3.1.x are also bundled with a JDK, however for these versions it is also possible to use the 'legacy' package which uses the system JDK, on systems where Java 6 is installed.
Versions 3.0.x: These versions of BlueJ require Java 6 to be installed separately.
Versions 2.5.x: These versions require Java 5 or 6 to be installed separately.
On Mac OS X 10.4 (Tiger), only Java 5 is available. On Mac OS X 10.5 (Leopard), Java 6 is available with an update (10.5.2) but only on 64-bit Intel processor systems (not on systems with a PowerPC, Intel Core or Intel Core Duo processor).
What this means is: you will not be able to run BlueJ 3.0 - 3.0.9 on a Mac with OS X 10.4 (Tiger), nor on some Macs with OS X 10.5 (Leopard). You can however run BlueJ 2.5.3 on these systems.
Regardless of which OS X version you have, if you use a version of BlueJ which does not bundle the JDK then:
You must make sure that the correct Java version is active in order to run BlueJ. To do this, run the "Java Preferences" application (Tiger: Applications / Utilities / Java / J2SE 5.0 / Java Preferences; Leopard/Snow Leopard: Applications / Utilities / Java Preferences), choose the "General" tab, and move Java SE 6 (or Java SE 5 if you do not have Java SE 6) to the top of the list. If you do not see Java SE 6 in the list, you will not be able to run BlueJ 3.0+.
We have found that on MacOS Mojave, Greenfoot can crash when a dialog is displayed. This may happen if the "update API" dialog is shown when an old scenario is opened but may also occur for other dialogs, particularly if you switch to another application while the dialog is shown.
This is actually a Java crash, described in bug entries here and here.
A workaround is to add BlueJ to the accessibility list in:
System Preferences > Security & Privacy > Privacy (tab) > Accessibility (in list on left; then add BlueJ to the list of applications on the right).
Doing this appears to prevent the crash.
BlueJ is itself a Java application, and creates another instance of a Java Virtual Machine (in which the user code written in BlueJ is executed). BlueJ launches these two applications: /Applications/BlueJ.app/Contents/MacOS/JavaAppLauncher and /Applications/BlueJ.app/Contents/JDK/Home/bin/java.
Make sure that the following applications are also granted authorisation in the MDM:
Bluej.app and/or org.bluej.Bluej,com.apple.JavaWebStart and com.apple.JavaLauncher.Some MDM may need extra authorisation for running OpenJDK, which BlueJ uses. To do so, create a "placeholder" package with your MDM with the Bundle ID set to net.java.openjdk.cmd.
As the full message text states, this problem is normally caused by firewall software interfering with BlueJ's operation. More information on how to deal with this issue is available here; see also this linux-specific information.
Another possible cause of this problem when running on Windows is that characters in the path to your project (including the project name) are not representable in the system character set. This often occurs when you use accented characters (or non-English characters) in your project path, and is actually due to a Java bug. In this case the easiest solution is to rename/move your projects to a location without the troublesome characters.
If you cannot resolve the problem, you will need to contact the BlueJ support team.
If your program requests input, then you must supply the input before the program can continue running! What is happening is that your program is waiting (indefinitely) for the input that it has asked for.
Generally, you can open the terminal from the 'view' menu and then type into it. Press 'enter' after supplying the input (the terminal input is line buffered).
As a better solution, you should have your program output a prompt (eg. "Please enter your name") before trying to read input. That will cause the terminal window to open automatically.
Since you are using Git over the network, it is affected by firewalls. If you have a proxy which you use for access to web sites via the HTTP/HTTPS protocols, then you should configure BlueJ to be aware of the proxy, which it can then use to access Git repositories on external hosts. This is a little bit complicated, but can be done following the steps below:
First you need to determine the proxy host and port for each protocol. Ask your system administrator for the correct settings. Note that HTTP and HTTPS will typically (but not necessarily) use the same proxy host and port.
To configure BlueJ to use a proxy, you need to define the Java properties http.proxyHost and http.proxyPort (for HTTP). For HTTPS the equivalent properties are https.proxyHost and https.proxyPort. (You might also be able to specify that the system proxy settings are used, by setting java.net.useSystemProxies to true, but we haven't been able to verify if this works).
To define the properties, you must add a -D option for each of these properties to the Java command line when BlueJ starts; for example, you might use:
-Dhttp.proxyHost=myproxy.myschool.edu -Dhttp.proxyPort=8000
These are just examples however - you'll need to use the correct host and port value!
Determine the appropriate command line arguments for your proxy settings. Then, you need to ensure that BlueJ starts with these arguments supplied to Java. To do that, see the explanation in this FAQ entry. (For Windows, you will need to edit the bluej.defs file and set the bluej.windows.vm.args property).
GitHub no longer allows GitHub account passwords to be used for version control operations, such as checking out and pushing.
GitHub now has a system called Personal Access Tokens, these "tokens" can informally be seen as sub-passwords. GitHub now view your main password as only for logging in to their website and controlling generation of sub-passwords for individually specified purposes.
You will need to follow the instructions of the above link to generate a "token" for the relevant repository, then enter this token into BlueJ's password field.
The work-around this issue is simple: specifying a font family usually solves the problem.
Follow this procedure to change the font family in BlueJ.
This problem can occur especially after connecting and then disconnecting a second monitor or projector display. The window is open, but cannot be seen on screen, because it is located outside of the visible screen area; you need to move it back to the visible area. There are a number of ways to do this described on this page.
(You may also experience this problem if you change your display resolution, or if your project settings have somehow become corrupted).
This problem has been known to affect older versions of BlueJ. The most common cause of this problem is that the JDK version is too low, and BlueJ requires a newer version (e.g. some versions of BlueJ require Java 6 and produce this issue when run with Java 5).
You can download the JDK here:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Then, use the "select VM" utility (from the start menu) to choose the newer JDK for BlueJ.
We recommend running the latest version of BlueJ, bundled with a recent Java JDK, to avoid this and other problems. Note that Bluej currently (version 4.x) requires Java 8.
The situation is usually this: on a multi-user installation, the system administrator installs and starts BlueJ, including the selection of the Java version (JDK/J2SDK). BlueJ runs fine. But when other users start BlueJ, they are prompted every time for the JDK location.
The reason is write restrictions to the Windows registry prevent BlueJ from saving the selected JDK. On Windows, BlueJ remembers the selected JDK version by writing an entry into the user space of the registry. If the registry is write protected, or if it is restored to its original state on every login, this information is lost, and the user will be asked to select the JDK location again.
This problem should not occur on versions of BlueJ which are bundled with a JDK. We recommend using a "bundled JDK" installation package rather than installin BlueJ and the JDK separately. Since BlueJ 4.0.0, only the bundled package is available; BlueJ is no longer available as a separate download.
There are two solutions available.
The first is to give users write access to the Windows registry.
If this is not practical (for example in some lab environments) then BlueJ can be explicitly configured to use a specific JDK, using a property in bluej.defs (see Tip 4 in the tips archive for general info about configuring BlueJ).
Set the 'bluej.windows.vm' property in bluej.defs to the path of the JDK you want to use. This property is commented out by default. If it is set, BlueJ will not check the registry, not ask the user, but just use this Java version and start.
Visual artifacts - black areas, distorted or missing text, etc - are usually a result of either a display driver bug or a Java bug. Try updating your display drivers (see here for Windows 7) or disabling graphics acceleration (see here).
If you are running a version of BlueJ which does not bundle the JDK, you should also make sure your JDK is up-to-date. Remember to run the "select VM" utility to ensure that BlueJ runs with your most recent Java version.
We have had some reports of text disappearing when the mouse cursor hovers over it, especially with Intel Graphics 4000 HD chipsets; the drivers may be buggy. A solution in this case is to disable Java's use of Direct3D (D3D) for rendering. To do this, you need to edit the BlueJ configuration (the bluej.defs file) and change (or add) the bluej.windows.vm.args setting by adding -Dsun.java2d.d3d=false. For example, change:
#bluej.windows.vm.args=to:
bluej.windows.vm.args=-Dsun.java2d.d3d=false(Make certain to remove the '#' at the beginning of the line!) It's possible that this setting will help with similar problems on other graphics chipset too.
Most crashes in BlueJ are related to graphics card issues. See the answer directly above about updating graphics card drivers for likely fixes. Also, if you are running your graphics card overclocked, try running without overclocking, as overclocking is known to cause graphics-related crashes.
This is a problem which affects some laptops. It may be due to video driver problems, so it's worth trying to update your video drivers if possible.
The problem affects Java applications other than BlueJ and there is a bug in Oracle's bug database regarding the issue.
The suggested fix is to edit the bluej.defs configuration file and enter the following settings:
bluej.vm.args=-Dsun.java2d.ddoffscreen=false
When you double click on a Jar application in Windows, it will not open a console window, therefore, if your application outputs text using System.out.println (for example), this output would be invisible.
One possible solution would be to write a GUI interface. Another one would be executing your jar using the command line, running:
java -jar yourApplication.jar
When double-clicking a BlueJ project file, BlueJ is usually opened and the corresponding project loaded.
However, on Windows, if the path of the project contains some non-ASCII characters (i.e., characters that are not simple Latin), BlueJ shows an error and the project cannot be opened.
This bug is a known Java issue that is therefore not directly related to BlueJ (see this bug ticket for more details).
To overcome this problem, either open the project from BlueJ, via the “Project” menu, or, if possible, save the project in a path that does not contain non-ASCII characters.
By default in macOS, ctrl-space is assigned to switch input source. There are two ways to fix this. One, using fn-ctrl-space can trigger the BlueJ shortcut instead. Two, you can disable or re-assign the macOS shortcut. Go to the system settings, then select the "Keyboard" section in the left-hand list. Click the "Keyboard shortcuts" button, and in the new window select "Input Sources" on the left. Either untick the box to disable the shortcuts altogether, or double-click an item to assign a new shortcut.
Note: this problem should be resolved in BlueJ 4.0.0+.
The "open project" dialog in BlueJ, because it comes from Java, is different from file chooser dialogs in native Mac applications. It doesn't show a list of devices (such as USB sticks) which makes it harder to locate them.
You can open projects from such a device by going in to the "Volumes" folder in the top-level "Macintosh HD". Mounted volumes from storage devices will be listed there.
On Mac OS X 10.2 and later, execution in BlueJ can fail when several Macintoshes on the same network have the same computer name (set in System Preferences/Sharing).
Solution: ensure that different machines have different names.
If you are on Mac OS X, and you try to create an object and it never finishes (the message "Creating object..." stays in the status bar), the reason may be the use of a proxy server for network access.
BlueJ uses sockets for communicating between two local virtual machines, and this is affected by the system's network settings. If your organisation uses a proxy, this may be the cause.
The solution: configure localhost traffic not to use the proxy server.
Here is how:
In recent versions of OS X, including Snow Leopard, open your System Preferences, go to the Network panel, click Advanced... and select the Proxies tab. Add "localhost" (without the quotes) to the Bypass proxy settings box.
On older versions of OS X, open your System Preferences, go to the Network panel, click Configure and Proxies for your network connection. Add "localhost" (without the quotes) to the Bypass Proxy Settings box.
There appears to be a bug in Apple's Java (Mac OS X 10.6.2, Java 1.6.0_17) which prevents BlueJ's menus from working when certain languages are selected as the preferred language via the system preferences.
One workaround is to set English as the preferred language.
Another workaround is to set BlueJ to use the "cross platform" look-and-feel rather than the "Aqua" (Mac OS X native) look-and-feel. To do this, edit the "bluej.defs" file (see tip of the week #12) and remove the '#' at the beginning of the line which reads:
#bluej.lookAndFeel=crossplatformSo that it reads:
bluej.lookAndFeel=crossplatformThis will make BlueJ use the (uglier) "cross platform" look-and-feel, but at least the menus (which will appear at the top of the BlueJ window) will be functional.
Some macOS users are affected by a JDK bug which prevents BlueJ from starting properly. Fortunately there is a simple work-around: open the Font Book application, and choose "Restore standard fonts..." from the File menu (click "Proceed" when prompted).
On Linux, this problem can be caused by Security Enhanced Linux ("SELinux") or overly restrictive firewall rules. Consult your distribution's documentation to find out to disable or correctly configure SELinux and/or the firewall. More information is available in the earlier firewall answer.
If you are running Debian "Sid" (the "unstable" Debian release) and you get this error message, it may be because of an apparent incompatibility or bug with Java. Some users have been able to resolve this by editing the file "/etc/sysctl.d/bindv6only.conf" and changing the setting "net.ipv6.bindv6only" from 1 to 0, and restarting the computer. However, we recommend that you do not run the unstable Debian release (or any other "unstable" Linux distribution or operating system) if you are not able to resolve problems like these on your own.
On the Raspberry Pi, a user needs super-user privileges ("root access") in order to access certain hardware interfaces, including the general-purpose I/O ports. Whenever BlueJ can't acquire such permissions without supplying a password, it will run without access to this hardware, and display the "Hardware access not available" message.
To give root access to your user account, you need to edit (from a privileged account) the file "/etc/sudoers" using the command "sudo visudo", and add the line "john ALL=(ALL) NOPASSWD: ALL" (where "john" is the user account you use to run BlueJ).
To re-enable hardware access in BlueJ, go to the Tools menu, select Preferences and open the Raspberry Pi tab; select the option Allow access to GPIOs (requires sudo), and then close BlueJ. The next time you start BlueJ it will run with full hardware access.