Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19710 > unrolled thread

Java daemon

Back to article view | Back to comp.lang.java.programmer

Contents

  Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 22:17 +0800
    Re: Java daemon David Lamb <dalamb@cs.queensu.ca> - 2012-11-12 09:25 -0500
      Re: Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-12 23:55 +0800
        Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-12 22:07 +0000
          Re: Java daemon "sl@exabyte" <sb5309@hotmail.com> - 2012-11-13 10:56 +0800
            Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:08 -0500
            Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 13:59 +0800
            Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-13 21:50 +0000
              Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:43 -0500
                Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-19 01:05 +0000
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 20:41 -0500
                    Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-20 00:32 +0000
                      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 20:07 -0500
                    Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-19 20:38 -0400
                      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 20:22 -0500
                        Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-20 17:46 -0400
                Re: Java daemon Lew <lewbloch@gmail.com> - 2012-11-18 20:10 -0800
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-19 10:50 -0500
          Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:06 -0500
            Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-13 21:36 +0000
              Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-13 17:31 -0500
                Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-14 21:33 +0000
                  Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-14 16:55 -0500
                    Re: Java daemon Martin Gregorie <martin@address-in-sig.invalid> - 2012-11-15 02:09 +0000
      Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 14:40 +0800
        Re: Java daemon Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-11-12 23:39 -0800
          Re: Java daemon "SL" <sb5309@hotmail.com> - 2012-11-13 16:16 +0800
        Re: Java daemon Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-11-13 06:37 -0400
        Re: Java daemon David Lamb <dalamb@cs.queensu.ca> - 2012-11-13 08:46 -0500
        Re: Java daemon "John B. Matthews" <nospam@nospam.invalid> - 2012-11-13 21:23 -0500
        Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:52 -0500
        Re: Java daemon markspace <-@.> - 2012-11-18 14:02 -0800
          Re: Java daemon jlp <jlp@jlp.com> - 2012-11-19 20:39 +0100
            Re: Java daemon "SL@maxis" <ecp_gen@my-rialto.com> - 2012-11-20 15:23 +0800
    Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 09:41 -0500
    Re: Java daemon Jim Janney <jjanney@shell.xmission.com> - 2012-11-12 14:24 -0700
      Re: Java daemon Lew <lewbloch@gmail.com> - 2012-11-12 13:35 -0800
        Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-12 22:05 -0500
      Re: Java daemon Arne Vajhøj <arne@vajhoej.dk> - 2012-11-18 16:40 -0500

Page 2 of 2 — ← Prev page 1 [2]

#19743

On 11/13/2012 4:36 PM, Martin Gregorie wrote:
> On Mon, 12 Nov 2012 22:06:50 -0500, Arne Vajhøj wrote:
>> On 11/12/2012 5:07 PM, Martin Gregorie wrote:
>>> On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:
>>>> I have sort of given up hope on PHP daemon; one cannot touch its GC I
>>>> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>>>>
>>> I've not done a lot with PHP, but haven't (so far) run into any
>>> particular problems with the Apache/PHP combination under Linux.
>>
>> For the typical web page the request scope is sufficient to avoid
>> problems.
>>
>> But a daemon is not a typical web page.
>>
> I've been picking it up from "Programming PHP" (O'Reilly). That doesn't
> mention anything even vaguely resembling a PHP Daemon.
>
> What is it?
> If you have Apache, why would you need it?
> Is it some sort of lightweight web server?

You know what a daemon is.

Besides the web integration with Apache and IIS that accounts
for 99+% of PHP usage, then PHP also comes with a command line
utility.

So you can write a daemon in PHP and run it via the command line
utility.

Arne

[toc] | [prev] | [next] | [standalone]

#19756

On Tue, 13 Nov 2012 17:31:22 -0500, Arne Vajhøj wrote:

> You know what a daemon is.
> 
> Besides the web integration with Apache and IIS that accounts for 99+%
> of PHP usage, then PHP also comes with a command line utility.
> 
> So you can write a daemon in PHP and run it via the command line
> utility.
>
Thanks for the clarification. I thought you must have been talking about 
some special PHP daemonising framework or library.
  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19757

On 11/14/2012 4:33 PM, Martin Gregorie wrote:
> On Tue, 13 Nov 2012 17:31:22 -0500, Arne Vajhøj wrote:
>
>> You know what a daemon is.
>>
>> Besides the web integration with Apache and IIS that accounts for 99+%
>> of PHP usage, then PHP also comes with a command line utility.
>>
>> So you can write a daemon in PHP and run it via the command line
>> utility.
>>
> Thanks for the clarification. I thought you must have been talking about
> some special PHP daemonising framework or library.

Nope. Just not very good at explaining what I meant.

Arne

[toc] | [prev] | [next] | [standalone]

#19758

On Wed, 14 Nov 2012 16:55:33 -0500, Arne Vajhøj wrote:

> On 11/14/2012 4:33 PM, Martin Gregorie wrote:
>> On Tue, 13 Nov 2012 17:31:22 -0500, Arne Vajhøj wrote:
>>
>>> You know what a daemon is.
>>>
>>> Besides the web integration with Apache and IIS that accounts for 99+%
>>> of PHP usage, then PHP also comes with a command line utility.
>>>
>>> So you can write a daemon in PHP and run it via the command line
>>> utility.
>>>
>> Thanks for the clarification. I thought you must have been talking
>> about some special PHP daemonising framework or library.
> 
> Nope. Just not very good at explaining what I meant.
>
Probably same here. I have written a batch-type program in PHP but would 
probably not do it again because I think there are better languages for 
that. This program walks a directory structure, generating thumbnails of 
all the images it finds. Its companion (still in PHP under Apache) 
generates menus if thumbnails on the fly. Its first cut generated the 
thumbnails as needed, but that was deadly slow, hence the overnight batch 
directory walker.

I ended up rewriting the thumbnail generating program in Java and dumping 
the PHP version when I needed a non-trivial enhancement (the ability to 
generate permanent HTML menu pages. As a bonus, the Java version is 
significantly faster which is quite surprising considering its run is 
fairly short - 2-3 seconds on a typical run when it finds nothing to do 
in the 600+ directories it looks at.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#19732

David Lamb wrote:
> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>> Since java also adopts the garbage collector mechanism, would java
>> daemon suffers from the same memory problem ?
>
> There are several different ways to do garbage collection, so flaws in
> one implementation have no bearing on what goes on with another.
>
> The most common complaint that crosses implementations is the
> unpredictability of when a gc happens, which can be a problem for a
> program with serious real-time constraints. IIRC Java implementations
> often have the gc run continuously and incrementally in a separate
> thread, which evens out the effect.

I did some google'ing on garbage collector (GC) in java and found that it is 
a big and complicated topic.
Java programmer has no permission to invoke it directly, beside juggling its 
settings to adjust its frequency of running and the type of collector to 
run. Even then how the GC is invoked stilll lies beyond programmer's 
control.

It gets me thinking.

Why bother with it (people in the finance trade especially) ? Are the 
advantages so great over c/c++ ? If the answer is yes, I can only think that 
the reason is portability. Otherwise forget about tweaking GC; go for C/C++; 
programmer has full control over memory management, and it is faster than 
java.

I hope my opinion does not ignite the ire of java people.

I do have a question on GC: how to run the GC continuously ? Create a 
thread, do some memory juggling to induce the GC to run ?

[toc] | [prev] | [next] | [standalone]

#19733

On Tue, 13 Nov 2012 14:40:23 +0800, SL wrote:

> [...]
> Why bother with it (people in the finance trade especially) ? Are the 
> advantages so great over c/c++ ? If the answer is yes, I can only think that 
> the reason is portability. Otherwise forget about tweaking GC; go for C/C++; 
> programmer has full control over memory management, and it is faster than 
> java.
> 
> I hope my opinion does not ignite the ire of java people.

Probably not. Most of the "Java people" are secure enough in their
knowledge that they are using the right tool for the job to not worry about
what some person grinding an anti-Java axe might have to say.

Fact is, a) it is not a foregone conclusion that explicit memory management
is faster than GC. It depends a lot on the implementation, and GC-based
memory management has certain scenarios where it wins (allocations are
practically free, and a generational collector can do very well speed-wise
when dealing with large numbers of short-lived objects.

There's a fair amount of overhead maintaining a C-style heap, incurred
during both allocation and deallocation of memory blocks.  It's just that
the overhead is more deterministic than what you see in GC systems.

And b) speed is not always the first priority anyway.  An inordinately
large proportion of bugs found in a C/C++ program are memory-related.  The
managed environment found in languages like Java protects against these
bugs.  Things such as invalid pointers and inaccessible blocks of allocated
memory (aka "leaks") are a thing of the past with a GC system.

A program that runs fast is nice, but if required to choose, I'd rather
have a program that runs correctly.

Pete

[toc] | [prev] | [next] | [standalone]

#19734

Peter Duniho wrote:
>
> Probably not. Most of the "Java people" are secure enough in their
> knowledge that they are using the right tool for the job to not worry
> about what some person grinding an anti-Java axe might have to say.
>....
>

I have no axe to grind, Peter.

I have hardly programmed beyond "Helo World" in java. The above was just my 
personal opinion, it could be very well wrong.

I am just hoping to learn some more esoteric facts about about java and 
c/c++, which only people with a lot of experiece can give.

I remember what my former once said:

"Read about people's biograhy. They take a life time to attain their 
achievements, and the reader takes 1 to 2 weeks to learn them. I don't think 
there is a better deal."

[toc] | [prev] | [next] | [standalone]

#19737

On 11/13/2012 02:40 AM, SL wrote:
> David Lamb wrote:
>> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>>> Since java also adopts the garbage collector mechanism, would java
>>> daemon suffers from the same memory problem ?
>>
>> There are several different ways to do garbage collection, so flaws in
>> one implementation have no bearing on what goes on with another.
>>
>> The most common complaint that crosses implementations is the
>> unpredictability of when a gc happens, which can be a problem for a
>> program with serious real-time constraints. IIRC Java implementations
>> often have the gc run continuously and incrementally in a separate
>> thread, which evens out the effect.
>
> I did some google'ing on garbage collector (GC) in java and found that it is
> a big and complicated topic.
> Java programmer has no permission to invoke it directly, beside juggling its
> settings to adjust its frequency of running and the type of collector to
> run. Even then how the GC is invoked stilll lies beyond programmer's
> control.
>
> It gets me thinking.
>
> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ? If the answer is yes, I can only think that
> the reason is portability. Otherwise forget about tweaking GC; go for C/C++;
> programmer has full control over memory management, and it is faster than
> java.
>
> I hope my opinion does not ignite the ire of java people.
[ SNIP ]

No ire on my part. I back up what Peter said (particularly with respect 
to maintenance and reliability), and I'll add a few remarks of my own.

Think about why you'd want to invoke the Java GC yourself, and what that 
would entail. You'd want to know *when* to do it - if you wrote the code 
yourself to make that decision, and you were really good and really 
experienced, it would probably look a lot like _existing_ code for some 
GC or another. If you weren't that good then your code just wouldn't cut it.

By "code" I mean both the actual source and the GC parameters that you 
can tune.

At first glance it might seem like this indirection - setting parameters 
- removes a lot of control. That's not the case.

I'm not saying this is you - you already said it's not - but people who 
assert that they can do better decision-making as to when to invoke a GC 
run than the code that represents years of experience of GC specialists 
strike me in the same vein as people who assert they can get better gas 
mileage using manual stick than people who drive modern automatic 
transmission cars. A very few people *can* do that - the majority (huge 
majority) can't.

AHS

[toc] | [prev] | [next] | [standalone]

#19738

On 13/11/2012 1:40 AM, SL wrote:
> David Lamb wrote:
>> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>>> Since java also adopts the garbage collector mechanism, would java
>>> daemon suffers from the same memory problem ?
>>
>> There are several different ways to do garbage collection, so flaws in
>> one implementation have no bearing on what goes on with another.
> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ? If the answer is yes, I can only think that
> the reason is portability. Otherwise forget about tweaking GC; go for C/C++;
> programmer has full control over memory management, and it is faster than
> java.

GC has several big advantages over programmer control, one of them being 
how often programmers get things wrong. A bug-free GC can be written 
once, by experts, tested thoroughly, then lives on not subject to bugs 
introduced by thousands of programmers across the hundreds of packages 
you might use in any one program.

You never get reuse of already-deallocated memory, a classic source of 
segmentation faults.

You never get the most common forms of memory leak, forgetting to 
deallocate and losing the last pointer to the allocated memory. Though 
people can misprogram to have long-lived structures point to ones no 
longer needed; dunno how common that is. Technically this does not count 
as a "memory leak"; rather it's "keeping data around too long that you 
can still free eventually".

A compactifying GC can also *speed up* memory allocation and *reduce* 
heap footprint by reducing fragmentation.

[toc] | [prev] | [next] | [standalone]

#19744

In article <k7sq0e$poi$1@news.albasani.net>, "SL" <sb5309@hotmail.com> 
wrote:

> I do have a question on GC: how to run the GC continuously ? Create a 
> thread, do some memory juggling to induce the GC to run ?

On my platform, the JVM automatically spawns several threads to 
facilitate garbage collection, including one called "Concurrent 
Mark-Sweep GC Thread," which runs at a moderately lower priority than 
the event queue. The host's scheduler uses multiple cores (when 
available) to balance the load in favor of the user. The overall effect 
is that even "busy" programs remain responsive, and I rarely notice GC 
unless I'm looking for it, say in a profiler.

IIUC, the exact number and names of threads is platform-dependent. You 
can use jvisualvm, included with the JDK, to see a thread timeline; or 
you can take a snapshot of running threads via `kill -SIGQUIT pid`.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#19795

On 11/13/2012 1:40 AM, SL wrote:
> I did some google'ing on garbage collector (GC) in java and found that it is
> a big and complicated topic.

It certainly is.

> Java programmer has no permission to invoke it directly, beside juggling its
> settings to adjust its frequency of running and the type of collector to
> run. Even then how the GC is invoked stilll lies beyond programmer's
> control.
>
> It gets me thinking.
>
> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ?

Yes.

GC is a lot better than manual deallocation for non realtime
usage as programmer tend to forget to deallocate resulting
in memory leaks.

And there are also other areas where the programmers end up
misusing the control that C++ provides you.

>                              If the answer is yes, I can only think that
> the reason is portability.

That is one reason but there are plenty of other.

>                            Otherwise forget about tweaking GC;

Yes. Because 99.999% of developers can not do a better job than what
the GC specialists has designed.

>                                                 go for C/C++;
> programmer has full control over memory management,

Which is a very good reason for not choosing C/C++ unless you
have special requirements like realtime, hardware interface or
kernel code.

>                                         and it is faster than
> java.

That is not always the case.

> I do have a question on GC: how to run the GC continuously ? Create a
> thread, do some memory juggling to induce the GC to run ?

The GC should not run continuously - that would be very bad for
performance.

Arne

[toc] | [prev] | [next] | [standalone]

#19796

On 11/12/2012 10:40 PM, SL wrote:

> I do have a question on GC: how to run the GC continuously ? Create a
> thread, do some memory juggling to induce the GC to run ?


I haven't been following closely, so I don't know what version of Java 
you're working with, but a web search for "java garbage collection 
tuning" usually gives lots of good hits.

<http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors>

You probably want the parallel GC or the concurrent GC.  And no, you do 
not create a new thread or "juggle memory," you configure it externally 
to your application.

Also, take a look at the System.gc() call, but DON'T USE THAT unless 
you're sure you need it.  The garbage collector is probably smarter than 
you are about when and how to collect unused memory, frankly.

<http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc>

[toc] | [prev] | [next] | [standalone]

#19816

Le 18/11/2012 23:02, markspace a écrit :
> On 11/12/2012 10:40 PM, SL wrote:
>
>> I do have a question on GC: how to run the GC continuously ? Create a
>> thread, do some memory juggling to induce the GC to run ?
>
>
> I haven't been following closely, so I don't know what version of Java
> you're working with, but a web search for "java garbage collection
> tuning" usually gives lots of good hits.
>
> <http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors>
>
>
> You probably want the parallel GC or the concurrent GC.  And no, you do
> not create a new thread or "juggle memory," you configure it externally
> to your application.
>
> Also, take a look at the System.gc() call, but DON'T USE THAT unless
> you're sure you need it.  The garbage collector is probably smarter than
> you are about when and how to collect unused memory, frankly.
>
> <http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc>
>
>
>
>
If the OP uses a JVM Java HotSpot 7 ( Oracle or Open JDK) , he can take 
a look to the G1 ( G first) garbage collector. It is an improve of the 
CMS garbage collector. This garbage collector is more "Real Time" than 
the others garbage collectors.

-- 
Cordialement
Jean-Louis Pasturel

[toc] | [prev] | [next] | [standalone]

#19827

On Tue, 20 Nov 2012 03:39:10 +0800, jlp <jlp@jlp.com> wrote:

> If the OP uses a JVM Java HotSpot 7 ( Oracle or Open JDK) , he can take  
> a look to the G1 ( G first) garbage collector. It is an improve of the  
> CMS garbage collector. This garbage collector is more "Real Time" than  
> the others garbage collectors.
>

I decide that I have windows c/c++ programming that I think I can get a  
daemon in C to run by month-end, since my daemon deals with XML processing  
and MySQL, and of course communicating over sockets.

Hope that you people are in the C/C++ Linux group, which I shall turn to  
if I get stuck. :-)

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

[toc] | [prev] | [next] | [standalone]

#19712

On 11/12/2012 9:17 AM, sl@exabyte wrote:
> I gather that PHP daemon suffers from memory leak problem due to its garbage
> collector mechanism.
>
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?

PHP uses reference counting, which has some known problems (circular
references).

It is typical not a big problem in PHP due to everything going out
when request scope runs out.

(that of course does not cover native resources in extensions,
but Java does not do anything with those either)

There are many Java implementations and most of them support
multiple garbage collection algorithms, so it is difficult to say
what "Java" does.

But all the most popular uses some type of mark and sweep to
find what is still reachable and what is not.

That does not have the same problems as reference counting.

So assuming that you use a common Java implementation, then
you should not see the same problems as in PHP.

Arne

[toc] | [prev] | [next] | [standalone]

#19718

"sl@exabyte" <sb5309@hotmail.com> writes:

> I gather that PHP daemon suffers from memory leak problem due to its garbage 
> collector mechanism.
>
> Since java also adopts the garbage collector mechanism, would java daemon 
> suffers from the same memory problem ?

Probably not: not all implementations of GC are equal, and you can't
generalize from one to another.  For what it's worth, Twitter is in the
process of migrating from Ruby to Java due to problems with memory
management, and claims to be happy with the results:

http://www.theregister.co.uk/2012/11/08/twitter_epic_traffic_saved_by_java/

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#19719

Jim Janney wrote:
> "sl@exabyte" writes:
>> I gather that PHP daemon suffers from memory leak problem due to its garbage 
>> collector mechanism.

More likely it suffers from a packratting problem - failure to release memory.

>> Since java also adopts the garbage collector mechanism, would java daemon 
>> suffers from the same memory problem ?

Not the same problem, but you can force Java to hang on to object references long 
past their usefulness, and eventually use up your available memory.

Idiomatic Java avoids this.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#19727

On 11/12/2012 4:35 PM, Lew wrote:
> Jim Janney wrote:
>> "sl@exabyte" writes:
>>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>>> collector mechanism.
>
> More likely it suffers from a packratting problem - failure to release memory.

Reference counted GC has known problems even without packratting.

>>> Since java also adopts the garbage collector mechanism, would java daemon
>>> suffers from the same memory problem ?
>
> Not the same problem, but you can force Java to hang on to object references long
> past their usefulness, and eventually use up your available memory.
>
> Idiomatic Java avoids this.

And none of the common Java implementations use reference counting for GC.

Arne

[toc] | [prev] | [next] | [standalone]

#19793

On 11/12/2012 4:24 PM, Jim Janney wrote:
> "sl@exabyte" <sb5309@hotmail.com> writes:
>
>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>> collector mechanism.
>>
>> Since java also adopts the garbage collector mechanism, would java daemon
>> suffers from the same memory problem ?
>
> Probably not: not all implementations of GC are equal, and you can't
> generalize from one to another.  For what it's worth, Twitter is in the
> process of migrating from Ruby to Java due to problems with memory
> management, and claims to be happy with the results:
>
> http://www.theregister.co.uk/2012/11/08/twitter_epic_traffic_saved_by_java/

The article is not very specific - "manage memory more efficiently" do
not tell much about the issues.

But other sources explain. Ruby do use mark and sweep like Java and
not ref count as PHP. But it has no generations and are global stop
during the entire GC. Which is not as good as modern Java GC's.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web