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

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

Using jar inside a jar

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

Contents

  Using jar inside a jar Cecil Westerhof <Cecil@decebal.nl> - 2015-01-22 11:48 +0100
    Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-22 11:28 +0000
      Re: Using jar inside a jar Cecil Westerhof <Cecil@decebal.nl> - 2015-01-22 13:05 +0100
        Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-22 13:46 +0100
          Re: Using jar inside a jar Jeff Higgins <jeff@invalid.invalid> - 2015-01-22 08:15 -0500
            Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-22 16:30 +0100
          Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-22 14:18 +0000
            Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-22 16:29 +0100
              Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-23 11:10 +0000
                Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-23 13:12 +0100
                  Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-23 15:46 +0000
                    Re: Using jar inside a jar Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-23 11:18 -0500
                    Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-23 22:42 +0100
                      Re: Using jar inside a jar Jerry Stuckle <jstucklex@attglobal.net> - 2015-01-23 17:02 -0500
                        Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-24 14:14 +0100
                          Re: Using jar inside a jar Martin Gregorie <martin@address-in-sig.invalid> - 2015-01-24 15:33 +0000
                      Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-26 09:28 +0000
                        Re: Using jar inside a jar Joerg Meier <joergmmeier@arcor.de> - 2015-01-26 21:14 +0100
                          Re: Using jar inside a jar Jerry Stuckle <jstucklex@attglobal.net> - 2015-01-26 15:23 -0500
                          Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-28 14:19 +0000
                Re: Using jar inside a jar Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-01-24 11:46 +0000
          Re: Using jar inside a jar Wayne <nospam@all.invalid> - 2015-01-23 00:47 -0500
          Re: Using jar inside a jar Silvio <silvio@internet.com> - 2015-01-23 12:28 +0100
        Re: Using jar inside a jar Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-22 14:18 +0000

Page 1 of 2  [1] 2  Next page →

#30784 — Using jar inside a jar

To compile a program I use:
    javac -classpath ../ShowMemory/ShowMemory.jar \
          -Xlint:all \
          -Werror \
          PanelTools.java

To create a jar I use:
    jar   -cvfm PanelTools.jar \
          MANIFEST.MF \
          images \
          -C ../ShowMemory ShowMemory.jar \
          *.class

The MANIFEST.MF contains:
    Manifest-Version: 1.0
    Main-Class: PanelTools
    Class-Path: ShowMemory.jar

But when I execute the program with:
    java -jar PanelTools.jar &

I get:
    Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: nl/decebal/utilities/ShowMemory

What am I doing wrong?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#30785

On 22/01/15 10:48, Cecil Westerhof wrote:
> To compile a program I use:
>      javac -classpath ../ShowMemory/ShowMemory.jar \
>            -Xlint:all \
>            -Werror \
>            PanelTools.java
>
> To create a jar I use:
>      jar   -cvfm PanelTools.jar \
>            MANIFEST.MF \
>            images \
>            -C ../ShowMemory ShowMemory.jar \
>            *.class
>
> The MANIFEST.MF contains:
>      Manifest-Version: 1.0
>      Main-Class: PanelTools
>      Class-Path: ShowMemory.jar
>
> But when I execute the program with:
>      java -jar PanelTools.jar &
>
> I get:
>      Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: nl/decebal/utilities/ShowMemory
>
> What am I doing wrong?
>

Java needs to know where to locate ShowMemory.jar.  The only information it has is the Class-Path: entry in MANIFEST.MF. 
This entry only has a bare filename, so Java looks for it in the same directory as the jar file it is executing.

You have various options, none of which are perfect.
1) You can embed an absolute path in the manifest. Ok if the dependency jar will always be in the same place.
2) You can use a relative path in the manifest. Better, but still only works if the jar and the dependency will always 
have the same relative locations.
3) Basically option 2, but during the build process copy all dependency jar's to a fixed location relative to the main 
jar (e.g. lib/), and use that relative path in the manifest. Best option, as it means you can package the jar and its 
dependency tree if you need to relocate it.

Ok, so I'm sure someone will point out that there is a another option, to do with $JAVA_HOME/lib/ext. But I think it's a 
bad idea and I won't explain it.

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

#30787

Op Thursday 22 Jan 2015 12:28 CET schreef Nigel Wade:

> On 22/01/15 10:48, Cecil Westerhof wrote:
>> To compile a program I use:
>> javac -classpath ../ShowMemory/ShowMemory.jar \
>> -Xlint:all \
>> -Werror \
>> PanelTools.java
>>
>> To create a jar I use:
>> jar   -cvfm PanelTools.jar \
>> MANIFEST.MF \
>> images \
>> -C ../ShowMemory ShowMemory.jar \
>> *.class
>>
>> The MANIFEST.MF contains:
>> Manifest-Version: 1.0
>> Main-Class: PanelTools
>> Class-Path: ShowMemory.jar
>>
>> But when I execute the program with:
>> java -jar PanelTools.jar &
>>
>> I get: Exception in thread "AWT-EventQueue-0"
>> java.lang.NoClassDefFoundError: nl/decebal/utilities/ShowMemory
>>
>> What am I doing wrong?
>>
>
> Java needs to know where to locate ShowMemory.jar. The only
> information it has is the Class-Path: entry in MANIFEST.MF. This
> entry only has a bare filename, so Java looks for it in the same
> directory as the jar file it is executing.
>
> You have various options, none of which are perfect. 1) You can
> embed an absolute path in the manifest. Ok if the dependency jar
> will always be in the same place. 2) You can use a relative path in
> the manifest. Better, but still only works if the jar and the
> dependency will always have the same relative locations. 3)
> Basically option 2, but during the build process copy all dependency
> jar's to a fixed location relative to the main jar (e.g. lib/), and
> use that relative path in the manifest. Best option, as it means you
> can package the jar and its dependency tree if you need to relocate
> it.

It is not possible to use the jar that I put into the jar file? I
would prefer to use only one jar file. But if that is not possible, I
will go for option 3.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#30789

On Thu, 22 Jan 2015 13:05:11 +0100, Cecil Westerhof wrote:

> It is not possible to use the jar that I put into the jar file? I
> would prefer to use only one jar file. But if that is not possible, I
> will go for option 3.

Certainly it is possible to pack everything into one jar, and that is what
the vast majority of people do. I'm not sure why Nigel recommended none of
the many standard solutions to this problem:

- FatJar
- OneJar
- Maven Shade
- Maven Assembly
- Gradle
- WARs
- Custom ANT task

Pick whichever you like best.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30790

On 01/22/2015 07:46 AM, Joerg Meier wrote:
> On Thu, 22 Jan 2015 13:05:11 +0100, Cecil Westerhof wrote:
>
>> It is not possible to use the jar that I put into the jar file? I
>> would prefer to use only one jar file. But if that is not possible, I
>> will go for option 3.
>
> Certainly it is possible to pack everything into one jar, and that is what
> the vast majority of people do. I'm not sure why Nigel recommended none of
> the many standard solutions to this problem:
>
> - FatJar
> - OneJar
> - Maven Shade
> - Maven Assembly
> - Gradle
> - WARs
> - Custom ANT task
>
> Pick whichever you like best.
>
Or get ahead of the train.
<http://openjdk.java.net/projects/jigsaw/doc/quickstart.html>

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

#30800

On Thu, 22 Jan 2015 08:15:00 -0500, Jeff Higgins wrote:

> On 01/22/2015 07:46 AM, Joerg Meier wrote:
>> On Thu, 22 Jan 2015 13:05:11 +0100, Cecil Westerhof wrote:
>>> It is not possible to use the jar that I put into the jar file? I
>>> would prefer to use only one jar file. But if that is not possible, I
>>> will go for option 3.
>> Certainly it is possible to pack everything into one jar, and that is what
>> the vast majority of people do. I'm not sure why Nigel recommended none of
>> the many standard solutions to this problem:

>> - FatJar
>> - OneJar
>> - Maven Shade
>> - Maven Assembly
>> - Gradle
>> - WARs
>> - Custom ANT task

>> Pick whichever you like best.
> Or get ahead of the train.
> <http://openjdk.java.net/projects/jigsaw/doc/quickstart.html>

I'm not sure how useful recommending an unfinished feature of an unreleased
Java version is, especially to a novice.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30794

On 22/01/15 12:46, Joerg Meier wrote:
> I'm not sure why Nigel recommended none of
> the many standard solutions to this problem:


The OP didn't ask how to package everything into a single jar.
They had used a MANIFEST to specify an external jar, so I assumed that's what they wanted to do and explained the 
options available for use of external (library) jars.

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

#30799

On Thu, 22 Jan 2015 14:18:15 +0000, Nigel Wade wrote:

> On 22/01/15 12:46, Joerg Meier wrote:
>> I'm not sure why Nigel recommended none of
>> the many standard solutions to this problem:
> The OP didn't ask how to package everything into a single jar.
> They had used a MANIFEST to specify an external jar, so I assumed that's what they wanted to do and explained the 
> options available for use of external (library) jars.

From the OP, his wish seemed to be obvious, but to be fair, I read his
response before I read the OP, so that may have coloured my glasses. But I
can't imagine what you thought his line:

jar [...] -C ../ShowMemory ShowMemory.jar

was supposed to do, if not include the jar into his jar.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30813

On 22/01/15 15:29, Joerg Meier wrote:
> jar [...] -C ../ShowMemory ShowMemory.jar
>
> was supposed to do, if not include the jar into his jar.

Well, now that you mention it...

I hadn't really taken notice of that bit, and was instead thinking of the classpath.
I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets 
updated it's only need to update a single library jar, rather than every "big jar" which contains that class.

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

#30815

On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:

> I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets 
> updated it's only need to update a single library jar, rather than every "big jar" which contains that class.

Different areas, I'd say. For end users you almost never would want them to
update libraries on their own, unless your end users are developers.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30821

On 23/01/15 12:12, Joerg Meier wrote:
> On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:
>
>> I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets
>> updated it's only need to update a single library jar, rather than every "big jar" which contains that class.
>
> Different areas, I'd say. For end users you almost never would want them to
> update libraries on their own, unless your end users are developers.
>

Why not? End user, or system admin. I'd still not supply a "big bundled jar" unless there was a specific requirement to 
do so.

When you get updates from Microsoft do you get a few small patched libraries, or GB's of statically linked applications 
each time?

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

#30823

On 1/23/2015 10:46 AM, Nigel Wade wrote:
> On 23/01/15 12:12, Joerg Meier wrote:
>> On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:
>>
>>> I'm not a fan of the "big jar" concept. I much prefer to keep
>>> libraries in separate jar's. If a library class gets
>>> updated it's only need to update a single library jar, rather than
>>> every "big jar" which contains that class.
>>
>> Different areas, I'd say. For end users you almost never would want
>> them to
>> update libraries on their own, unless your end users are developers.
>>
>
> Why not? End user, or system admin. I'd still not supply a "big bundled
> jar" unless there was a specific requirement to do so.
>
> When you get updates from Microsoft do you get a few small patched
> libraries, or GB's of statically linked applications each time?

     My plain-vanilla Windows 7 system has ten count them ten
different versions of "Microsoft Visual C++ 20xx Redistributable"
installed.  Why do you suppose Redmond ships so many different
editions of the same library, instead of just updating the latest?

     In other words: If you develop an application using external
libraries A,B,C, you will at some point test it with A 1.2.0-5,
B 2.1.1-18, and C 1.9.12-3.  Will your application still work
properly with updated A 1.2.1-0, B2.1.1-21, and C 2.0.1-1?  To
get around issues of version skew, might you consider bundling
the tested versions of A,B,C along with your application as
opposed to telling the end user to install A,B,C versions in
combinations you've not tried?

     Welcome to the joys of "component architecture" ...

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#30826

On Fri, 23 Jan 2015 15:46:21 +0000, Nigel Wade wrote:

> On 23/01/15 12:12, Joerg Meier wrote:
>> On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:
>>> I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets
>>> updated it's only need to update a single library jar, rather than every "big jar" which contains that class.
>> Different areas, I'd say. For end users you almost never would want them to
>> update libraries on their own, unless your end users are developers.
> Why not? End user, or system admin. I'd still not supply a "big bundled jar" unless there was a specific requirement to 
> do so.

> When you get updates from Microsoft do you get a few small patched libraries, or GB's of statically linked applications 
> each time?

Depends on who provides the libraries. If it's third parties, like is the
case for most Java libraries, then I most certainly get them with each app
that uses them. If it's .NET, like the JRE, I tend to not get them bundled
other than a few exceptional cases.

Nobody guarantees you that newer versions of open source libraries will
behave 100% the same as the one you dev against.

Honestly, short of .NET, DirectX, OpenGL and similar giants, I know of no
library for Windows that isn't delivered along with the app that needs it.
I honestly can't remember the last time an installer said "To run this you
need to manually install library so and so", again, other than above
behemoths.

Do you and me live in different realities or do I misunderstand you ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30827

On 1/23/2015 4:42 PM, Joerg Meier wrote:
> On Fri, 23 Jan 2015 15:46:21 +0000, Nigel Wade wrote:
> 
>> On 23/01/15 12:12, Joerg Meier wrote:
>>> On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:
>>>> I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets
>>>> updated it's only need to update a single library jar, rather than every "big jar" which contains that class.
>>> Different areas, I'd say. For end users you almost never would want them to
>>> update libraries on their own, unless your end users are developers.
>> Why not? End user, or system admin. I'd still not supply a "big bundled jar" unless there was a specific requirement to 
>> do so.
> 
>> When you get updates from Microsoft do you get a few small patched libraries, or GB's of statically linked applications 
>> each time?
> 
> Depends on who provides the libraries. If it's third parties, like is the
> case for most Java libraries, then I most certainly get them with each app
> that uses them. If it's .NET, like the JRE, I tend to not get them bundled
> other than a few exceptional cases.
> 
> Nobody guarantees you that newer versions of open source libraries will
> behave 100% the same as the one you dev against.
> 
> Honestly, short of .NET, DirectX, OpenGL and similar giants, I know of no
> library for Windows that isn't delivered along with the app that needs it.
> I honestly can't remember the last time an installer said "To run this you
> need to manually install library so and so", again, other than above
> behemoths.
> 
> Do you and me live in different realities or do I misunderstand you ?
> 
> Liebe Gruesse,
> 		Joerg
> 

Joerg,

Back in the days before .NET, you often had to load the Visual C++ or
Visual Basic runtime (free downloads from MS) to run applications
created with either one, respectively.

But in general, unless it was something specified by MS or similar, as
you note, Windows applications are generally self-contained.

Unlike on Linux, where you often need to compile code to run on your
system, and almost always need libraries from other products, including
the compiler.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#30834

On Fri, 23 Jan 2015 17:02:17 -0500, Jerry Stuckle wrote:

> Unlike on Linux, where you often need to compile code to run on your
> system, and almost always need libraries from other products, including
> the compiler.

Very good point, I actually forgot about 'the Linux way'.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30835

On Sat, 24 Jan 2015 14:14:23 +0100, Joerg Meier wrote:

> On Fri, 23 Jan 2015 17:02:17 -0500, Jerry Stuckle wrote:
> 
>> Unlike on Linux, where you often need to compile code to run on your
>> system, and almost always need libraries from other products, including
>> the compiler.
> 
> Very good point, I actually forgot about 'the Linux way'.
>
That is often the case for C and C++, where third party libraries are 
traditionally supplied as source tarballs (a hang-over from UNIX).

However, for Java, the situation is probably no different from any other 
OS. All the third party class libraries I've needed so far have been 
released as jar files with the documentation supplied as Javadocs in a 
zipfile. 

However, if you're using 'big jars', you'd still need to update and 
reissue that if the third party classes get updated. I put the main and 
supporting jarfiles into a zipfile so that after its been unpacked the 
jarfiles will be arranged as the main jar's manifest describes.
  

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

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

#30907

On 23/01/15 21:42, Joerg Meier wrote:
> On Fri, 23 Jan 2015 15:46:21 +0000, Nigel Wade wrote:
>
>> On 23/01/15 12:12, Joerg Meier wrote:
>>> On Fri, 23 Jan 2015 11:10:35 +0000, Nigel Wade wrote:
>>>> I'm not a fan of the "big jar" concept. I much prefer to keep libraries in separate jar's. If a library class gets
>>>> updated it's only need to update a single library jar, rather than every "big jar" which contains that class.
>>> Different areas, I'd say. For end users you almost never would want them to
>>> update libraries on their own, unless your end users are developers.
>> Why not? End user, or system admin. I'd still not supply a "big bundled jar" unless there was a specific requirement to
>> do so.
>
>> When you get updates from Microsoft do you get a few small patched libraries, or GB's of statically linked applications
>> each time?
>
> Depends on who provides the libraries. If it's third parties, like is the
> case for most Java libraries, then I most certainly get them with each app
> that uses them.If it's .NET, like the JRE, I tend to not get them bundled
> other than a few exceptional cases.
>
> Nobody guarantees you that newer versions of open source libraries will
> behave 100% the same as the one you dev against.
>
> Honestly, short of .NET, DirectX, OpenGL and similar giants, I know of no
> library for Windows that isn't delivered along with the app that needs it.
> I honestly can't remember the last time an installer said "To run this you
> need to manually install library so and so", again, other than above
> behemoths.
>
> Do you and me live in different realities or do I misunderstand you ?
>
> Liebe Gruesse,
> 		Joerg
>


Well, yes, you clearly do misunderstand me completely.

In your scenario you describe applications as being supplied with libraries. Presumably those libraries can be 
upgraded/patched without it being necessary to re-download the entire application and re-install it?

Also, if different applications share the requirement for the same library you only need to have 1 copy of that library, 
not a different copy for each application?

Maybe Windows is different, and application developers think differently, but on Linux if I install/develop an 
application which, for example, requires access openSSL libraries I wouldn't expect those libraries to be statically 
linked into the application requiring the application to be downloaded and re-installed every time there was a change to 
openSSL. I would expect to be able to upgrade the library via a different route, and the application will get the latest 
update automatically via dynamic linking. The same applies to the "big jar" application. If any of the jar's bundled 
into the "big jar" were updated the application wouldn't benefit from that change until the application developer 
supplied you with an updated application, and you'd have to re-install the entire application all over, rather than just 
the updated library jar.

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

#30930

On Mon, 26 Jan 2015 09:28:14 +0000, Nigel Wade wrote:

>> Do you and me live in different realities or do I misunderstand you ?
> Well, yes, you clearly do misunderstand me completely.

> In your scenario you describe applications as being supplied with libraries. Presumably those libraries can be 
> upgraded/patched without it being necessary to re-download the entire application and re-install it?

Not, not other than, again, those 'big ones' like DirectX. 

> Also, if different applications share the requirement for the same library you only need to have 1 copy of that library, 
> not a different copy for each application?

Same answer as above. The normal approach is to have multiple copies.

> Maybe Windows is different, and application developers think differently, but on Linux if I install/develop an 
> application which, for example, requires access openSSL libraries I wouldn't expect those libraries to be statically 
> linked into the application requiring the application to be downloaded and re-installed every time there was a change to 
> openSSL. I would expect to be able to upgrade the library via a different route, and the application will get the latest 
> update automatically via dynamic linking. The same applies to the "big jar" application. If any of the jar's bundled 
> into the "big jar" were updated the application wouldn't benefit from that change until the application developer 
> supplied you with an updated application, and you'd have to re-install the entire application all over, rather than just 
> the updated library jar.

It turns out we really do live in different realities. I completely forgot
about the strange way Linux handles this, despite administrating a Linux
server. Linux really is the way you describe, and Windows really is the way
I describe (the 'fat jar' approach, where you simply can't update
dependencies). My apologies for being snarky.

For what it's worth, the multitude of available 'fat jar' solutions should
be evidence enough that fat jars are a very common path for releasing Java
applications to end users.

Liebe Gruesse,
		Joerg
		
ps.: Interestingly, I always perceived the Linux way as the inferiour
solution that is only really convenient for relatively low level computer
use by the typical user. As soon as one wants current versions of software,
let alone try a beta version, one runs into a nightmarish world of
dependency hell, snapshot nonsense, package maintainers and their refusal
to cooperate and genrally total dependency on ones distro, whereas on
Windows, I'd just click on "Download exe" and be done with it 30 seconds
later.

At least that was my personal experience. Please don't take it as a slam of
Linux, which I love and much prefer over Windows on the server side of
things. The package managers are leaps and bounds ahead of Windows for 98%
of use cases.

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#30932

On 1/26/2015 3:14 PM, Joerg Meier wrote:
> On Mon, 26 Jan 2015 09:28:14 +0000, Nigel Wade wrote:
> 
>>> Do you and me live in different realities or do I misunderstand you ?
>> Well, yes, you clearly do misunderstand me completely.
> 
>> In your scenario you describe applications as being supplied with libraries. Presumably those libraries can be 
>> upgraded/patched without it being necessary to re-download the entire application and re-install it?
> 
> Not, not other than, again, those 'big ones' like DirectX. 
> 
>> Also, if different applications share the requirement for the same library you only need to have 1 copy of that library, 
>> not a different copy for each application?
> 
> Same answer as above. The normal approach is to have multiple copies.
> 
>> Maybe Windows is different, and application developers think differently, but on Linux if I install/develop an 
>> application which, for example, requires access openSSL libraries I wouldn't expect those libraries to be statically 
>> linked into the application requiring the application to be downloaded and re-installed every time there was a change to 
>> openSSL. I would expect to be able to upgrade the library via a different route, and the application will get the latest 
>> update automatically via dynamic linking. The same applies to the "big jar" application. If any of the jar's bundled 
>> into the "big jar" were updated the application wouldn't benefit from that change until the application developer 
>> supplied you with an updated application, and you'd have to re-install the entire application all over, rather than just 
>> the updated library jar.
> 
> It turns out we really do live in different realities. I completely forgot
> about the strange way Linux handles this, despite administrating a Linux
> server. Linux really is the way you describe, and Windows really is the way
> I describe (the 'fat jar' approach, where you simply can't update
> dependencies). My apologies for being snarky.
> 
> For what it's worth, the multitude of available 'fat jar' solutions should
> be evidence enough that fat jars are a very common path for releasing Java
> applications to end users.
> 
> Liebe Gruesse,
> 		Joerg
> 		
> ps.: Interestingly, I always perceived the Linux way as the inferiour
> solution that is only really convenient for relatively low level computer
> use by the typical user. As soon as one wants current versions of software,
> let alone try a beta version, one runs into a nightmarish world of
> dependency hell, snapshot nonsense, package maintainers and their refusal
> to cooperate and genrally total dependency on ones distro, whereas on
> Windows, I'd just click on "Download exe" and be done with it 30 seconds
> later.
> 
> At least that was my personal experience. Please don't take it as a slam of
> Linux, which I love and much prefer over Windows on the server side of
> things. The package managers are leaps and bounds ahead of Windows for 98%
> of use cases.
> 

Joerg,

You can install software outside of the Linux package managers - I've
done it when I need a version not otherwise available.  What you lose is
the ability to maintain the software via the distro's package system,
bringing you closer to what Windows has.

The problem you could run into is when the software you're trying to
install requires a different version (i.e. newer) than something else
(like the compiler) that is installed on your system.  You can run into
dependency hell then.

Or you can go with something like slackware Linux, which has no real
package system - you're responsible for everything, like on Windows.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#30942

On 26/01/15 20:14, Joerg Meier wrote:
> It turns out we really do live in different realities. I completely forgot
> about the strange way Linux handles this,

Strange? You consider good package/library/dependency management to be "strange"?
Maybe it is strange to someone who lives in the Windows world.

> despite administrating a Linux
> server. Linux really is the way you describe, and Windows really is the way
> I describe (the 'fat jar' approach, where you simply can't update
> dependencies). My apologies for being snarky.

That's not what I mean by "fat jar".

Supplying an application with necessary supporting libraries is perfectly reasonable under most circumstances.
A good installer might also check whether those dependencies could already be met on the system without having to 
install them again, but that's another issue.  The fundamental point is the separation of the application and the 
libraries. You could, by judicious administration, update just libraries which you wished to upgrade without having to 
rely on the support of the application developer.

By "fat jar" I mean the idea of supplying everything in a single monolithic application, with all the libraries built 
into it, i.e. in Java terms having all supporting library jars unpacked and re-packaged into the main application jar. 
In this scenario it's next to impossible to upgrade a supporting library in the event that you discover it has some 
major problem without the support of the application developer.

 > For what it's worth, the multitude of available 'fat jar' solutions should
 > be evidence enough that fat jars are a very common path for releasing Java
 > applications to end users.

Which ones? I can't think of any which I have installed.

 > ps.: Interestingly, I always perceived the Linux way as the inferiour
 > solution that is only really convenient for relatively low level computer
 > use by the typical user.


 > As soon as one wants current versions of software,
 > let alone try a beta version, one runs into a nightmarish world of
 > dependency hell, snapshot nonsense, package maintainers and their refusal
 > to cooperate and genrally total dependency on ones distro, whereas on
 > Windows, I'd just click on "Download exe" and be done with it 30 seconds
 > later.

I have exactly the opposite opinion as you with regard to convenience and management.

It's the Windows style of application installation which I think is typical of low level computer expertise, both from 
the developer and the end user. It has been deliberately designed to make it simpler for the general user to install 
software without any understanding or care as to the implications of what that software may do to their system. It 
creates an incoherent mishmash of packages and libraries which the user doesn't understand and can't hope to maintain 
with any level of expectation of good reliability or security. The concept of "just clicking on "Download exe" and be 
done with it 30 seconds later" is exactly why so many Windows computers are "owned".

Installing a current version, or beta, on Linux requires a basic level of expertise necessary to separate the main 
system from the development environment. However, it's that expertise, and separation, which keeps the overall system 
safe from bad/insecure software/malware which blights Windows. And if you want real separation it only takes a few 
minutes to install a new Linux VM from scratch, or just run a VM from a live CD. As compared to the several hours it 
takes to install/upgrade/re-boot/upgrade/re-boot/upgrade/re-boot a new Windows VM.

Horses for courses. If you prefer to be able to just click, download and install any old garbage from the Internet 
that's fine. It's your computer. I'm just glad it's not mine.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web