[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-java-com
Subject:    J++: Make EXE/DLL from command line
From:       Howard Kapustein <hsk0 () VOICENET ! COM>
Date:       1999-02-27 4:17:27
[Download RAW message or body]

Sorry for the cross-post. Given the relative lack of traffic on most of
these forums, Microsoft's questionable commitment to J++ and the
difficulty of the issue, I felt it warranted the etiquette breach. My
apologies in advance.


Advanced developers only. I'm not a newbie. This is a simple question
which is likely to have a complex answer. I'm relatively stumped; I have
a suspicion where the answer lies, but I dread being right.


Q: How do I create a .EXE (and, if process is different, .DLL) solely
using command line tools (and no J++ IDE, at all, nope, nada, squat,
bupkiss, zilch, no way, no how)?

I've pored over the archives, can't find an existing answer to this one.
If it's there, it's not turning up across various searches.

Here's the picture:
Install VJ++ 6.0 SP2.
You've got make. [Configuration Builder actually, but same diff.]
No SDK for Java.
No IDE.
No IDE projects.

We have our own build infrastructure, which does things the IDE's can't
(reproduceable builds, meet ISO 9000 and similiar requirements, etc.).
Many developers use the IDE during development, but all "real"
(production) builds must be done using our build process. Essentially a
MAKE.EXE-style system.

Welcome to enterprise development.
This is serious, enterprise-scale software development; the VB-style
"whatever's currently registered is cool" approach is ***not*** good.


Compiling *.java->*.class is easy -- a little creative make logic
involving JVC.EXE and voila.

The only exes under ..\VJ98 are JVC.EXE (compiler), JACTIVEX.EXE (COM
wrapper/importer), and VJREG.EXE (Java/COM registrar).

Unlike the SDK for Java, there is no JEXEGEN.EXE.
Obviously, the supporting logic's there, somewhere, since the IDE can
make EXEs and DLLs. [And .ZIP files too, though same thing, I couldn't
find a command line .EXE shipped w/J++ that made .ZIP files.]

Using JVC.EXE and Info-ZIP's ZIP.EXE, I can compile Java compile and
make .ZIP (and unsigned but compressed .JAR) files. VJ6 also ships
CABARC.EXE and DUBUILD.EXE that let me create .CAB files.

As far as I can tell, the only possible way to make .EXE/.DLL files via
VJ6 seems to require using the IDE and its projects.


Yes, I'm all too aware of the IDE automation facilities.
That's not an option.
We're trying to make the Java compiles work much like C++ -- run command
line tools, give input files, get output files -- rather than VB where
the "compile" process is highly dependent on what happens to have been
last installed on the box.

Java's real close -- JVC.EXE and /cp parms let us run an executable and
control exactly what symbols/libraries get resolved during the compile.
This works quite well with our build process and avoids a lot of
headaches people run into in the VB world.

[For example, one guy installed something that dropped ADO 2.0 on his
machine, his VB project updated references from ADO 1.5->2.0 and he
accidentally built a VB .DLL that was dependent on the newer ADO, when
the other half of the app was built by someone else on a another machine
using ADO 1.5 -- nasty problem to track down. Another example: I
installed VJ6 on my box, had to slap together a little VB5 widget,
compiled and ran fine, copied it to another machine and wouldn't run --
because the TreeView control created on the form started its life
referencing the VB6 (TreeView 1.2?) interface rather than the VB5
version/IID -- fortunately it was a very small app with only 3 lines of
text to manually hack back to the VB5 GUIDs, but in a real app? Would
have forced us to move to VS6 runtimes far sooner than we were prepared
to do (test, validate, etc.), put the project on hold (not good), or
waste hours and hours (and days or weeks) manually hacking the VBP/FRM
files and testing, praying we didn't miss anything... Let's just say
Microsoft's development tools leave something to be desired in the
software management arena...]

Snooping around various DLLs in the VS6/VJ6 directories, it looks like
there's a bunch of COM objects, most likely buried somewhere in there is
the actual 'Make EXE/DLL file' function(s). Not documented that I can
find and almost nothing exported (lots of DllCanUnloadNow/etc. but only
found 3 entry points across 2 of the DLLs, and those were
semi-cryptically named).

I suspect the logic's exposed via COM objects, used by the IDE. I didn't
investigate in detail (look for typelibs embedded in the DLLs, scan
registry widgets coming from the VS6/VJ6 directories, etc.). If that's
how it's done, I'm probably SOL -- reverse-engineering what may be a
non-trivial API isn't my idea of "minimizing risk".


I've considered giving up on VJ6 for these files -- I can use the SDK
for Java's JEXEGEN.EXE to make a .EXE but I'm concerned it may not make
the same/equivalent .EXE as the VJ6 IDE. Also, it's not clear how (or
even if) it can make a .DLL.


Let me repeat:
I'm looking for a command-line driven technique to create .EXE and .DLL
files using VJ6, w/o creating IDE projects (not even dynamically, via
IDE automation/scripting). I'm willing to consider using the SDK for
Java, **if** that will produce equivalent results.

I repeat -- *NO* IDE!
I know how to get my results using the IDE's scripting, but that's truly
a last resort. I'm looking for a command-line/MAKE-driven solution.

(The scripted-IDE approach would force us to give up on some of the
requirements/goals/features of our build process for Java code -- not
something done lightly or sits well, considering the reasons we need
them -- ISO 9000, FDA approval, and other fun details. This is
enterprise scale development -- this stuff isn't as flexible as for
departmental or other 'small' projects/shops).



The .DLL support is more important than .EXE support -- we mostly make
.ZIP/.CAB files for 'normal' Java code and .DLLs for COM objects
implemented via Java. The handful of .EXEs we have are mainly simple
utility things; we could live with plain ZIP/CAB files for them via
JVIEW.EXE, if we have to.


If my suspicions are true and the 'Make EXE/DLL' logic exists in COM
objects used by the IDE, I'm not adverse to writing my own EXE that
drives the COM object(s). Documentation would be nice, but I'm willing
to settle for an undocumented but reasonably reliable solution. [I'd
rather not go this route if I can help it, but it might be less
problematic than the scripted-IDE path.]


Has anyone else done this?

Thought about it?

Dealt with it?

Hey, any of the VJ team listening?
Drew?
Mark?
Bill?
Hervey?
Is there a solution?

    - Howard

----------------------------------------------------------------------
Email: mailto:hsk0@voicenet.com     WWW: http://www.voicenet.com/~hsk0
----------------------------------------------------------------------
Your mouse has moved. Windows NT must be restarted for the change to
take effect. Reboot now?  [ OK ]
----------------------------------------------------------------------
"A child of five could understand this - fetch me a child of five!"
----------------------------------------------------------------------
"So you could say the greatest achievement of the Internet is that it
turns nuclear war into nothing more than a series of routing errors." --
Mark Pesce
----------------------------------------------------------------------


["hsk0.vcf" (text/x-vcard)]
----------------------------------------------------------------
Users Guide http://www.microsoft.com/workshop/essentials/mail.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html


[prev in list] [next in list] [prev in thread] [next in thread]