Frequently Asked Questions

Why does "from file" in the "Command Line Interface" window cause MacJikes to crash? (2-16-1999)

"From file" does not do what you think it does. This is a left-over from the unix world. "From file" redirects standard-input or standard-output (whichever you choose) to come from, or be sent to a file! DO NOT choose .java files in either of these dialogs.

I have not tested this myself, but try this... If you want to compile java files based on a file that contains a list of files, try this in the text-edit field in place of any filenames: 

	@filesToCompile
Where filesToCompile is a file in the same directory as MacJikes and contains a return-delimited list of files you want to compile. ie: 
	'Macintosh HD:Work files:java:MyProgram.java'
	'Macintosh HD:Work files:java:MyOtherProgram.java'
Yes, this should work from AppleScript also. Yes, I now understand that MacJikes' user interface needs a major overhaul. Please use AppleScript with MacJikes in the interim. The next release will be directed toward making MacJikes much more intuitive to use.

How come the applet shows up in a small portion of the screen in my web browser?

Because it works best from a "appletviewer" program rather than from a web browser. Use Apple Appletrunner (the default filetype) to view the applet. You'll be able to resize the window, but even then, to see everything, you might need a monitor > 640x480.

Is Jikes an optimizing Java compiler?

Basically, there is only one way to parse most Java constructs. Also, there are some Verification and Serialization versioning bugs, but they are being worked out. From the Jikes mailing list: 
Date: Wed, 10 Feb 1999 11:14:27 -0500
From: shieldsd@us.ibm.com
Subject: [Jikes] Re: Jikes and JIMI - a perfect marriage?

Rick,

Re 1: Jikes doesn't do *any* optimization or inlining. All "-O" means to
Jikes is to suppress the line number table. In general we have found that
javac and Jikes emit essentially the same code, as there is usually only
one way to process a particular construct (one of the strengths of the JVM
design).

 We have seen claims that code produced by Jikes is faster, but no one has
ever sent us any hard evidence of this. Class files produced by Jikes are
sometimes smaller, as we only put something in the constant pool if there
is a reference to it, but this should make little practical difference.

Re 2: We don't do any inlining. I recall John Rose from Sun's team saying
at a presentation at the last JavaOne that Sun would be doing less and less
optimization in the front end, as their experience had been that overly
aggressive optmization could produce security problems, and they felt all
optimization should be done at run time,  such as by using HotSpot, etc.

Re 3: We get occasional reports about code produced by Jikes failing
verification. We try to fix them as we can, though we're still catching up
with the backlog of problem reports received before (while we were busy
getting it out) and after release of Jikes in source form. It can be hard
to track such problems down as the verifier doesn't always pinpoint the
cause of verification failure.

We have received reports of problems with JIT's. We suspect this is because
JIT's are usually developed and tested in the context of a particular front
end, and so "learn their master's voice", but may not work with other front
ends. For example, early versions of the IBM's JIT for OS/2 failed as it
hadn't been told about the "nop" operator. We've also gotten a few
complaints about failures running with Symantec's JIT.

This suggests you might be better off continuing to build your final
release version using javac, or whatever other compiler is appropriate. We
know of several companies, including IBM for some projects, that do their
development using Jikes and then do final build using javac, we also know
of others that do build production versions using Jikes.

Re Jikes news, we've just finished implementing the language extensions
added in latest JDK 1.2 (aka Java 2), and hope to post a new version
shortly. If you haven't yet done so, I encourage you to subscribe to our
mail lists -- instructions for doing so can be found at
http://www.ibm.com/research/jikes.

thanks,
dave

PS to Jikes list; Rick is head of Java Lobby (30,000+ members). His company
was also a finalist in the recent JavaWorld awards (as was Jikes, in a
different category).

PS to Rick: Good to see you at the NYC Java UG meeting. If you're going to
LinuxWorld Expo in San Jose in March, look for me in the IBM booth.



"Rick Ross"  on 02/10/99 08:19:59 AM

To:   shields@watson.ibm.com
cc:   Luke Gorrie  (bcc: David Shields/Watson/IBM)
Subject:  Jikes and JIMI - a perfect marriage?





Dear Dave,

We're considering switching to Jikes to produce our final, distributable
copies of the JIMI graphics libraries. I have a few questions from our lead
develoepr (who is a big fan of Jikes):

1 - Is optimized output from Jikes typically at least as fast or faster
than
optimized output from javac? Are there any circumstances where you know
Jikes will produce slower code? How aggessive are your optimizations in
Jikes?

2 - We have encountered illegal optimizations in javac (ie - protection
violations w/inlining). Isn't this one of the specific places where Jikes
will be more rigorously adherent to specs?

3 - Are there any gothcha's we need to be aware of? Particularly, are there
any points where the non-compliant MS VM's will puke on classes compiled by
Jikes, even though Jikes may be producing correct bytecode? Are there any
known problems with other major VM's, again even though Jikes may be
producing legal and correct bytecodes?

Please reply ASAP - we've been using Jikes for internal development for a
long time now, but we have been switching to javac for final production.
We'd like to make the leap to Jikes only, and your input here will help a
lot.

Best regards,
Rick

To learn more about this mailing list, including disclaimers and how to
end your subscription, see http://www.ibm.com/research/jikes/subscribe .

IO Redirection

stdin (the left dialog io-redirector): dont use it. Passing a file with a commmand line in it causes crashes.

stdout should be able to redirect to a file just fine.

When all else fails (1-28-99)

  1. Move the compiler to the base of your source hierarchy.
  2. Copy (or move) your .jar and .zip classpath files to the same directory as MacJikes.
  3. Form the command line like this 
    -classpath :MRJClasses.zip,:JDKClasses.zip,:Everything.jar MySource.java

Example command lines and misc notes (1-28-99)

-classpath 'Macintosh HD:System Folder:Extensions:MRJ Libraries:MRJClasses:JDKCl asses.zip,Macintosh HD:System Folder:Extensions:MRJ Libraries:MRJClasses:MRJClas ses.zip,Macintosh HD:SDKs:Swing-1.1:swingall.jar' 'Macintosh HD:dev:java:MyClass.java '

Note that any pathname that has spaces in it needs to be quoted using "'"s as above.

Note that unix pathnames are not directly substitutable for Mac pathnames in the current MacJikes implementation.

Using lots of .zip or .jar files might require you to allocate more RAM to MacJikes. if you can spare the RAM, I have always been safe at 30MB myself. :-)

Did it crash!?

MacJikes takes over all processing time while it is compiling. MacJikes v1.1 fixes this problem for the MacJikes application.

File system conventions

This port of Jikes uses the MPW conventions for filenames and pathnames.

Absolute pathnames:

disk:

the name of a disk

Relative pathnames:

folder

reference to a folder

 
:folder

reference to the same folder above

 
:folder:

reference to the same folder above

 
:filename

reference to a file in the current directory

 
:

current directory

 
::

back one directory

 
::back2

back one directory, referring to the file or folder named back2.

 
::back2:

back one directory in the back2 directory.

UNIX and Windowsisms:

.

current directory

 
..

back one directory

 
.:

a folder named ".". Don't abuse the "." and ".."!

 
..:

a folder named "..". Don't abuse the "." and ".."!

Multiple pathnames or files:

{path},{path}

The comma separates logical pathnames. That's right, you cannot define packages such as "sbytnar.Jet,Car,Plane". Get over it. :-)

What Java Development Kit do I use!

In my testing, the Metrowerk's Classes.zip file works perfectly. The MRJ 2.0EA3 "JDKClasses.zip" also works fine. You have to specify either of these for EACH TIME you execute Jikes for MacOS:

These are examples of the command line parameters you would give the application or the MPW tool.

-classpath :,:Classes.zip    MySource.java
-classpath :,:JDKClasses.zip    MySource.java

It created a ton folders with wierd names!

This is what happens when Jikes cannot write a file because the pathname is too long! Ooops. This happens when you see errors like this when you are compiling source files in directories that exist in places other than the Jikes binary:

Found 4 system errors:

*** Error: Unable to write file 
  "/mindbright/ssh/SSHStdIO$CtrlDPressedException.class"

*** Error: Unable to write file 
  "/mindbright/ssh/SSHInteractiveClient$DumbConsoleThread.class"

*** Error: Unable to write file 
  "/mindbright/ssh/SSHPduInputStream$PduByteArrayInputStream.class"

*** Error: Unable to write file 
  "/mindbright/ssh/SSHPduOutputStream$PduByteArrayOutputStream.class"

MPW Tool specific

set CLASSPATH ":,:Classes.zip"
export CLASSPATH
MacJikes MySource.java

Yes, environment variables that Jikes normally listens to are able to be used with the MPW Shell version of Jikes for MacOS. If you intermix javac and MacJikes, you can keep separeate classpaths. MRJ's javac listens to CLASSPATH, MacJikes listens to JIKESPATH exclusively if it is defined, otherwise it uses CLASSPATH.




Error messages I've seen and why



File name length is definitely a problem. Any .java file that
creates a .class file that is >32 characters will cause PROBLEMS.
You might end up with a ton of folders with garbage names, or even a
complete crash. Be smart. Rename class files, their contents and
anything that depends on them. I am working on making MacJikes so you
don't have to worry about this.



I am contemplating a fix for this by truncating names like
this:



For



class UserAlreadyLoggedInException /* 28 characters */



contained in:



UserAlreadyLoggedInException.java
/* 33 characters WILL NOT fit under HFS */



will be assumed to be named:



UserAlreadyLoggedInExceptio.java
/* 32 characters will fit under HFS */



and will NOT generate:



UserAlreadyLoggedInException.class
/* 34 characters WILL NOT fit under HFS */



but WILL generate:



UserAlreadyLoggedInExcepti.class
/* 32 characters will fit under HFS */



 



If you rename a class file such that its name is shorter than the
class enclosed, you will see a failure like this:



Assertion (type_name_length - (n + 1) == type ->
ExternalNameLength()) failed in "getclass.cpp" on line 628






Examples of long filename fixing



For SunSphere from MRJ 2.1 EA3, here is how you can get almost all
of the source compiled:



# -------- 
setdirectory Viking:jikesos:jikes:src:zSunSphere:Source
if (`exists SunSphereConfig.java) 
else
rename SunSphereConfigMRJ.java SunSphereConfig.java
delete SunSphereConfigPersonal.java
endif
flush; Viking:jikesos:jikes:src:MacJikesPPCTool -depend -d : 
         -classpath ::,:Classes.zip `files -f .java`
# --------




Return
to the MacJikes homepage.


This material is Copyright 1999, Steven Bytnar