A Concurrent Affair » DrJava

DrJava DefinitionsPaneMemoryLeakTest fails on Mac

Mathias — Mon, 14 Nov 2011 06:28:38 +0000

I submitted a bugfix for a problem with the debug panel when no debugger is available.

I noticed that on the Mac, the DefinitionsPaneMemoryLeakTest now fails:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

[junit] DefinitionsPaneMemoryLeakTest 26.92 sec
[junit] Testsuite: edu.rice.cs.drjava.ui.DefinitionsPaneMemoryLeakTest
[junit] Tests run: 1, Failures: 1, Errors: 0
[junit] ------------- Standard Error -----------------
[junit] Skipped analysing class java.security.ProtectionDomain
because of java.lang.AssertionError
[junit] ------------- ---------------- ---------------
[junit] Testcase:
testDocumentPaneMemoryLeak(edu.rice.cs.drjava.ui.DefinitionsPaneMemoryLeakTest): FAILED
[junit] Document 0 leaked:
[junit] private static sun.awt.AppContext
sun.awt.AppContext.mainAppContext->
[junit] sun.awt.AppContext@4998a455-table->
[junit] java.util.HashMap@7f1bfcfc-table->

...

[junit] [Ljava.beans.PropertyChangeListener;@67b50846-[373]->
[junit] javax.swing.JViewport$1@7ceade87-this$0->
[junit] javax.swing.JViewport@48be3a5e-component->
[junit] java.util.ArrayList@6b333f77-elementData->
[junit] [Ljava.lang.Object;@559b52d3-[0]->
[junit] edu.rice.cs.drjava.ui.DefinitionsPane@2a38d0a8-_doc->
[junit] edu.rice.cs.drjava.model.DefaultGlobalModel$ConcreteOpenDefDoc@557e5cbd
[junit] at
org.netbeans.test.MemoryTestUtils.assertGC(MemoryTestUtils.java:137)

It passes on Windows, and I haven’t tried it on Linux. I rolled back as far as revision 5266, which was from June 3, 2010, and it was still failing on the Mac. I have a feeling that something must have changed in Mac OS (Lion) or the Java version I have running (1.6.0_29). I know I’ve successfully run the unit tests many times since then on the Mac, even on my MacBook Pro. I even think I have run them successfully on Mac OS Lion.

It would be great if I could still run the unit tests on an older Mac, with an older Mac OS. I’ll dig into this, but it may take some time.

Better Number Highlighting in DrJava More Difficult

Mathias — Thu, 29 Sep 2011 06:58:00 +0000

Getting the lexing right for the syntax highlighting will be a little bit more work than I thought. Right now, DrJava tokenizes numbers like 3.14 separately as “3″ “.” “14″, and then it highlights “3″ and “14″ as numbers. That approach never was quite right, but I think it gets even uglier with the new literals.

I’m continuing the process of giving the compiler adapters more responsibility. The first step that I made for supporting HJ and Mint was to put the list of keywords into the adapters. I was now going to put the highlight determination into the adapters, but it seems like I may have to put tokenization there as well.

Of course, that fits well with plans of eventually supporting more languages, and languages that differ more.

Additional Java 5 Syntax Highlighting Errors in DrJava

Mathias — Tue, 27 Sep 2011 16:15:42 +0000

While adding syntax highlighting for underscores and binary literals introduced in Java 7 to DrJava, I discovered that a few other numbers aren’t syntax-highlighted correctly. Some of these problems go back to the beginning of Java, others go back to Java 5, when the obscure hexadecimal floating-point literal was introduced.

Here are the numbers that give DrJava’s syntax highlighter trouble:

1
2
3
4
5
6
7
8
9
10
11
12

float f = 6.022137e+23f;
f = 2.f;
f = .3f;

double d = 2.;
d = .3;
d = 1e-9d;

double x = 0x1.8p1;
x = 0x1.fffffffffffffp1023;
x = 0x1.0P-1074;
x = 0x0.0000000000001P-1022;

Did you know about these hexadecimal floating-point literals? I didn’t.

I created a bug report for these Java 5 highlighting bugs.

References:

Suggestions for Better Java 7 Support in DrJava

Mathias — Sun, 04 Sep 2011 19:43:00 +0000

I just looked through the new language features in Java 7, and experimented with them in DrJava.

None of the changes are supported in the Interactions Pane, and there will be a lot of required work to make these things work there. We’ll have to change the parser, change the type checker, change the interpreter, and so on.

There are, however, smaller changes that we should do to provide better support in the Definitions Pane:

Binary literals int i = 0b100000; are not syntax-highlighted correctly.
Numeric literals with an underscore in them int i = 1_000; double d = 3.141_5927; are not syntax-highlighted correctly.

In some cases, try-with-resources is indented badly:

1
2
3
4
5
6
7
8
9
10

// badly indented
public static void tryWithResources2(String f) {
try (InputStream is = new FileInputStream(new File(f));
InputStream is2 = new FileInputStream(new File(f))) {
is.read();
}
catch(IOException e) {
e.printStackTrace();
}
}

Everything else looks pretty good. Here’s the sample class that I used:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134

import java.io.*;
import java.util.*;

public class Java7Samples {
public static void main(String[] args) {
stringSwitch(args[0]);
intSwitch(new Integer(args[1]));
tryWithResources(args[2]);
tryWithResources2(args[2]);
multiCatch(new Integer(args[3]));

// bad integer syntax highlighting
int i = 0b100000;
System.out.println(i);

// bad numeric syntax highlighting
i = 1_000_000;
System.out.println(i);
i = 2__000__000;
System.out.println(i);
// int illegal = _1000;
// int illegal2 = 1000_;
double d = 123_456.789_012;
System.out.println(d);
}

public static void stringSwitch(String arg) {
switch(arg) {
case "one":
System.out.println("case one");
break;
case "two":
case "three":
System.out.println("case two or three");
break;
default:
System.out.println("default case");
}
}
public static void intSwitch(int arg) {
switch(arg) {
case 1:
System.out.println("case 1");
break;
case 2:
case 3:
System.out.println("case 2 or 3");
break;
default:
System.out.println("default case");
}
}

public static void tryWithResources(String f) {
try (InputStream is = new FileInputStream(new File(f))) {
is.read();
}
catch(IOException e) {
e.printStackTrace();
}
}

// badly indented
public static void tryWithResources2(String f) {
try (InputStream is = new FileInputStream(new File(f));
InputStream is2 = new FileInputStream(new File(f))) {
is.read();
}
catch(IOException e) {
e.printStackTrace();
}
}

public static class Ex1 extends RuntimeException { }
public static class Ex2 extends RuntimeException { }
public static class Ex3or4 extends RuntimeException { }
public static class Ex3 extends Ex3or4 { }
public static class Ex4 extends Ex3or4 { }

public static void doSomething(int i) throws Ex1, Ex2, Ex3, Ex4 {
switch(i) {
case 1:
throw new Ex1();
case 2:
throw new Ex2();
case 3:
throw new Ex3();
case 4:
throw new Ex4();
}
}

public static void handleEx1Or2(RuntimeException e) {
System.out.println("handlEx1Or2");
}

public static void handleEx3Or4(Ex3or4 e) {
System.out.println("handlEx3Or4");
}

public static void multiCatch(int i) {
try {
doSomething(i);
}
catch(Ex1 | Ex2 ex) {
handleEx1Or2(ex);
}
catch(Ex3 | Ex4 ex) {
handleEx3Or4(ex);
}
}

public static void multiCatch2(int i) {
try {
doSomething(i);
}
catch(Ex1 |
Ex2 ex) {
handleEx1Or2(ex);
}
catch(Ex3 |
Ex4 ex) {
handleEx3Or4(ex);
}
}

public static Map<String, String> diamond() {
return new HashMap<>();
}

public static void diamond2() {
Map<String, String> map = new HashMap<>();
}
}

Update

I filed bugs 3404387 and 3404389.

New DrJava Beta Release: drjava-beta-20110822-r5448

Mathias — Tue, 23 Aug 2011 06:30:09 +0000

We have made a new development release available: drjava-beta-20110822-r5448. You can download it from the DrJava website or from SourceForge.

Available for download at http://drjava.org.

DrJava is a lightweight programming environment for Java designed to foster test-driven software development. It includes an intelligent program editor, an interactions pane for evaluating program text, a source level debugger, and a unit testing tool.

In addition to bug fixes, this beta release includes a two new features introduced after the last development release:

The debugger has been revised to interface properly with functional language level files. The source line numbers shown in the debugger now consistently correspond to the source files open in DrJava, even when the source files are language level files. During tracing, line numbers corresponding to augmented code that does not appear in language level files are mapped to -1.
A compiler adapter for Java 7 has been added to DrJava. Unfortunately, the adapter does not find the Java 7 compiler on Windows unless DrJava is started from a JDK installation rather than a JRE installation. As a result, running this release on Windows with Java 7 will typically invoke the bundled Eclipse Java compiler rather than the Oracle/Sun Java 7 compiler. Note: Java 1.4 compatibility has been dropped. To use DrJava, you will need Java 5 or newer.

New features since the last release:

better integration of the functional languaage level with the debugger
a Java 7 compiler adapter.

Bug fixes since last release:

the code has been revised to more closely conform with the synchronization invariants governing the design.

New features since the last stable release:

better integration of the functional languaage level with the debugger
a Java 7 compiler adapter
refactored language level
improved compiler support, including support for Habanero Java
added support for copying the Compiler Errors pane to clipboard
preferences like indent level can now be stored on a per-project basis (see “Project Properties”, “Advanced”).

Bug fixes since the last stable release:

the code has been revised to more closely conform with the synchronization invariants governing the design
applet viewer not started in event thread anymore to avoid exception
Static type checking for primitive casts in Interactions pane.

DrJava Now Works Even When Launched with the Java 7 JRE

Mathias — Mon, 22 Aug 2011 05:26:44 +0000

I think I’ve got DrJava working with the Java 7 compiler the way it should, even when started with the JRE (as long as the JDK is installed as well). That was the situation that both Corky and I got into when we double-clicked on DrJava.

Please give the weekly build drjava-weekly-20110822-r5448.jar a shot.

In the original JDK7 compiler adapter, I followed the instructions and used the javax.tools.ToolProvider.getSystemJavaCompiler() method to get the Java compiler. Unfortunately, when a user starts DrJava with the JRE, the tools.jar file is not on the boot classpath, and the getSystemJavaCompiler() method will not find the com.sun.tools.javac.api.JavacTool class, even when we later provide the tools.jar file to the class loader. The javax.tools package cannot be shadowed, so we can’t load one version of it for one compiler and a different version for another compiler.

Instead of using ToolProvider, I now do a Class.forName("com.sun.tools.javac.api.JavacTool").newInstance() directly. That’s exactly what ToolProvider is doing too, but we can shadow the com.sun.tools.javac.* packages and have control over the classloader.

I’m sorry that it took this long. I had a long day on Friday and I’m on call this coming week; I wanted to make sure I have time to goof off and enjoy the beautiful weather this weekend.

If other issues come up, please let me know.

Java 7 for DrJava and Concutest

Mathias — Mon, 01 Aug 2011 15:58:49 +0000

I worked on Java 7 support this weekend, and I’m almost done. I just discovered that Concutest is currently incompatible with Java 7, though, so I will need to disable the ConcJUnit option in DrJava when using Java 7. I also need to test on Mac and Linux.

I’ll try to finish this tonight so we can get a beta out. Or should we release a stable version without this code?

Fixing Concutest will take a bit longer, of course.

Yes, DrJava Works under Mac OS X 10.7 Lion

Mathias — Thu, 28 Jul 2011 07:29:52 +0000

I just upgraded to Mac OS X 10.7, and DrJava works flawlessly. The one vague report that someone had filed therefore proved to be wrong.

When I started DrJava the first time, Mac OS X asked me if I wanted to download a Java runtime environment. I said yes. The JRE was downloaded and installed, and after that, DrJava opened.

I’m still not sure about Mac OS X Lion, but I continue to be excited about DrJava:

DrJava on Mac OS X Lion

Does DrJava Work on Mac OS X Lion?

Mathias — Sat, 23 Jul 2011 22:17:43 +0000

We were just informed of an entry on RoaringApps indicating that DrJava does not work on Mac OS X Lion.

Is that the case? We don’t know at this time. DrJava has always worked on previous versions of Mac OS X, but we haven’t had the opportunity to test it on Mac OS X Lion. If you have Mac OS X Lion, could you please download and run DrJava and corroborate the information?

Thanks!

Update

Yes, it does work! DrJava works flawlessly in Mac OS X 10.7 Lion.

Two DrJava Tutorials on YouTube

Mathias — Mon, 11 Jul 2011 05:55:05 +0000

On YouTube, I found two tutorial series that describe DrJava:

and

Neither of them covers very advanced topics, but I’m always happy to hear that beginners choose DrJava. It’s the primary audience for our IDE.

PPPJ 2011 Tool Paper Accepted

Mathias — Sun, 26 Jun 2011 07:24:01 +0000

A while ago I worked on a paper together with Vivek, Corky, Vincent, Jared and Raghavan at Rice. We still have to make some final revisions, but I’m happy to report that our tool paper “DrHJ — a lightweight pedagogic IDE for Habanero Java” has been accepted to PPPJ 2011 in Denmark.

Eclipse Has Messed with My Shortcut-fu for DrJava

Mathias — Sun, 12 Jun 2011 07:36:22 +0000

Working with Eclipse for nearly half a year has definitely messed with my shortcut-fu for DrJava. I keep pressing the wrong buttons now:

Function	Eclipse	DrJava
Go to class under cursor	F3	F6
Go to class	Ctrl-Shift-T	Ctrl-Shift-G
Run unit tests	F11 / Ctrl-F11	Ctrl-Shift-T
Find next	Ctrl-K	F3

Very confusing indeed.

I decided to pick up working on this file I/O bug in DrJava again, though, and I verified that the font dialog in Windows 7 is verifiable problematic.

DrJava Is Virus-Free

Mathias — Tue, 08 Mar 2011 08:05:29 +0000

Today, Ian Barland informed me that someone on the AP-CS mailing list believed he found a virus in DrJava. Let me reassure you, if you download from drjava.org or SourceForge, our software is virus-free. We build on Linux or Mac systems and only test on Windows, which makes a virus infection even less likely.

Our software has also been independently certified as clean by hosting providers such as DowloadRoute, DoDownload, GearDownload, and DownloadAtlas. We even got this clunky award images:

DrJava download test: PASSED

I also just commissioned an online virus scan of the latest DrJava development release, drjava-20110205-r5425, using VirusTotal, a free service that uses over 30 different anti-malware products, and our software came out clean. Here are the reports for the exe file (exe file directly downloaded from SourceForge), the jar file (jar file directly downloaded from SourceForge), and the Mac application (Mac application directly downloaded from SourceForge).

Not that I ever had a doubt, but DrJava is virus-free.

I would be interested in seeing more information about this virus infection report, like what virus scanner was used, what virus was reported, and where the user downloaded the file.

I’m glad Ian brought this to our attention. We need to take even a false positive seriously.

DrJava Build and Release Instructions

Mathias — Wed, 09 Feb 2011 08:03:38 +0000

As part of our knowledge (back) transfer, I wrote up these instructions for creating a fresh build of all parts of DrJava and then making a new release on SourceForge.

Note: Our build process is currently broken for Windows machines (see “instructions below for building just DrJava”, step 6, “Make the release and put it into Subversion”.)

Check out trunk (svn co https://drjava.svn.sourceforge.net/svnroot/drjava/trunk), or if you have trunk checked out, update it.
cd drjava
ant clean jar
cd ../platform
export DRJAVA_JAR=../drjava/drjava.jar
ant clean compile-??? jar

Note: Which compile-??? targets you can run depends on the platform you are compiling on. You need to be on a Mac to run compile-mac and on Windows to run compile-windows. Since the compiled classes are stored in Subversion, you can always do

ant clean jar

to just get all the class files without recompiling.
cp platform.jar ../drjava/lib
cd ../plt
ant clean test jar
Copy the generated new plt.jar file over all other plt.jar files. This can be done using

find .. -name plt.jar -not -samefile plt.jar | xargs -n 1 cp -v plt.jar
cd ../dynamicjava
ant clean test jar-base
cp dynamicjava-base.jar ../drjava/lib
cd ../javalanglevels
ant clean test jar-base
cp javalanglevels-base.jar ../drjava/lib
cd ..
Continue with the instructions below for building just DrJava, but not plt.jar, etc. from scrach.

Building the DrJava application (not the libraries) and making a new release:

cd drjava
Create the release locally. It’s a good idea to do this first, without touching Subversion or SourceForge. To create a development release:
```
ant clean release-local
To create a beta release:
ant clean release-local-beta
To create a stable release:
ant clean release-local-stable
```
This cleans, compiles, runs the unit tests, builds the jar, exe and Mac application, and it also generates the Javadoc and a zip file with source code.
It makes sense to test the three different variants of DrJava: Run the jar on some platform, run the exe on Windows, and run the Mac application on a Mac, because sometimes one of them may be corrupted. This can has happened sometimes for the exe file when building on a Mac, or for the Mac application when building on Windows or Linux.
ant clean
This deletes the locally built release again.
Make the release and put it into Subversion. Run one of:
```
ant release
ant release-beta
ant release-stable
```
You may want to add -Dtest-repeat=0 to the command line (e.g. ant -Dtest-repeat=0 release). That tells Ant not to run the unit tests. You can leave it out, but we just ran the unit tests, so it should not be necessary to run them again.
Note that this step may ask you for your SourceForge password if you have never committed code to Subversion from the computer you are working on.
The build script will now create a “tag” of DrJava that will contain exactly the source code versions and libraries used to build this release of DrJava. This is useful in analyzing bugs that users report in a specific version.
Make note of that tag. It should be something like this: drjava-20110205-r5425
To upload files to SourceForge, we will follow this guide written by SourceForge. I find that using SFTP is the easiest.
Log into SFTP. In the following command, replace with your SourceForge username:
sftp ,drjava@frs.sourceforge.net
Example: sftp mgricken,drjava@frs.sourceforge.net
On the SFTP server: cd /home/frs/project/d/dr/drjava
If you are building a stable or beta release, type:
cd "1. DrJava Stable Releases"
If you are building a development release, type:
cd "2. DrJava Development Releases"
Create a directory with the name of the tag from step 8 above.
Example: mkdir drjava-20110205-r5425
Change into that directory.
Example: cd drjava-20110205-r5425
Upload the files. You can do that with the command:
put *
Example: put drjava-20110205-r5425*
Exit SFTP:
exit
Browse to DrJava’s SourceForge site at http://sourceforge.net/projects/drjava/develop and log in.
Click on the “Files” tab (or go to https://sourceforge.net/projects/drjava/files/).
Click on 1. DrJava Stable Releases or 2. DrJava Development Releases, find the tag, and enter that directory. You should see the files you uploaded.
Click on the (i) (Info) button next to the exe file, check the Windows checkbox, and press save.
Click on the (i) (Info) button next to the Mac application, check the Mac checkbox, and press save.
Click on the (i) (Info) button next to the jar file, check all the other checkboxes (except Windows and Mac), and press save.
This step changes the default download on DrJava’s SourceForge page (in the “Download Now!” button on https://sourceforge.net/projects/drjava/). People downloading directly from the SourceForge page will start getting the new release.

Prepare the release notes text file called readme.txt. I start with a template that looks like the one below. To determine the lists of new features and bug fixes, you can look up the revision number of the last release you’re comparing to, and then you can go through the Subversion log and look at the descriptions of the commits, which should hopefully be good enough to tell you what was done. Unless the last version was a stable release, I usually include a comparison to the last stable release as well, which is easy to create just by copying and pasting the lists from individual release notes together.

Available for download at http://drjava.org  .

DrJava is a lightweight programming environment for Java designed to
foster test-driven software development. It includes an intelligent
program editor, an interactions pane for evaluating program text, a
source level debugger, and a unit testing tool.

In addition to bug fixes, this  release
includes a number of new features introduced after the last
 release:



Note: Java 1.4 compatibility has been dropped. To use DrJava, you will
need Java 5 or newer.


New features since the last  release:
 - list of new features since the last beta/development release



Bug fixes since last  release:
 - list of bug fixes since the last beta/development release



New features since the last stable release:
 - list of new features since the last stable release



Bug fixes since the last stable release:
 - list of bug fixes since the last stable release

On the DrJava SourceForge page, upload the release notes into the new release’s folder. You can do that either using SFTP again or using the web upload by clicking on “Add File”. I just find that SFTP works better for uploading the multiple large files earlier in step 15.
On the DrJava SourceForge page, hover over “Develop” and click on “News” (or go to https://sourceforge.net/news/?group_id=44253, but that link has changed frequently). Click on “Submit” and paste the contents of the readme.txt file into the “Details” part. In the “Subject” line, I usually put something like “DrJava Development Release 20110205-r5425″. Press “Submit”.
Send an email to the following addresses: drjava@rice.edu, drjava-hackers@lists.sf.net, drjava-users@lists.sf.net
I use the same text that was used in step 23 for the SourceForge news, but I let the following text precede the email:
```
Dear DrJava Users:

We have made a new  version available: 

You can download it from the DrJava website at http://drjava.org/
or from SourceForge.net by following this link:



You receive this email because you have subscribed to a DrJava mailing list.
```
Replace the part with the link to the SourceForge page that has the files for this release, i.e. the website you navigated to in step 19. Example: https://sourceforge.net/projects/drjava/files/2.%20DrJava%20Development%20Releases/drjava-20110205-r5425/
SSH into CSnet as javaplt (e.g. ssh javaplt@finland.cs.rice.edu).
cd ~/public_html/drjava
Run the drjava-update-news script. This pulls the SourceForge news onto the DrJava website. Note that for now, this only happens on our CSnet mirror at http://www.cs.rice.edu/~javaplt/drjava/
drjava-update-news
Edit the LATEST_DEV_VERSION.TXT, LATEST_BETA_VERSION.TXT or LATEST_VERSION.TXT file, depending on whether you have a development, beta, or stable version. Put the new tag into the file. Make sure there is no newline at the end of the file!
If you made a stable release, you will want to remove the download links for the beta and development releases. Edit main.shtml and change the line
to
and
to
If you made a beta release, you want the hash mark for the #include of the beta.shtml file, but not for the devrelease.shtml file. If you made a development release, you probably want the hash mark for the devrelease.shtml file, but not for the beta.shtml file.
Do a similar thing as in step 29 for download.shtml. The corresponding lines are
and
Go to http://www.cs.rice.edu/~javaplt/drjava/ and check that the download buttons link to the right files, the ones that you have just released. It’s a good idea to download them all and run them, to make sure there were no upload errors.
Delete backup files:
rm *~
Copy the website to the SourceForge server using the drjava-cs-to-sf script. Note that it may also update Javadocs, test coverage, and other files.
drjava-cs-to-sf
That’s it! Thanks for helping make DrJava even better.

New DrJava Development Release: drjava-20110205-r5425

Mathias — Sat, 05 Feb 2011 19:36:52 +0000

We have made a new development release available: drjava-20110205-r5425. You can download it from the DrJava website or from SourceForge.

Available for download at http://drjava.org .

In addition to bug fixes, this development release includes a number of new features introduced after the last stable release:

The language level facility has been changed to consist of two language levels, Functional Java (corresponding to the old Intermediate level) and Full Java. The old files can still be compiled, but DrJava will ask if it should rename .dj0 and .dj1 to .dj and .dj2 files to .java.

DrJava’s compiler support has been improved, and DrJava now supports compiling files with file extensions other than .java, .dj, .dj0, .dj1, and .dj2. This includes support for Habanero Java .hj files, provided the Habanero Java compiler is installed.

DrJava preferences like indent level can now be stored on a per- project basis (see “Project Properties”, “Advanced”).

Note: Java 1.4 compatibility has been dropped. To use DrJava, you will need Java 5 or newer.

New features since the last stable release:

refactored language levels
improved compiler support, including support for Habanero Java
The contents of the Compiler Errors pane can now be copied the clipboard.
DrJava preferences like indent level can now be stored on a per-project basis (see “Project Properties”, “Advanced”).

Bug fixes since last stable release:

Applet viewer not started in event thread anymore to avoid exception
Static type checking for primitive casts in Interactions pane

Integrating the Habanero Java Race Detector into DrJava

Mathias — Mon, 22 Nov 2010 17:53:35 +0000

Jarred, Vincent and the guys of the Habanero Java group are planning to add a race detector to the Habanero Java compiler adapter in DrJava. I won’t have much time to help them with this, but I gave them some pointers.

Adding a race detector pane

I would probably use a panel that is shown in the “Tabbed Panes” part at the bottom of DrJava. You could look at JUnitPanel (extending ErrorPanel, which has a list of errors with file-and-line location information) or at BreakpointsPanel (extending RegionsTreePanel, which has a tree of documents, each having line numbers in them).

Specialized handler for race condition runtime exceptions

Right now, we have special treatment for OutOfMemoryError exceptions. This portion is in MainFrame.java:

1
2
3

else if (lastError.startsWith("java.lang.OutOfMemoryError")) {
askToIncreaseSlaveMaxHeap();
}

I don’t think this is the perfect place to put it, and we should probably refactor the code at some point so it doesn’t fill up MainFrame even more, but this is the simplest place to extend DrJava. That’s where you could display the race condition pane.

There is one problem: Since the exception is thrown in another JVM (interpreter JVM) and then passed to the JVM where the main DrJava IDE is running (main JVM), the exception would have to be serializable. Right now, we just pass a string, not the exception itself. Unless you want to change the current design, you probably have to put the file and line number information into the string and then parse it again in the IDE.

Compilation options for the Habanero Java compiler adapter

You can create a panel in the Preferences pane in ConfigFrame.java and add options in OptionConstants.java. Then, in HjCompiler.transformHJCommand, you can check the state of those options, e.g. using DrJava.getConfig().getSetting(HJ_USE_RACE_DETECTION) or something like that, to create the appropriate command line.

DrJava Listed in Overview of Java IDEs

Mathias — Mon, 22 Nov 2010 15:29:52 +0000

DrJava was included in this overview of Java IDEs:

Dr. Java- This is a lightweight IDE geared towards students in introductory level classes, including the Advanced Placement Computer Science course. Dr. Java has support for evaluating snippets of code without compiling them. In addition, Dr. Java supports the AP Computer Science GridWorld API, having features to aid developers in getting it setup as well as some basic GridWorld tutorials.

One commenter even listed DrJava as his favorite. I agree, but I’ve probably made DrJava organically grow around me.

DrJava Preferences Stored in Project Files

Mathias — Tue, 16 Nov 2010 06:55:15 +0000

I told myself I wouldn’t work on DrJava anymore, but here I go again. I Implemented feature request 3081586, Store Preferences within Projects, mainly because this was something I had wanted for a long time (I kept going back and forth between indent levels of 2 and 4), and because Corky had requested the language level setting to be stored in project files. This feature request was more general than what he wanted, but I think it was what DrJava needed.

There now is an “Advanced” button on the “Project Properties” dialog that takes the user to a secondary window. In that window, the user can list (by name, using predictive input) those preferences that should be saved in the project file.

Note that for simplicity, the actual values are still configured in the “Preferences” window (Edit menu). This list only names the preferences whose values should be stored in the project file when the project is saved, and restored when the project is loaded again.

By default and for new projects, the language level and the indent level are saved in the project file and restored upon loading of the project.

For existing projects, you can cause DrJava to store the language level in the project file by going to Project Properties, clicking the new “Advanced” button in the bottom left corner, pressing the “Add” button underneath the list, and entering “Language Level”. Once you press OK to add that preference to the list, and OK to close the “Advanced” window, and then “OK” to close the Project Properties window, DrJava will store the language level in the project file.

Now I can set the indent level to 2 for DrJava and to 4 for most other projects. So can you if you grab the latest weekly build of DrJava.

Spam on the DrJava SourceForge Trackers

Mathias — Wed, 20 Oct 2010 23:28:50 +0000

We’ve been getting tons of pharmaceutical spam on the DrJava trackers (bug reports, feature requests, support requests) today. Unfortunately, when it comes to limiting the amount of spam from automated bots, the only mechanism that SourceForge provides is requiring users to register for a SourceForge account.

I don’t like doing this, but at this point, it seems like it’s the only simple action we can take. There are more advanced “hosted apps” that can be used for bug tracking, but I have not evaluated any of them.

If you feel strongly that we should allow anonymous postings again, please let me know.

Another DrJava User Site: University of Western Ontario

Mathias — Mon, 18 Oct 2010 02:41:34 +0000

I found another university that uses DrJava in its CS curriculum: The University of Western Ontario teaches CS 1026: Computer Science Fundamentals I using DrJava.

The course is based on Mark Guzdial’s and Barbara Ericson’s Media Computation textbook. Having had Georgia Tech as clients has certainly been most beneficial for DrJava.

I have added UWO to the list of DrJava user sites.