Menu
▾
▴
drjava-hackers — DrJava developers mailing list
You can subscribe to this list here.
| 2002 |
Jan
(17) |
Feb
(80) |
Mar
(56) |
Apr
(79) |
May
(9) |
Jun
(60) |
Jul
(29) |
Aug
(40) |
Sep
(23) |
Oct
(6) |
Nov
(25) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(17) |
Feb
(85) |
Mar
(22) |
Apr
(3) |
May
(18) |
Jun
(27) |
Jul
(38) |
Aug
(19) |
Sep
(15) |
Oct
(6) |
Nov
(2) |
Dec
(5) |
| 2004 |
Jan
(19) |
Feb
(26) |
Mar
(30) |
Apr
(29) |
May
(8) |
Jun
(28) |
Jul
(39) |
Aug
(17) |
Sep
(19) |
Oct
(12) |
Nov
(18) |
Dec
(9) |
| 2005 |
Jan
(5) |
Feb
(18) |
Mar
(4) |
Apr
(5) |
May
(9) |
Jun
(10) |
Jul
(15) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(11) |
Dec
(6) |
| 2006 |
Jan
(10) |
Feb
(27) |
Mar
(24) |
Apr
(39) |
May
(14) |
Jun
(14) |
Jul
(5) |
Aug
(15) |
Sep
(21) |
Oct
(25) |
Nov
(10) |
Dec
(6) |
| 2007 |
Jan
(19) |
Feb
(23) |
Mar
(10) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
(23) |
Feb
(13) |
Mar
(19) |
Apr
(11) |
May
(11) |
Jun
(10) |
Jul
(12) |
Aug
(19) |
Sep
(11) |
Oct
(4) |
Nov
(6) |
Dec
|
| 2009 |
Jan
(8) |
Feb
(15) |
Mar
(21) |
Apr
(12) |
May
(14) |
Jun
(9) |
Jul
(2) |
Aug
(17) |
Sep
(36) |
Oct
(31) |
Nov
(13) |
Dec
(13) |
| 2010 |
Jan
(24) |
Feb
(17) |
Mar
(32) |
Apr
(18) |
May
(9) |
Jun
(6) |
Jul
(11) |
Aug
(18) |
Sep
(7) |
Oct
(20) |
Nov
(5) |
Dec
(4) |
| 2011 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
|
| 2013 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James I-C. H. <jh...@ow...> - 2004-03-31 22:07:08
|
This development release of DrJava contains support for the Java 1.5.0 beta compiler as well as the JSR14v2.5 compiler. Also, only one compiler per version of compiler is now shown. For example, users will only see one java 1.4.1 compiler. Please download and test this release as your primary copy of DrJava. James |
|
From: Charles R. <creis@u.washington.edu> - 2004-03-31 02:31:21
|
Hey Peter-- From what I've heard from James, the newest versions of JSR-14 (and presumably 1.5) are able to compile with 1.3 as a target, and it actually works. So that's great news for using new language features in the DrJava source. I agree that a new build of the plug-in should be released, whenever you guys have time. Charlie Peter Centgraf wrote: > Hello again, > > Since many of the new features in the recent stable release are related > to the interactions pane, it would be nice to have a new build of the > Eclipse plugin that takes advantage of the improvements. Could someone > on the team make a new release? > > Also, I've discovered that the latest CVS of our modified DynamicJava > contains 1.5-style wildcard types. Are we officially discontinuing J2SE > 1.3 support, or is there some way to compile with a recent JSR-14 > version and still support 1.3? > > -- > Peter Centgraf > Research Programmer, > Human-Computer Interaction Institute > Carnegie Mellon University > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > drjava-hackers mailing list > drj...@li... > https://lists.sourceforge.net/lists/listinfo/drjava-hackers |
|
From: Peter C. <cen...@cm...> - 2004-03-29 08:11:46
|
Hello again, Since many of the new features in the recent stable release are related to the interactions pane, it would be nice to have a new build of the Eclipse plugin that takes advantage of the improvements. Could someone on the team make a new release? Also, I've discovered that the latest CVS of our modified DynamicJava contains 1.5-style wildcard types. Are we officially discontinuing J2SE 1.3 support, or is there some way to compile with a recent JSR-14 version and still support 1.3? -- Peter Centgraf Research Programmer, Human-Computer Interaction Institute Carnegie Mellon University |
|
From: James I-C. H. <jh...@ow...> - 2004-03-26 23:36:28
|
A new stable version of DrJava, drjava-stable-20040326, has just been released! This version includes new features, along with numerous bug fixes and usability improvements. The most notable changes include the automatic insertion of newlines when an interaction in not complete, the ability to search backwards through history by typing the first few letters of a previous command and hitting Tab, the ability to find/replace only whole words, and an improved undo function that removes series of typed text at once. Buttons have been added to error panels to allow easier scrolling through errors. More detailed information can be found in the Release Notes. Please download this version from http://drjava.org and use it as your primary copy of DrJava. We welcome any feedback you have on this release; please submit any suggestions or difficulties as feature requests and bug reports on our SourceForge site. Thanks! James |
|
From: SourceForge.net <no...@so...> - 2004-03-26 20:43:32
|
Bugs item #924181, was opened at 2004-03-26 12:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=924181&group_id=44253 Category: Interactions Group: Would be nice if fixed ... Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Error when working with strings in Interactions pane Initial Comment: While experimenting with some of the methods in the String class in the Interactions pane, DrJava encountered an unexpected exception: java.lang.IllegalArgumentException: startRow is beyond the end of the string at edu.rice.cs.util.StringOps.getOffsetAndLength (StringOps.java:139) at edu.rice.cs.drjava.model.repl.InteractionsModel.replRetur nedSyntaxError(InteractionsModel.java:671) at edu.rice.cs.drjava.model.repl.InteractionsModel.interpret CurrentInteraction(InteractionsModel.java:224) at edu.rice.cs.drjava.ui.InteractionsController$10.construct (InteractionsController.java:403) at edu.rice.cs.util.swing.SwingWorker$2.run (SwingWorker.java:157) at java.lang.Thread.run(Thread.java:536) The About info: DrJava Version : 20040323-0318 DrJava Configuration file: C:\Documents and Settings\Steven\.drjava Copyright © 2001-2003 JavaPLT group at Rice University (ja...@ri...) See http://www.drjava.org for more information on DrJava or to obtain the latest version of the program or its source code. DrJava is free software; you can redistribute it and/or modify it under the terms of the DrJava Open Source License. A copy of the license should have been included in the documentation for this software. The line that caused the error: s.split(new String(new Character((char)9).toString() ) ; I'm using the latest beta of DrJava under Windows XP SP1 with Java SDK 1.4.1_03 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=924181&group_id=44253 |
|
From: Charles R. <creis@u.washington.edu> - 2004-03-26 05:05:12
|
> I also like the changes to group text operations into single undo/redo > blocks. However, the current implementation ignores use of the delete > key. Although text additions are grouped, text deletes are not. This > makes for somewhat odd undo/redo behavior. You may want to patch that > before the stable, for consistency. I agree-- a deletion should end a block of consecutive additions, but several consecutive deletions should also be treated as a single block (eg. until the next addition, etc.). Don't know if that's feasible before the stable, but hopefully with a unit test it shouldn't be too hard. Charlie |
|
From: Peter C. <pe...@ce...> - 2004-03-26 04:55:05
|
Hi guys, Like Charlie, I'm loving the new changes, especially in the interactions pane. The conditional return handling is a really nice use of the pre-processor. I also like the changes to group text operations into single undo/redo blocks. However, the current implementation ignores use of the delete key. Although text additions are grouped, text deletes are not. This makes for somewhat odd undo/redo behavior. You may want to patch that before the stable, for consistency. Hopefully I'll be contributing more actively soon. (I'm trying to negotiate for an independent study course to work on UI issues in DrJava.) Keep up the good work! -- Peter Centgraf Master of HCI Student (and DrJava Developer) Carnegie Mellon University |
|
From: James I-C. H. <jh...@ow...> - 2004-03-25 21:53:26
|
The latest changes I've made to DrJava can be found in a jar at http://www.owlnet.rice.edu/~jhsia/drjava.jar Try it out before tomorrow and send comments! Changed the option from "JVM Args" to "JVM Args for Interactions" A warning dialog pops up when saving a file with '#' in its path (bug 885248). Changed the status bar so that the file name is overwritten instead of the find/replace message. This works better since the find/replace message can always be removed by closing the pane or switching to a different one. The prev/next error buttons in the error panels do not become disabled when moving the cursor in the Definitions Pane; the current error is maintained. James |
|
From: Charles R. <creis@u.washington.edu> - 2004-03-25 03:24:23
|
Hey folks-- Is there any chance of getting the "#"-in-folder-name bug fixed for the stable, or is that too deep a problem? https://sourceforge.net/tracker/?func=detail&atid=438935&aid=885248&group_id=44253 Thanks, Charlie |
|
From: Charles R. <creis@u.washington.edu> - 2004-03-24 17:18:47
|
I've been working with the beta release, and some of the new features are great. Just thought I'd send back a few comments to help polish it up for the stable release... - The "JVM Args" option in the preferences is not at all descriptive about what it means. The tool tip helps, but I bet most people don't look at that. What about "JVM Args for Interactions"? - It looks like the beta release was not compiled with the "stable" Ant target (ie. the CodeStatus.DEVELOPMENT flag is true). I don't know if there's anything new using that flag-- the only thing I know of is the "Anti-aliased text in Definitions" option, since we never figured out a reasonable default behavior for OS X, where the text is already anti-aliased. I'll let you decide whether to include the feature in the stable release, but make sure DEVELOPMENT is false (using "ant commit-stable"). - The status text for Find is now in the status bar, and it isn't legible if a long filename is open. Not sure if there's an easy way to improve this. - The new buttons on the error panels are really useful. I found an annoying quirk with the enable/disable behavior, though (which I lobbied strongly for in the first place). If you click on an error, the buttons are properly enabled depending on whether you are at the start or end of the list. But if you fix the error in the Definitions Pane and your caret happens to move to another line (eg. if the error was actually on the previous line), both error buttons are disabled! This causes you to lose your place pretty quickly. Not sure exactly what the right behavior is-- what about not changing the enabled state of the buttons unless you reach or leave one end of the list or recompile/test/etc? (That way you could always click next...) That's it for now-- great work so far! Charlie |
|
From: SourceForge.net <no...@so...> - 2004-03-24 06:01:37
|
Bugs item #922228, was opened at 2004-03-24 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=922228&group_id=44253 Category: Compiler integration Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Bradley M. Wagner (beamer908) Assigned to: Nobody/Anonymous (nobody) Summary: Not compatible with sdk 1.5.0 beta Initial Comment: I don't know if you guys are planning on supporting the beta release of 1.5, but DrJava says that there's a problem with the tools.jar file in the 1.5 lib directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=922228&group_id=44253 |
|
From: James I-C. H. <jh...@ow...> - 2004-03-23 04:35:00
|
There is a new beta release of DrJava made in preparation for the next stable release (http://drjava.org). The primary features added to this release relate to improving the Interactions Pane. First, uninitialized variables are assigned the correct default value and initialization of multi-dimensional arrays now works correctly. Second, newlines are automatically inserted for users if the current interaction is not yet complete. This makes defining methods and classes in the Interactions Pane much easier. Third, users can type in the first few letters of a command in the history and hit the Tab key to cycle through all commands that begin with that sequence of letters. Fourth, the minimum size of the bottom pane has been reduced to allow more room for editing files. Other changes include an improved undo command that can now undo series of typed text at a time. Forward brace matching has been added as well. Also, using System.in will no longer cause DrJava to hang in some cases. Please download this beta release and use it as your primary copy of DrJava, submitting any bugs that you find. We intend to release a stable version of DrJava based on this release by the end of this week, depending on the feedback we receive. Thanks for your help with DrJava! James |
|
From: James I-C. H. <jh...@ow...> - 2004-03-16 05:37:10
|
This development release of DrJava includes a large number of bug fixes, a couple of new features, and an interface improvement. The new features improve the usability of the Interactions Pane by automatically inserting newlines when the interactions is detected to not be complete. This makes declaring methods and classes much easier. Also, typing in the first few characters of previous commands allows you to hit Tab to search backwards in history through the commands that begin with those characters. We are trying to release a beta within a couple of days so please download and test this release as your primary copy of DrJava, reporting any bugs you may find (http://drjava.org). James |
|
From: SourceForge.net <no...@so...> - 2004-03-16 02:46:54
|
Bugs item #917054, was opened at 2004-03-15 21:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=917054&group_id=44253 Category: Interactions Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Tristen (tpierson) Assigned to: Nobody/Anonymous (nobody) Summary: Interactions Reset Bug Initial Comment: DrJava Version : 20040213-2314 OS: Windows 2000 Professional/XP Professional JDK: 1.4.2.03 The bug is provoked under the following case: 1) The user compiles the current document. 2) The user runs the documents main method. 3) The user resets interactions while the program is running. 4) The user attempts to run the documents main method again. This bug has only happened while the interactions were handling the console input where the interactions would lock up after pushing the return key. The program only locks up if the above case has been done. I've had this bug while using custom input super methods, but the problem may occur with other types of interactions. The temporally solution to this problem is recompiling the program and then running the documents main method again. I believe that this is a bug in the interactions, however I use a collection of input super methods that may have something to do with that, however I've been bug searching all week along with several colleges of mine. My school has changed our Java IDE from KAWA to DrJava and the students are starting to grow frustrated as I try to explain to them the cause of our problem. Your help would be most appreciated! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=917054&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-03-14 07:07:45
|
Bugs item #915906, was opened at 2004-03-14 07:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=915906&group_id=44253 Category: Interactions Group: Serious Status: Open Resolution: None Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Methods in Interactions no longer work Initial Comment: As of the 20040203-2304 development release, methods can no longer be defined in the Interactions Pane. (The current stable release works fine.) > void foo() {} Error: Bad types in assignment > void foo(Object o) { String s = o.toString(); } java.lang.ClassCastException: As a side note, the return value of a void method shows up as "null" in the Interactions Pane for the stable release. We should be detecting it and using the VoidResult class in model/repl/newjvm/... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=915906&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-03-13 23:23:00
|
Feature Requests item #915804, was opened at 2004-03-13 23:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=915804&group_id=44253 Category: Other Group: Unknown size Status: Open Priority: 5 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: Update FAQ re: ObjectDraw Initial Comment: We received complaints at SIGCSE '04 about using the ObjectDraw library from Williams to support applet development in DrJava. There's an entry in the FAQ about it, and I seem to remember it working in the past. However, it appears that ObjectDraw does not properly call the applet's init method (which seems like a huge problem). In the short run, we should update the FAQ to reflect the bug. We should also see if there's a better solution available (or a way to fix the bug in ObjectDraw). (I know there's a proprietary solution available, but that's not a great option for most of our users. We might post a link to it, though.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=915804&group_id=44253 |
|
From: SourceForge.net <no...@so...> - 2004-03-13 23:19:23
|
Feature Requests item #915803, was opened at 2004-03-13 23:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=915803&group_id=44253 Category: Other Group: Small (< 1 pair-week) Status: Open Priority: 6 Submitted By: Charles Reis (csreis) Assigned to: Nobody/Anonymous (nobody) Summary: More visible "shift+enter" docs Initial Comment: We received comments at SIGCSE '04 that users were unable to figure out how to enter multiple line commands in the Interactions Pane. While other feature requests are under way to improve the Interactions Pane in this respect, it's also important to make sure that the documentation for "shift+enter" is more visible in DrJava's help files. Notes: this is a good chance for people to get used to updating the documentation (as described in the developer docs). This is also a good chance to figure out why newer versions of docbook2html (like on greenland) generate the wrong names for the output (ie. no index.html). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=915803&group_id=44253 |
|
From: Charles R. <cr...@cs...> - 2004-03-10 23:27:21
|
> (Wacky idea: If startup really does take a long time and that can't be > fixed, how about starting a "hot-spare" VM in the background and > swapping to it when the user resets the interactions window?) That's a really interesting thought... I don't think it should be the default, because having 3 JVMs running with less than about 256 MB of memory will likely kill performance, but for people with plenty of RAM to spare, that could be a nice speedup. Not exactly high priority, but it could be a cool side project. I wonder how messy the synchronization issues would be. Charlie |
|
From: Hal P. <pe...@cs...> - 2004-03-10 23:18:10
|
My take on this - #1 sounds right, but the delay to restart has to be pretty reasonable. (Wacky idea: If startup really does take a long time and that can't be fixed, how about starting a "hot-spare" VM in the background and swapping to it when the user resets the interactions window?) #2 depends on how it's done. We don't want the students to react to the display of the root directory by saying "oh! So that's where the computer wants me to put the file!". Hal -----Original Message----- From: Robert Cartwright [mailto:co...@cs...]=20 Sent: Tuesday, March 09, 2004 12:16 PM To: Hal Perkins Cc: Charles S Reis; drj...@li...; Douglas W Johnson Subject: Re: [DrJava] RE: Current Directory Debate My off-the-cuff opinions: 1. Executing "java <classname>" in the interactions pane should reset=20 the interactions pane. 2. Perhaps the root for file path names in the interactions pane should=20 be displayed when a file is not found so that students know why their command failed. -- Corky =20 |
|
From: Charles R. <creis@u.washington.edu> - 2004-03-10 08:00:53
|
Unfortunately, we've investigated this before, and that approach only=20 works the first time you change the "user.dir" property. It's also=20 explicitly (purposely) undocumented in the JVM specs, so there are=20 likely JVMs that do not implement this behavior. (I haven't tried it on=20 Apple's JVM.) There are many discussions about the issue on=20 groups.google.com and the Java forums, but it boils down to the fact=20 that this approach isn't reliable or recommended... Charlie Jonathan Lugo wrote: > In terms of implementation, I believe it is quite easy to=20 > programmatically change the default abstract path used by most file IO.= =20 > The java.io.File class uses the System property, =93user.dir=94 when=20 > determining the file=92s absolute path. This property is easily change= d=20 > by using the following code: >=20 > =20 >=20 > System.setProperty(=93user.dir=94, =93<<default directory>>=94);. >=20 > =20 >=20 > I ran the following code in the interactions pane and it successfully=20 > changed the output of the getAbsolutePath() method of a java.io.File=20 > object. It also worked on java=92s XML parser. If this system change=20 > could be made in the interactions pane, could it be done as easily=20 > behind the scenes by drjava? We could have some sort of code that=20 > chooses a good default based on the open/selected files that can be=20 > overruled by the user easily. There could be a =93change current worki= ng=20 > directory=94 button on the interactions pane. This concept could also = be=20 > applied to Unit testing just incase. >=20 > =20 >=20 > I admit that I have not thoroughly researched the repercussions of=20 > changing this system property, but I know the change lasted only until = I=20 > reset the interactions pane again. >=20 > =20 >=20 > - Jonathan Lugo >=20 |
|
From: Jonathan L. <jl...@ri...> - 2004-03-10 05:57:16
|
In terms of implementation, I believe it is quite easy to programmatically
change the default abstract path used by most file IO. The java.io.File
class uses the System property, "user.dir" when determining the file's
absolute path. This property is easily changed by using the following code:
System.setProperty("user.dir", "<<default directory>>");.
I ran the following code in the interactions pane and it successfully
changed the output of the getAbsolutePath() method of a java.io.File object.
It also worked on java's XML parser. If this system change could be made in
the interactions pane, could it be done as easily behind the scenes by
drjava? We could have some sort of code that chooses a good default based
on the open/selected files that can be overruled by the user easily. There
could be a "change current working directory" button on the interactions
pane. This concept could also be applied to Unit testing just incase.
I admit that I have not thoroughly researched the repercussions of changing
this system property, but I know the change lasted only until I reset the
interactions pane again.
- Jonathan Lugo
|
|
From: Robert C. <co...@cs...> - 2004-03-09 20:32:50
|
My off-the-cuff opinions: 1. Executing "java <classname>" in the interactions pane should reset the interactions pane. 2. Perhaps the root for file path names in the interactions pane should be displayed when a file is not found so that students know why their command failed. -- Corky |
|
From: Hal P. <pe...@cs...> - 2004-03-09 19:46:32
|
Sorry for the multiple replies, but one other thought.
This issue shows up for even the mainstream students when an assignment
involves reading files. "new FileReader("data.txt")" doesn't work right
if the default directory is the one containing DrJava. Students
shouldn't be learning that to read files, one must put them in the
DrJava directory.
Hal
-----Original Message-----
From: Hal Perkins=20
Sent: Tuesday, March 09, 2004 11:19 AM
To: Charles S Reis; drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: RE: Current Directory Debate
To expand on Charlie's note a bit.
We often assign projects that are open-ended to give the more ambitious
students a chance to challenge themselves by extending the basic
requirements. It often happens that they want to use image files for
fancier graphics or buttons or whatever. The trouble is that when they
run an application and try to load an image file using a simple filename
("fish.gif", or "images/fish.gif") it fails because the default
directory is related to DrJava, not to their application. This is also
a problem with most of the sample programs found in, for example, the
Sun Swing tutorial. Those work fine if you're running them from a
command line, but they fail in DrJava.
The getResource() solution is the right one for more sophisticated
programs and for when a program is packaged as a .jar file. You could
tell students just to do it, but it involves concepts that even
ambitious beginners are likely to find confusing, and it doesn't address
the issue of being able to run simple demo applications found in the
Java tutorial or other sources.
The other hack that some students have discovered is to put their files
in the same folder containing DrJava. That's ugly and should be
discouraged - there should be a clean separation between the folders
containing the development environment and the folders containing the
multiple Java projects created throughout the course. I find it really
annoying when this "solution" surfaces on the class discussion list,
giving students the idea that this is an appropriate way to solve the
problem.
The key issue is that simple file references from programs ought to work
more-or-less as expected, meaning finding the files relative to the
class files that are running. Whether that involves resetting the
interactions window when an application is launched, or whether there is
some other way to do it is an implementation issue.
Hal
-----Original Message-----
From: Charles Reis [mailto:cr...@cs...]=20
Sent: Tuesday, March 09, 2004 10:47 AM
To: drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: Current Directory Debate
In the context of UW's intro course, the instructors and I have been=20
having a discussion about the "current directory" issue of DrJava's=20
Interactions pane. As a reminder, here's the facts so far:
1) Opening any file with a relative path name loads it relative to the=20
directory where the JVM was started. For the Interactions pane, that's=20
currently the directory where DrJava was started, not the directory of=20
the open class files.
2) An appropriate way to load files in production code is=20
getClass().getResource("myfile.jpg"), which loads files from the same=20
directory as the class file, returning a URL. This is arguably far too=20
complex for CS1 students.
3) You can't change the current directory of a JVM after it's started.
Given those, our position has been to make people use getResource,=20
since that has the expected behavior in most cases, and it's definitely=20
unclear which directory we would put the Interactions pane in if=20
multiple files from different folders are open in DrJava.
However... in the interest of creating a better heuristic which=20
might be more convenient, we've discussed what happens when DrJava runs=20
the main method of a class (either through a menu item or by typing=20
"java Classname"). We do not currently reset the Interactions pane to=20
run main(), but it's arguable that we *should* provide a clean slate,=20
despite the extra time it takes to reset. (It's more in tune with what=20
the user expects to happen.) If that change were made, then the JVM=20
could be started in the correct directory to load relative paths in the=20
case of running a main method.
Note that any normal reset wouldn't attempt to change the directory;=20
only running the main method of a class would. This could still lead to
some confusing behavior if the user tries to load files in the=20
Interactions pane after an invocation of main vs. after a clean reset,=20
but that's arguably much less likely than expecting main to run from the
class's directory.
Please let us know your opinions on this, and whether it's a good=20
idea to move DrJava in this direction.
Thanks!
Charlie
|
|
From: Hal P. <pe...@cs...> - 2004-03-09 19:36:31
|
To expand on Charlie's note a bit.
We often assign projects that are open-ended to give the more ambitious
students a chance to challenge themselves by extending the basic
requirements. It often happens that they want to use image files for
fancier graphics or buttons or whatever. The trouble is that when they
run an application and try to load an image file using a simple filename
("fish.gif", or "images/fish.gif") it fails because the default
directory is related to DrJava, not to their application. This is also
a problem with most of the sample programs found in, for example, the
Sun Swing tutorial. Those work fine if you're running them from a
command line, but they fail in DrJava.
The getResource() solution is the right one for more sophisticated
programs and for when a program is packaged as a .jar file. You could
tell students just to do it, but it involves concepts that even
ambitious beginners are likely to find confusing, and it doesn't address
the issue of being able to run simple demo applications found in the
Java tutorial or other sources.
The other hack that some students have discovered is to put their files
in the same folder containing DrJava. That's ugly and should be
discouraged - there should be a clean separation between the folders
containing the development environment and the folders containing the
multiple Java projects created throughout the course. I find it really
annoying when this "solution" surfaces on the class discussion list,
giving students the idea that this is an appropriate way to solve the
problem.
The key issue is that simple file references from programs ought to work
more-or-less as expected, meaning finding the files relative to the
class files that are running. Whether that involves resetting the
interactions window when an application is launched, or whether there is
some other way to do it is an implementation issue.
Hal
-----Original Message-----
From: Charles Reis [mailto:cr...@cs...]=20
Sent: Tuesday, March 09, 2004 10:47 AM
To: drj...@li...
Cc: Douglas W Johnson; Hal Perkins
Subject: Current Directory Debate
In the context of UW's intro course, the instructors and I have been=20
having a discussion about the "current directory" issue of DrJava's=20
Interactions pane. As a reminder, here's the facts so far:
1) Opening any file with a relative path name loads it relative to the=20
directory where the JVM was started. For the Interactions pane, that's=20
currently the directory where DrJava was started, not the directory of=20
the open class files.
2) An appropriate way to load files in production code is=20
getClass().getResource("myfile.jpg"), which loads files from the same=20
directory as the class file, returning a URL. This is arguably far too=20
complex for CS1 students.
3) You can't change the current directory of a JVM after it's started.
Given those, our position has been to make people use getResource,=20
since that has the expected behavior in most cases, and it's definitely=20
unclear which directory we would put the Interactions pane in if=20
multiple files from different folders are open in DrJava.
However... in the interest of creating a better heuristic which=20
might be more convenient, we've discussed what happens when DrJava runs=20
the main method of a class (either through a menu item or by typing=20
"java Classname"). We do not currently reset the Interactions pane to=20
run main(), but it's arguable that we *should* provide a clean slate,=20
despite the extra time it takes to reset. (It's more in tune with what=20
the user expects to happen.) If that change were made, then the JVM=20
could be started in the correct directory to load relative paths in the=20
case of running a main method.
Note that any normal reset wouldn't attempt to change the directory;=20
only running the main method of a class would. This could still lead to
some confusing behavior if the user tries to load files in the=20
Interactions pane after an invocation of main vs. after a clean reset,=20
but that's arguably much less likely than expecting main to run from the
class's directory.
Please let us know your opinions on this, and whether it's a good=20
idea to move DrJava in this direction.
Thanks!
Charlie
|
|
From: Charles R. <cr...@cs...> - 2004-03-09 19:04:24
|
In the context of UW's intro course, the instructors and I have been
having a discussion about the "current directory" issue of DrJava's
Interactions pane. As a reminder, here's the facts so far:
1) Opening any file with a relative path name loads it relative to the
directory where the JVM was started. For the Interactions pane, that's
currently the directory where DrJava was started, not the directory of
the open class files.
2) An appropriate way to load files in production code is
getClass().getResource("myfile.jpg"), which loads files from the same
directory as the class file, returning a URL. This is arguably far too
complex for CS1 students.
3) You can't change the current directory of a JVM after it's started.
Given those, our position has been to make people use getResource,
since that has the expected behavior in most cases, and it's definitely
unclear which directory we would put the Interactions pane in if
multiple files from different folders are open in DrJava.
However... in the interest of creating a better heuristic which
might be more convenient, we've discussed what happens when DrJava runs
the main method of a class (either through a menu item or by typing
"java Classname"). We do not currently reset the Interactions pane to
run main(), but it's arguable that we *should* provide a clean slate,
despite the extra time it takes to reset. (It's more in tune with what
the user expects to happen.) If that change were made, then the JVM
could be started in the correct directory to load relative paths in the
case of running a main method.
Note that any normal reset wouldn't attempt to change the directory;
only running the main method of a class would. This could still lead to
some confusing behavior if the user tries to load files in the
Interactions pane after an invocation of main vs. after a clean reset,
but that's arguably much less likely than expecting main to run from the
class's directory.
Please let us know your opinions on this, and whether it's a good
idea to move DrJava in this direction.
Thanks!
Charlie
|
25 messages has been excluded from this view by a project administrator.
