[GLASSFISH-6784] Do not use batch files on Windows Created: 15/Nov/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: installation
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mkarg Assignee: scatari
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Issuezilla Id: 6,784


Batches are common in the UNIX world and had been popular in the DOS world, too.
But in the Windows world, batches are something administrators don't like: The
chance is just too high that they break. The reason is that the batch language
is not well suited for exceptions. Batches are potentially instable. Also when
running they open that ugly DOS BOX, which nobody wants to see and (worse!)
could break using CTRL-BREAK (with undeterministic result, depending on the
currently executed command within the batch). And worse, the batch language
itself has several differences between the Windows versions...

On Windows it is typical to have an EXE file. In the Java world it is typical to
have a JAR file. Both can be supplied with excellent exception handling and can
optionally run without showing any UI.

So it would be really great if there would be no batches but EXE or JAR files
that drive the command line interface. I do not see anything in the batch that
can be done in a batch but not in a JAR file. Since we are in the Java universe
let's use Java.

Comment by mkarg [ 15/Nov/08 ]

This is an enhancement but not a bug.

Comment by Bill Shannon [ 23/Sep/09 ]

I assume this is a request to have a way to start the server without using
the asadmin.bat batch file on Windows?

Presumably when typing commands in a command window it's fine to use the
asadmin.bat batch file?

We're unlikely to provide a native asadmin.exe to replace asadmin.bat,
and the Windows jar file integration makes it unsuitable for command line
use, although we could consider a jar file to start the default domain.

Comment by mkarg [ 24/Sep/09 ]

Please check again my original proposal. I wrote that there is no need for a
batch since all it does can be written in plain old Java. So my proposal
actually is to replace the platform dependent batches by executable JARs.

See, Windows people will accept EXE or JAR. If you don't like to provide EXE
then provide JAR. But don't force them to use Batches. This is just not good
style in the Windows universe.

Comment by janey [ 28/Feb/10 ]

Reassign to Bill.

Comment by Byron Nevins [ 05/Mar/10 ]

What exactly is the gist of this? What batch file do you want to replace?

Scripts are directly editable and very very easy for an end-user to modify.
Java jars are binary and are a much much bigger deal for an end-user to change.

What if you want to run the java program with -Xmx1024 - how are you going to do
that? What about the -Xrs option? Without that option GF running as a service
will stop the moment you logout.

If asadmin is the complaint – you can run it as a jar right now like so:

java -jar modules\admin-cli.jar some-command some-arg ...


Comment by Byron Nevins [ 05/Mar/10 ]

I just downloaded and installed V3 via the official installer.

If that is what you are talking about – I agree. The shortcuts are flaky.
They start up a temporary DOS box that is minimized. I didn't notice so I
double-clicked twice and ended up with 2 running instances of V3!

This could be improved. There are ways to run without a visible DOS box I believe.

Reassigning to installer

Comment by Byron Nevins [ 05/Mar/10 ]


Comment by mkarg [ 05/Mar/10 ]

One must understand that each platform has its standards for how things have to
work like. On UNIX, this is using batches for configuration, installation,
startup und daemon control. On Windows it it not. On Windows, Microsoft is
providing different binary APIs for that. So a program that likes to get
accepted by Windows users, or even more wants to apply for a "Windows Logo"
certification, must not use batches for anything but instead utilize that
different APIs.

The reason is that using the APIs much better integrates the application into
the overall Windows environment. It does "feel" like Windows when using their
style, while it feels "strange" to see a script run. Also using their style
provides MUCH improved stability. For example, their service API is unparallel
and gives Windows much better control of a service's current state than any
script on UNIX will give on daemons. Windows knows exactly in what state a
service really is, whether it is shutting down actually or asks for more time
while doing that and so on. Batches cannot provide this information. But it is
not only about services, it is much more about stability in general.

Microsoft clearly defines that configuration information is to be stored in the
registry. So if you like to configure RAM or other options, this must be stored
in registry. It gets there using a GUI, and the program will pick it from there
using a binary API. The customer shall never fumble around with editing
scripts. Why? Because he likely will break the script by incident.

To sum up, Windows has a completely different design regarding the complete
life cycle control of a service. Batches are far beyond what Windows wants and
feels to Windows users like "stone age applications", but not
like "professional services provided by people that understand makes a program
a REAL windows program".

Comment by Bill Shannon [ 06/Mar/10 ]

Really reassign.

If there's a way we can write a Java program that avoids bringing up a
Command window, we should consider that.

If the only solution is to write native Windows code, we should close
this bug.

Comment by mkarg [ 06/Mar/10 ]

To make it more clear: It's less a problem that window is shown (native Windows
applications also shows windows, hence the name of the operating system ),
but more a problem of using batches. Batches are likely to break. Why not
writing a simple executable JAR file containing a main-class entry which pulls
configuration from registry using Preferences API? That would be 100% pure Java
AND would fulfil the constraint that configuration must not be found in
batches. It would be more accepted by Windows users from their point of view,
and it would be able to run on ANY operating system, while a batch obviously
will only run on some.

Comment by Byron Nevins [ 06/Mar/10 ]

I'm starting to get a little bit lost. The discussion is too abstract. What
specifically are you talking about? Is it that "asadmin.bat" even exists? Or
is it that the installer provides these clunky little scripts that start and
stop the server?

In the former case, we are providing a service to users. Asadmin is a **command
line tool**. It is supposed to be used in a "DOS box". We provide a fully
featured GUI as well – the Admin GUI normally found at localhost:4848. Asadmin
allows you to easily do things like run JDK6 for V3 and run JDK5 for other
things, etc.

This is analogous to what Microsoft does. E.g. managing Services
GUI: "Rt-Click My Computer/Manage/Services&Applications/Services"
Command Line: sc

You can run "asadmin" easily without a batch file. Simply run it like so – no
batch involved:

C:\Users\bnevins>java -jar e:\glassfishv3\glassfish\modules\admin-cli.jar
Waiting for DAS to start .............
Started domain: domain1
Domain location: E:\glassfishv3\glassfish\domains\domain1
Log file: E:\glassfishv3\glassfish\domains\domain1\logs\server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

Comment by Byron Nevins [ 06/Mar/10 ]

Here is a link that describes how to run a script with no window...


Comment by mkarg [ 07/Mar/10 ]

It is ok to have CLI tools, but this is not about the form of tool but about
the form of implementation: Batch files vs. standalone binaries.

It's not about one particular batch file, it is about using batch files at all.
Most distracting is applient.bat and asadmin.bat being batch files, but
certainly every other batch falls into the same category.

I never said that microsoft does not use CLI tools or batches on their own, but
that it is uncommon. The fact that microsoft provides one doesn't make it more
common tot he average Windows user or administrator, and doesn't change their
own logo criteria.

The main problem is that a batch can break. The fact that it showns a DOS box
is just an unwanted (and correctable) side effect.

And: There is a big difference between a real Windows service and wrapping
something behaving LIKE a service (read the Windows service API to get an
understanding of the difference – GF just supports SOME of the needed events,
while Windows users expect ALL to be supported). Lots of threads in this forum
are based solely on the fact that GF does not work like a "real" service, but
just comes with a service that controls GF. That problems will be gone as soon
as you understand that you must not somehow wrap Java to make it look like
Windows, but that you must start do DESIGN FOR Windows to make people happy.
That IS possible in Java, and it does not necessarily break compatibility with
other platforms. But you need to learn how to do it and you then must do it.
Otherwise it will always feal like a "impurity" on Windows.

We lost several customers since they where unhappy with the "strange" felling
of GF, actually, and all we ask for is just to get rid of batches in the first
place. Is that so non-understandable?

Comment by scatari [ 09/Mar/10 ]

Instead of java.exe, javaw.exe can be used to suppress the command window @startup time. javaw.exe
uses WinMain() as the entry point.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Generated at Sat Sep 05 03:54:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.