OK - well - here is a plan.....
I have these scripts in a "hacked together" state and they currently
rely on reading the output from -verbose:class generated by an IBM JRE.
Ideally I'd like them to be able to read a couple of different formats.
If anyone is interested in knowing if their app would (in theory) run
using Harmony classes open a JIRA called "Would $my_favourite_app run on
Harmony?" and attach the output from "java -verbose:class
$my_favourite_app". If this works I can pick up the output and use it to
test the tool. Please would you also attach the output from "java
-version"? I will append (or ask someone to append) a list of missing
files to the JIRA.
When I'm happy that my scripts work and I've tidied up the code I'll
attach the source as a JIRA and write some instructions on how to use it.
FWIW in looking at Derby, it looks as though we still need SQL (could
have predicted that I suppose) and JNDI, but those seem to be all that
are missing. I can send the list of missing classes to anyone that
wants to verify this - it's just slightly too long to paste into mail
Geir Magnusson Jr wrote:
zoe slattery wrote:
I've tried to post this a couple of times from another mail account -
but it seems to go into a black hole - apologies if another two copies
turn up later :-(
I had some thoughts about running applications using Harmony classes.
Rather than just getting various applications and trying them with
Harmony I've been trying to see what classes they need.
For example, I downloaded and installed Derby then ran this:
java –verbose:class org.apache.derby.drda.NetworkServerControl start
> dbc.txt
This generates a file (dbc.txt) showing all of the classes that get
loaded when Derby starts up. The format of the output is something
like this:
...
class load: java/io/BufferedOutputStream
class load: java/io/BufferedReader
class load: java/io/BufferedWriter
class load: java/io/ByteArrayInputStream
class load: java/io/ByteArrayOutputStream
class load: java/io/CharConversionException
class load: java/io/DataInput
class load: java/io/DataInputStream
...
using an IBM JRE - the format would likely be different using another
JRE. I ran a few more similar things to look at what classes get
loaded when you create tables, add rows etc. and then cat'd the class
load output into a single file. A more extensive test could be run by
using Derby unit tests.
I wrote a small perl script that extracts the names of all of the java
classes and then compares these against the API spec to generate a
final list of API classes that are used by an application. I'd be
happy to supply the perl, although it needs a bit of tidying up.
This is cool.
The next step would be to check how many of these exist in SVN already
- and maybe highlight the areas that we are missing?
Yes!
So far, the only
way I have found to get a list of files that exist in SVN is using
something like "svn list $repos_path -R", if anyone knows of a better
(faster) way I'd be happy to hear it.
Try to find a way to do it on a local checkout. We don't want to be
banging the SVN repo like this. (We've been having problems lately w/
people walking through the SVN repo, file after file, version after
version, via the viewCVS interface. Not a good use of resources.
Agreed - I did try the svn list command once and realised that it wasn't
going to be practical. It's easy to do on a local checkout.
This would be cool - I'd love to post these on the website, to let
people know what they could do to help get their favorite app up and
going.
I wonder too if this could be combined with Gump somehow, so we can
automatically test a large swatch of the "popular java app" world.
I don't know but would be happy to look (later)
Thoughts?
--
Zoe Slattery
IBM
