Enhancement request

A

Andrew Thompson

What i would support would be an int return type from main, so you can
return an exit code to the OS. I don't see why one should have to use
System.exit to do that.

One reason is because System.exit() may occur long
after the main() has ended, in a multi-threaded
(e.g. GUId) application.
 
A

Andrew Thompson

(runtime arguments)
So have I, but of the different types of Java apps:
   - SE console apps
   - SE GUI apps

A GUId app. launched using webstart that suggests
file associations..
   - SE applets
   - EE apps
   - ME whatever such apps are called
only the first category is potential command line arguments.

...should logically expect arguments handed to
the main() (though obviously not 'command line'
args. - I am not sure how you meant that).

Here is a JNLP file service API demo. that claims
file associations..
<http://pscode.org/jws/api.html#fs>
 
T

Tom Anderson

Considering you ownly write one main method for an application it is
hardly a common inconvenience, I therefore see no real reason to
support your suggestion.

I suggest the main method is used a lot more often than one per
application. I test every sophisticated method by invoking from the
main, e.g.

Class Topology {
...
public static void main( String[] args ) {
Cylinder c = new Cylinder("a",10,10,10,10);
Topology t = new Topology(c);
System.out.println(t.getOpenings());
}
}

Therefore, almost every class has it. With this usage scenario it is
unjustifiably verbose.

http://junit.sourceforge.net/

tom
 
T

Tom Anderson

Lew said:
Unless you call it from another Java class in a different package,
'main()' doesn't need to be public.

It's not callable from the command line unless it's public.

class Hello
{
static void main(String[] args)
{
System.out.println("Hello.world.");
}
}


% java -cp . Hello
Main method not public.

I could have sworn that private main methods worked. Was that changed at
some point, or was i wrong all along?

tom
 
T

Tom Anderson

I think it would have been fine if they had done it that way. But they
did not and I don't think it is important enough to justify a change.

Oh, agreed, entirely. It's a very, very minor niggle.

Although the change could easily be backwards-compatible - permit main to
be void or int. I can't immediately see how it could break any existing
code.

But yes, this is really an incredibly minor point.

tom
 
A

Andreas Leitgeb

Tom Anderson said:
I could have sworn that private main methods worked. Was that changed at
some point, or was i wrong all along?

Maybe you mixed it up with the classes' access:

class Test // package-visible in "."
{
private static class Rest {
public static void main(String... args) { }
}
public static void main(String... args) { }
}

java -cp . Test # ok
java -cp . Test\$Rest # ok, too
 
R

Roedy Green

I'm programming java since 96 and can't remember myself ever using
main method with arguments. Does anybody have a different experience?

I guess you write only GUIs, not utilities. I use them all the time.
 
A

Andreas Leitgeb

Lew said:
That would be a major change to the Java language, because it does not allow
different return types for methods in the same class with otherwise identical
signatures. The current main() signature suffices anyway.

It's not really all that major: You still cannot have two methods
with same parameter types and different return-value *at the same time in the
same class* (including "inherited" stuff). Though you can already have *any*
one such method. No one forbids you to define this one in absence of
conflicting variants:

public static int main(String[] args) {return 0;}

The question is, whether the jvm could/should make another try at
"int main(...)" after having failed for "void main(...)", or do some
reflection first to determine whether to call void main or int main
or byte main or long main or BigInteger main or .... ;-)

While I do think it quite easily *could*,
I personally do not think it *should*,
but would still likely use it if it did. :)
 
T

Tegiri Nenashi


The way to organize unit testing is subject to debate. This section
http://en.wikipedia.org/wiki/Unit_testing#Documentation
however, caught my attention. Now, suppose a developer came across
unfamiliar class/method with sophisticated functionality and want to
run the test in order to see how it works. Would it be easier to start
looking for unit tests that cover it, or just fire up the main method
that is sitting right there in the class itself?
 
P

Patricia Shanahan

Tegiri said:
Most people belive in global warming too. Can you name a single
benefit using testing "framework"? Consider http://open.ncsu.edu/se/tutorials/junit/
the code samples there are just ridiculos.

Here are a couple:

Automatic execution of sets of tests. For example, right click a package
in Eclipse and select Run as JUnit Test.

Continuation after a failure, to get a complete picture of which tests
are wrong. This is less frequently useful, because I often run the
complete set of unit tests as part of a regression test, and that rarely
fails.

Meanwhile, consider the possibility of writing a simple wrapper that,
given a class name, uses reflection on that class to look for a public
static void main without arguments. If it finds one, run it.
Alternatively, look for it with an int result, run it, and call
System.exit with the result.

Patricia
 
T

Tegiri Nenashi

Here are a couple:

Automatic execution of sets of tests. For example, right click a package
in Eclipse and select Run as JUnit Test.

Continuation after a failure, to get a complete picture of which tests
are wrong. This is less frequently useful, because I often run the
complete set of unit tests as part of a regression test, and that rarely
fails.

Batch processing is an old philosophy of doing things. Sometime ago, a
common scenario was the following. Programmer makes a change in a
source file, hits "build", and goes to lunch until the complie system
would be able to process the result. Today one witness the errors
immediately as she types. Therefore, why not to extend this idea to
unit tests? I start changing some method, and, boom, IDE would
invalidate the test methods immediately! Again, it is more convenient
to have test method(s) local.
 
S

Stefan Ram

Tegiri Nenashi said:
Can you name a single benefit using testing "framework"?

Using JUnit establishes a certain interface for test. Other
tools then can rely on that interface. For example, when they
instrument code to detect test coverage, they already know
which methods are test methods, when the test methods are
declared according to JUnit conventions.

When pogrammers change companies and both companies use JUnit,
the programmers already know the conventions and do not have
to learn anew.

The framework does not actually have to do anything for this
to work. It just needs to establish a convention.
 
T

Tegiri Nenashi

  Using JUnit establishes a certain interface for test. Other
  tools then can rely on that interface. For example, when they
  instrument code to detect test coverage, they already know
  which methods are test methods, when the test methods are
  declared according to JUnit conventions.

  When pogrammers change companies and both companies use JUnit,
  the programmers already know the conventions and do not have
  to learn anew.

  The framework does not actually have to do anything for this
  to work. It just needs to establish a convention.

Could you please be more specific what interface and what conventions?
You aren't implying that "setUp", "tearDown", "testSomeBehavior"
specify any meniful interface right? As for various kind of
assertions, there is only obe kind: assert(Boolean). Therefore, *any*
test program needs only two things:
* be identifiable as a test
* contain identifiable assertions
Again, I'm suggesting "main" as a dedicated test method, and standard
assert for assertion. With these two things is is not hard to see how
Eclipse (or other IDE) could easily automate testing without relying
on JUnit bloatware. Just run the main method in a dedicated thread and
mark all the assertions that are invalid. (Obviously if there is no
assertions, don't run anything:).
 
M

Mike Schilling

Lew said:
That would be a major change to the Java language, because it does
not allow different return types for methods in the same class with
otherwise identical signatures.

Right, you could have

void main(String[] args)

or

int main(String[] args)

but not both. The magic that looks for main() could handle that easily.
 
M

Mike Schilling

Andreas said:
Lew said:
That would be a major change to the Java language, because it does
not allow different return types for methods in the same class with
otherwise identical signatures. The current main() signature
suffices anyway.

It's not really all that major: You still cannot have two methods
with same parameter types and different return-value *at the same
time in the same class* (including "inherited" stuff). Though you can
already have *any* one such method. No one forbids you to define
this one in absence of conflicting variants:

public static int main(String[] args) {return 0;}

The question is, whether the jvm could/should make another try at
"int main(...)" after having failed for "void main(...)", or do some
reflection first to determine whether to call void main or int main
or byte main or long main or BigInteger main or .... ;-)

While I do think it quite easily *could*,
I personally do not think it *should*,
but would still likely use it if it did. :)

Hypocrite :)
 
S

Stefan Ram

Tegiri Nenashi said:
Could you please be more specific what interface and what conventions?

The conventions JUnit uses to identify test methods
within a class.
 
M

Mike Schilling

Tom said:
Lew said:
Tegiri Nenashi wrote:
static void main() {
}

Mark Space wrote:
Forgot the "public."

Unless you call it from another Java class in a different package,
'main()' doesn't need to be public.

It's not callable from the command line unless it's public.

class Hello
{
static void main(String[] args)
{
System.out.println("Hello.world.");
}
}


% java -cp . Hello
Main method not public.

I could have sworn that private main methods worked. Was that changed
at some point, or was i wrong all along?

AFAIK, it's always worked that way. Though I think the error message used
to be less friendly, more like "main([String not found".
 
M

Martin Gregorie

Oh, agreed, entirely. It's a very, very minor niggle.

Although the change could easily be backwards-compatible - permit main
to be void or int. I can't immediately see how it could break any
existing code.

But yes, this is really an incredibly minor point.
Agreed. Why not pick on something more substantial, such as the tangle of
Readers, InputStreams etc - beast me why I have to jump through nested
hoops just to open a BufferedReader when I have File that identified the
data source. The current way of doing it:

File inf = new File ("myinputfile.txt");
InputStream is = new FileInputStream(inf);
Reader isr = new InputStreamReader(is);
BufferedReader inb = new BufferedReader(isr);

is just plain perverse. When I can release all the resources with
inb.close()

why can't I acquire them with
BufferedReader inb = new BufferedReader(inf);

or
BufferedReader("myinputfile.txt");

Maybe there's a good reason for this, but I'm damned if I can see it.
 
M

Martin Gregorie

Batch processing is an old philosophy of doing things. Sometime ago, a
common scenario was the following. Programmer makes a change in a source
file, hits "build", and goes to lunch until the complie system would be
able to process the result.
Yes, some machines were slow then, particularly if you kept the source on
cards. I've been there, done that. We used to combine the build with a
test run in a single job. It was great - submitted before lunch or chuck-
out time and you got results back after lunch / next day ready to be
analysed.
Today one witness the errors immediately as
she types. Therefore, why not to extend this idea to unit tests? I start
changing some method, and, boom, IDE would invalidate the test methods
immediately! Again, it is more convenient to have test method(s) local.
But regression testing is inherently a batch process that, done properly,
returns a single pass/fail result from a comprehensive set of tests -or
are you saying you really prefer running each test in the set manually
and keeping a hand-written log of the results?

Personally, I have no faith in any set of library classes that don't have
a properly thought out and carefully implemented set of automated
regression tests.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top