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

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

compile directly into a .zip/.jar file?

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

Contents

  compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-12 12:30 +0000
    Re: compile directly into a .zip/.jar file? Joerg Meier <joergmmeier@arcor.de> - 2014-04-12 15:02 +0200
      Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-12 19:56 -0700
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 15:29 +0000
      Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 15:19 +0000
        Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-13 17:35 -0700
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 13:53 -0400
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 22:21 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 18:40 -0400
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-13 14:04 -0400
        Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 22:52 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-14 21:41 -0400
            Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-15 12:51 +0000
              Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-15 20:00 -0400
                Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 12:29 +0000
                  Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 10:58 -0400
                    Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 12:45 -0400
                      Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 19:33 +0000
                        Re: compile directly into a .zip/.jar file? Jeff Higgins <jeff@invalid.invalid> - 2014-04-16 15:48 -0400
                        Re: compile directly into a .zip/.jar file? Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-04-16 16:20 -0400
                          Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 22:31 +0000
                    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 18:43 +0000
                  Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-16 18:33 -0400
                    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-17 12:58 +0000
    Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-12 19:54 -0700
      Re: compile directly into a .zip/.jar file? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-04-13 16:08 +0000
    Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-13 23:25 +0000
      Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-14 21:40 -0400
        Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-15 13:38 +0000
          Re: compile directly into a .zip/.jar file? Arne Vajhøj <arne@vajhoej.dk> - 2014-04-15 19:49 -0400
            Re: compile directly into a .zip/.jar file? Martin Gregorie <martin@address-in-sig.invalid> - 2014-04-16 12:38 +0000
    Re: compile directly into a .zip/.jar file? Roedy Green <see_website@mindprod.com.invalid> - 2014-04-13 17:38 -0700

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

#28111

On Wed, 16 Apr 2014 16:20:19 -0400, Eric Sosman wrote:

> On 4/16/2014 3:33 PM, Martin Gregorie wrote:
>> On Wed, 16 Apr 2014 12:45:54 -0400, Jeff Higgins wrote:
>>
>>> On 04/16/2014 10:58 AM, Jeff Higgins wrote:
>>>
>>>> as an adjunct to the manpages
>>> Schedule this. A memento for me.
>>> Kernel Korner - I/O Schedulers - Robert Love
>>> <http://www.linuxjournal.com/article/6931>
>>
>> Hate to say this, but I was using a a box with a scheduler that was at
>> least as good as the Anticipatory Scheduler way back in 1972 on an ICL
>> 1903S mainframe running the George 3 Mk 6 OS.
>>
>> George 3 used a similar directory structure to Unix/Linux. Its i/o
>> scheduler was, however, quite a bit different. This maintained two i/o
>> queues and a vector for each disk. The vector kept book on where the
>> heads were and which direction they were travelling. One of the queues
>> held requests for blocks that were 'in front' of the heads and the
>> other queue held requests for blocks 'behind' the heads. Both queues
>> were sorted. When the 'in front' queue was empty, the queues were
>> swapped and the vector reversed, so in practise the heads floated
>> smoothly back and forth across the disk while sounding like castenet
>> dancer on speed and the i/o rate was much higher than earlier versions,
>> without the i/o scheduler, or the manual UDAS executive could manage.
>> [...]
> 
>      An issue (not necessarily "problem") with this approach is that
> the tracks near the inner and outer extremes get fewer/slower accesses
> than those near the middle.[*]  That could be turned to advantage,
> by allocating frequently-used files in the favored area and relegating
> less-used material to the frozen fringes -- but then you're sort of back
> in the days of fixed (usually manual) allocations.
> 
>      [*] I once heard an instructor explain it this way: He asked us
> to think of three friends sitting on a bench, passing a can of beer back
> and forth.  Friend A on one end takes a swig and hands the can to B in
> the middle, who takes a swig and hands it on to C on the other end, who
> takes his swig and hands the can -- to whom?  To his only neighbor, B. 
> The swigging sequence is ABCBABCBAB... with B getting half the beer
> while A and C split the rest.
>
I'm certain you're right, but I don't remember ever hearing how George 
placed files in its filestore so can't add anything about its file 
allocation strategy.

I know that files moved. This was back in the days when disk was scarce 
and expensive, so its disk usage strategy reflected that: 

- it did automatic incremental backups at configurable intervals to
  magnetic tape. You could do 1-3 copies in parallel.

- if it was getting short of disk space, the Backing Store Unjammer
  started up. This freed up space by erasing the online copies of the
  largest files that had not been accessed for the longest time and 
  which had offline backups until it had freed sufficient space.

- if a user or batch job needed a file that had been thrown offline,
  it automatically asked the operator to put a tape containing it online
  and copied the file back to disk. Its scripting language also allowed
  a user or batch job to issue retrieves ahead of time for all the files
  that would be needed.

A couple of other of George's features that may give you some useful 
ideas are:

Separating error handlers from main line code
---------------------------------------------
George was written in chapters: each was a small, relocatable block of 
code that carried out a single task. Early on it was realised that George 
would run faster if very OS task was split in two: one chapter contained 
the error-free path and the other contained error handling code. This 
added speed because the error handlers are generally used infrequently 
and so it didn't matter if the error handlers were slow. Meanwhile, the 
limited memory[*] could keep many more frequently used chapters in memory 
if their error handling code was left on disk until needed. This may also 
work with modern paging systems.

* 1900s used a fixed length instruction set. Each 24 bit word could hold 
one instruction or four 6-bit characters. Our 1903S had 32 Kwords (128 
Kchars) of memory which allowed us to support 4-6 online users, a 
background job, spooled input (cards or paper tape) and printed output.
It had a 3.6 uS clock cycle but, despite this, handled its KSR33 teletypes 
smartly enough that you weren't concious of it being slow.

Minimising unwanted trace logging
---------------------------------
The guts of George is where my favourite way of minimising debug traces 
came from: instead of logging everything, you write tracing into a 
circular buffer and, if an error occurs, you dump the buffer before 
outputting the error and stopping. You size the buffer to suit the amount 
of trace lines you need to localise the problem - generally 50-100 trace 
lines is enough. This works really well for long-running processes that 
only occasionally mess up because you don't end up with several megabytes 
of tracing to search through when you're trying to find the interesting 
bits and their causes. 

Needless to say, my ReportError Java class has this implemented as an 
optional tracing facility.


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

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

#28107

On Wed, 16 Apr 2014 10:58:46 -0400, Jeff Higgins wrote:

> On 04/16/2014 08:29 AM, Martin Gregorie wrote:
>> On Tue, 15 Apr 2014 20:00:22 -0400, Arne Vajhøj wrote:
>>
>>> AFAIK then fflush only move data from user space to system space.
>>>
>>> To get data on the plates you need fsync.
>>>
>> The manpages for fflush()m and fsync() could be a little clearer, but I
>> read them as saying that both functions force a write to disk. The only
>> difference is the type of file reference argument they take: fflush()
>> takes a FILE* stream reference while fsync() takes an int file
>> description.
>>
>> That is pretty much the same as the difference between read() and
>> fread()
>> or write() and fwrite().
>>
>>
> as an adjunct to the manpages "The Linux Programming Interface"
> 13.3 Controlling Kernel Buffering of File I/O
> <http://books.google.com/books?id=Ps2SH727eCIC&pg=PA239>

Interesting. If I didn't already have O'Reilly's Lion book(Unix Sys V 
System Programming), Pthreads (POSIX Threads) and Unix in a Nutshell, I'd 
want it; it covers pretty much the same ground as those three, and 
probably with a similar page count too.

However, I am surprised it omits all coverage of writing easily 
internationalised code and curses, but, hey, my equivalents don't cover 
those topics either.


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

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

#28112

On 4/16/2014 8:29 AM, Martin Gregorie wrote:
> On Tue, 15 Apr 2014 20:00:22 -0400, Arne Vajhøj wrote:
>
>> AFAIK then fflush only move data from user space to system space.
>>
>> To get data on the plates you need fsync.
>>
> The manpages for fflush()m and fsync() could be a little clearer, but I
> read them as saying that both functions force a write to disk. The only
> difference is the type of file reference argument they take: fflush()
> takes a FILE* stream reference while fsync() takes an int file
> description.

Linux man pages are rather clear:

<quote>
Notes
Note that fflush() only flushes the user-space buffers provided by the C 
library. To ensure that the data is physically stored on disk the kernel 
buffers must be flushed too, for example, with sync(2) or fsync(2).
</quote>

Arne

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

#28118

On Wed, 16 Apr 2014 18:33:10 -0400, Arne Vajhøj wrote:

> On 4/16/2014 8:29 AM, Martin Gregorie wrote:
>> On Tue, 15 Apr 2014 20:00:22 -0400, Arne Vajhøj wrote:
>>
>>> AFAIK then fflush only move data from user space to system space.
>>>
>>> To get data on the plates you need fsync.
>>>
>> The manpages for fflush()m and fsync() could be a little clearer, but I
>> read them as saying that both functions force a write to disk. The only
>> difference is the type of file reference argument they take: fflush()
>> takes a FILE* stream reference while fsync() takes an int file
>> description.
> 
> Linux man pages are rather clear:
> 
> <quote>
> Notes Note that fflush() only flushes the user-space buffers provided by
> the C library. To ensure that the data is physically stored on disk the
> kernel buffers must be flushed too, for example, with sync(2) or
> fsync(2). </quote>
>
Don't think so:

fsync() flushes a single file all the way to disk according to its 
manpage, which says that it makes the file safe against crashes and 
reboots. So does fflush(), because it, also according to its manpage, by 
calling fsync() on the filedesc underlying the FILE* passed to fflush(). 
There's an extension: fflush(NULL) flushes all streams opened by the 
process.

sync() is rather different. It flushes all buffetrs belonging to all open 
files regardless of which process is using them.
   

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

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

#28050

On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>Is it possible to compile directly into a .zip/.jar file?

I have not seen anything.  I use genjar which is very quick. I don't
know if they have a version for your OS.

The big advantage is you just give it the main class and your
resources and it finds all the classes it needs. You have to tell it
about anything you load via classForName.

see http://mindprod.com/jgloss/genjar.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

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

#28066

Roedy Green <see_website@mindprod.com.invalid> wrote:
> <avl@auth.logic.tuwien.ac.at> [...] said :
>> Is it possible to compile directly into a .zip/.jar file?
> I have not seen anything.

At least I haven't just missed anything obvious.

> I use genjar which is very quick. I don't
> know if they have a version for your OS.

Although that doesn't address the problem I posted, it seems
to fit a separate problem that I've been putting off so far.

Thanks!

On your page, you say that to get genjar2 one needs mercurial,
but in the source-tab, when you click "Browse" then you're
also offered to download a .zip .  There may of course be
reasons to stick with mercurial, but it's good to know one's
options.

> see http://mindprod.com/jgloss/genjar.html

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

#28073

On Sat, 12 Apr 2014 12:30:12 +0000, Andreas Leitgeb wrote:

> PPS: I'm not an expert of AIX, so if there are better filesystems than
> jfs2,
>
What sort of kernel does AIX use? 

I've had dire performance from a MACH-type kernel (this was DEC TrueUnix) 
when a lot of files were being accessed. IIRC this turned out to be due 
to the kernel serialising calls on lstat() when the RedBrick datawarehouse 
was checking access permissions on the files it used to store schema 
components.


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

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

#28085

On 4/13/2014 7:25 PM, Martin Gregorie wrote:
> On Sat, 12 Apr 2014 12:30:12 +0000, Andreas Leitgeb wrote:
>> PPS: I'm not an expert of AIX, so if there are better filesystems than
>> jfs2,
>>
> What sort of kernel does AIX use?

Traditional Unix based on SysV.

Arne

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

#28092

On Mon, 14 Apr 2014 21:40:05 -0400, Arne Vajhøj wrote:

> On 4/13/2014 7:25 PM, Martin Gregorie wrote:
>> On Sat, 12 Apr 2014 12:30:12 +0000, Andreas Leitgeb wrote:
>>> PPS: I'm not an expert of AIX, so if there are better filesystems than
>>> jfs2,
>>>
>> What sort of kernel does AIX use?
> 
> Traditional Unix based on SysV.
>
OK, though I think that may be true of all Unices since System V, unless 
they were very old or BSD. AFAIK all Linuxes used the SysV init until 
recently, when Systemd rocked onto the scene. However, what I meant was 
was what architecture does it have, e.g. a traditional monolithic kernel, 
a microkernel, or a Mach-style message-passing design: from a web search 
it appears that its a traditional monolithic kernel architecture.


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

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

#28096

On 4/15/2014 9:38 AM, Martin Gregorie wrote:
> On Mon, 14 Apr 2014 21:40:05 -0400, Arne Vajhøj wrote:
>> On 4/13/2014 7:25 PM, Martin Gregorie wrote:
>>> On Sat, 12 Apr 2014 12:30:12 +0000, Andreas Leitgeb wrote:
>>>> PPS: I'm not an expert of AIX, so if there are better filesystems than
>>>> jfs2,
>>>>
>>> What sort of kernel does AIX use?
>>
>> Traditional Unix based on SysV.
>>
> OK, though I think that may be true of all Unices since System V, unless
> they were very old or BSD. AFAIK all Linuxes used the SysV init until
> recently, when Systemd rocked onto the scene. However, what I meant was
> was what architecture does it have, e.g. a traditional monolithic kernel,
> a microkernel, or a Mach-style message-passing design: from a web search
> it appears that its a traditional monolithic kernel architecture.

The widely used label for the modern traditional Unixes are "Monolithic
with dynamically loadable modules".

Arne

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

#28103

On Tue, 15 Apr 2014 19:49:41 -0400, Arne Vajhøj wrote:

> On 4/15/2014 9:38 AM, Martin Gregorie wrote:
>> On Mon, 14 Apr 2014 21:40:05 -0400, Arne Vajhøj wrote:
>>> On 4/13/2014 7:25 PM, Martin Gregorie wrote:
>>>> On Sat, 12 Apr 2014 12:30:12 +0000, Andreas Leitgeb wrote:
>>>>> PPS: I'm not an expert of AIX, so if there are better filesystems
>>>>> than jfs2,
>>>>>
>>>> What sort of kernel does AIX use?
>>>
>>> Traditional Unix based on SysV.
>>>
>> OK, though I think that may be true of all Unices since System V,
>> unless they were very old or BSD. AFAIK all Linuxes used the SysV init
>> until recently, when Systemd rocked onto the scene. However, what I
>> meant was was what architecture does it have, e.g. a traditional
>> monolithic kernel,
>> a microkernel, or a Mach-style message-passing design: from a web
>> search it appears that its a traditional monolithic kernel
>> architecture.
> 
> The widely used label for the modern traditional Unixes are "Monolithic
> with dynamically loadable modules".
> 
I'm not disagreeing. The main split I wanted to emphasize is between 
traditional monolithic kernels and MACH-type message-passing microkernels 
because, apart from all its other overheads, the latter tends to 
introduce serialising overheads if something you ask it to do really 
hammers a particular kernel server type. At least that was the case with 
the DEC TrueUnix OS running on alphaservers.


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

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

#28079

On Sat, 12 Apr 2014 12:30:12 +0000 (UTC), Andreas Leitgeb
<avl@auth.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>Is it possible to compile directly into a .zip/.jar file?

ANT speeds things up incredibly because it loads the various
processors and keeps them in ram, rather the loading them over and
over the way a make script would.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"Don't worry about people stealing an idea; if it's original, you'll
 have to shove it down their throats." 
~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)

[toc] | [prev] | [standalone]

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

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

csiph-web