← Back to branch summary

~russel/groovynativelauncher/trunk

« back to all changes in this revision

Viewing changes to README.txt

  • Committer: akaranta
  • Date: 2010-04-30 03:47:43 UTC
  • Revision ID: svn-v4:a5544e8c-8a19-0410-ba12-f9af4593a198:trunk/groovy/modules/native_launcher:19904
SConstruct: fixed issue of os.uname not being available on windows, improved test execution logic, small cosmetic improvements in c files, added preprocessor macros that should make swig handle jni_md.h on os-x ok

Show diffs side-by-side

added added

removed removed

Lines of Context:
README.txt
23
23
 
24
24
The launcher has been built in such a way that only groovy.c has groovy dependent stuff.
25
25
It is simple to use the other source files to create a native laucher for any
26
 
java program.
 
26
Java program. In fact, native launchers for gant and grails have later been added.
27
27
 
28
28
Great care has been taken to avoid possibility of buffer overflows. The common c-convention
29
29
of using "big enough" buffer is avoided if at all possible - instead memory is allocated dynamically after
30
30
calculating how much is needed. The only exception to this rule is places where the posix or 
31
 
os specific API used must be called w/ a preallocated buffer, e.g. realpath function.
 
31
os specific API used must be called with a preallocated buffer, e.g. realpath function.
32
32
 
33
33
Licencing
34
34
---------
52
52
  * location and name of jvm dynamic library (jvmstarter.c)
53
53
  * getting the location of the current process' executable (jst_fileutils.c)
54
54
  * supporting platform peculiarities like looking up java home from windows registry and
55
 
    using the standard java installation location on os-x
 
55
    using the standard Java installation location on os-x
56
56
  
57
57
Java launcher generator
58
58
-----------------------
87
87
TODO
88
88
----
89
89
 
90
 
 * According to a compiler define, the home folder for groovy is either a hard coded location (well known location) or it is looked up
91
 
   dynamically. Note that in certain cases dynamic location lookup can pose a security hole.
92
90
 * refactor parameter classification into separate functions, possibly a separate source file
93
91
   options:
94
92
   - value into system property
102
100
   * what about the other way around, i.e. specifying that a sys prop / launchee param is to
103
101
     be created using a param value / env var value / hard coded default value?
104
102
 * add the possibility to define "recursive jar dirs", i.e. directories where jars are searched for recursively.
105
 
 * add a check that the java home found can actually be used (i.e. it is valid). ATM the first java home is used; in some
106
 
   cases it may not be valid (e.g. if there are stale win registry entries, if the java executable found on path
107
 
   is not contained in a jdk/jre (even after following the symlinks). This can happen if the executable is a hard link.
108
103
 * the terminating suffixes is really only necessary in case where the name of the input file begins w/ "-". 
109
104
   Maybe it is such a special case that it can be ignored? In that case the terminating suffixes part could be
110
105
   removed.
112
107
   * very low priority
113
108
 * add an option to restrict the used jre/jdk version to be exactly something, greater than something, between some values etc.
114
109
   Have a look at how eclipse plugins define the required version of their dependant plugins in their manifest.mf
115
 
   A problem that needs to be solved: how to reliably tell the version of a java impl w/out actually loading and starting the jvm?
 
110
   A problem that needs to be solved: how to reliably tell the version of a java impl without actually loading and starting the jvm?
116
111
 * Write some instructions on creating an .ico file for windows. Point to e.g. http://imageauthor.com and some win programs for icon creation. 
117
112