Skip to main content

Why 2 != jdic.jar depending on OS used?

18 replies [Last post]
jhujol
Offline
Joined: 2006-02-17
Points: 0

Hi,
I noticed that the size of the jdic.jar's changes slightly from the Windows version (58,153 bytes) and the Linux one (55,145 bytes). I thought Java was OS agnostic (at least for the class byte code!)

Could you enlight my misunderstandings or maybe some stuff belong to another package than the JDIC API itself. Probably they should be named jdic-win-adapter.jar and jdic-lin-adapter.jar respectively. The jdic.jar would then be the real common JDIC API shared by all implementation.

Best,
Johnny

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chas
Offline
Joined: 2004-06-23
Points: 0

I think the best approach is a somewhat of a merge.

Have all platform specific classes have unique names and have factories for instantiating any platform specific classes.

Have the standard packaging place shared classes in jdic.jar, platform specific classes in jdic-platform.jar, and add a jdic.jar manifest entry "Class-Path: jdic-platform.jar"

For those who wish to repackage the jars, they may unjar all standard jars and rejar with their own classes.

For those using jdic with a standard jre, create an installer which would copy jdic.jar and the correct jdic-platform.jar into the jre/lib/ext directory.

For those using jdic with webstart, the proper jdic-platform.jar can be specified in a jdic.jnlp file -- something like:



JDIC Installer
JDesktop Project of JavaDesktop
















troggan
Offline
Joined: 2003-06-21
Points: 0

Java is not platfrom specific, why should the user download a platform-specific version of my Application (TV-Browser)? Only for the Tray ? I really don't like that...I will put the changes into the cvs of my App.

And I don't think the Tray-Lib will increase much in the Future...(ok, 300 kb maybee, but not 50mb ;) ).

If someone is interested in my Changes, mail me!

troggan
Offline
Joined: 2003-06-21
Points: 0

Now we have 2 Users that did this...I think there are more out there...could you put this into the CVS, please ?

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi,

As all the JDIC code uses the same factory pattern to return the implementation instance for a specific OS, it's doable to include the .class files for all the platforms into one command but bigger .jar file. Then it's the same .jar file for all the platforms.

The problem for that, as pointed out by Chas, is every platform needs to download all the other class files. At the moment, it's not a big problem, as it's just tens of KB difference, but it will definitely grow bigger. Like JDK, it's now nearly 50MB !!!, which requires much time to download and much disk space. And bigger size jar files are expecially a problem with WebStart applications. I already met some big WebStart apps, which are unbearable to download and check for updates every time running it.:-(

So, initially we followed the way JDK doing that(at lease t Java WebStart: jre/lib/javaws.jar) to include only the command API and classes for one platform into one jar file for that platform, instead of including all the classes into one jar.

On the other hand, most importantly, I still can't see what's the gain to use one common jar file for all platforms. I responded to Johnny on his problem, which is not a problem with the current approach.

So I still intend to keep the current code...

Anyway, I enjoy such kind of discussions. :-)

Thanks,
-George.

John Ellis

I wouldn't blame you for keeping the code as-is, given your architecture goals.

The main reason I performed the merge for the System Tray
implementation was because I was going to pre-package the .jar with
the installer used for my application. If I had users find and install
their own specific implementation, they wouldn't bother installing the
app. Likewise it's a turnoff (and a release maintenance headache) to
release different installers for different OS'. A strong argument for
Java is to have an app that can be archived in a single .zip, sent out
to any platform and have it natively executed.

Of course, there's also the problem of JNI needing native libraries. I
mainly got around that by including each native library in my
distribution - then JNI will simply call the appropriate one depending
on platform. Using the combination of these two techniques I have a
single installer for Windows, KDE and Gnome.

If JDIC becomes a more standardized distribution (or even part of the
JRE installer) this will cease to be a problem, since the JRE download
is OS-specific. Until then, I'm going to keep merging into a single
.jar to keep my installer releases simple.

On Thu, 30 Sep 2004 06:04:26 EDT, jdic@javadesktop.org
wrote:
> Hi,
>
> As all the JDIC code uses the same factor pattern to return the implementation instance for a specific OS, it's doable to include the .class files for all the platforms into one command but bigger .jar file. Then it's the same .jar file for all the platforms.
>
> The problem for that, as pointed out by Chas, every platform needs to download all the other class files. At the moment, it's not a big problem, as it's just tens of KB, but it will definitely grow bigger. Like JDK, it's now nearly 50MB !!!, which requires more time to download and much disk space. And bigger size jar files are expecially a problem with WebStart applications. I already saw some big WebStart apps, which are unbearable to download and check for updates every time running it.:-(
>
> So, currently, we followed the way JDS doing that(at lease t Java WebStart: jre/lib/javaws.jar) to include only the command API and classes for one platform into one jar file for that platform, instead of including all the classes into one jar.
>
> On the other hand, most important, I still can't see what's the gain to use one common jar file for all platforms. I responded to Johnny on his problem, which is not a problem with the current approach.
>
> So I still intend to keep the current code...
>
> Anyway, I enjoy such kind of discussions. :-)
>
> Thanks,
> -George.
> ---
> [Message sent by forum member 'georgez' (George Zhang)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=31029&#31029
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
> For additional commands, e-mail: jdic-help@jdic.dev.java.net
>
>

--
John Ellis
john.ellis@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
For additional commands, e-mail: jdic-help@jdic.dev.java.net

georgez
Offline
Joined: 2003-08-19
Points: 0

I quite understand that.

I'll talk about it with some other contributors...

Thanks,

-George.

troggan
Offline
Joined: 2003-06-21
Points: 0

Done...was 5 min of work :)

I have renamed the ServiceManagerStub into GnomeServiceManagerStub and WinServiceManagerStub and then I changed the return ServiceManagerStub.getService(serviceName); line in ServiceManager into

if (os.indexOf("linux") > -1) {
return GnomeServiceManagerStub.getService(serviceName);
} else if (os.indexOf("windows") > -1) {
return WinServiceManagerStub.getService(serviceName);
}

Now I have 1 Jar for both Platforms. Including both "Flavours" into 1 Jar makes it 10-15 kb bigger. That's not worth talking about it...it downloads in no-time ;)

If you don't put that changes back into your cvs I will put them into the cvs of www.tvbrowser.org!

Bodo

John Ellis

I did the same for system tray, with similar results.

On Wed, 29 Sep 2004 01:34:01 EDT, jdic@javadesktop.org
wrote:
> Done...was 5 min of work :)
>
> I have renamed the ServiceManagerStub into GnomeServiceManagerStub and WinServiceManagerStub and then I changed the return ServiceManagerStub.getService(serviceName); line in ServiceManager into
>
> if (os.indexOf("linux") > -1) {
> return GnomeServiceManagerStub.getService(serviceName);
> } else if (os.indexOf("windows") > -1) {
> return WinServiceManagerStub.getService(serviceName);
> }
>
> Now I have 1 Jar for both Platforms. Including both "Flavours" into 1 Jar makes it 10-15 kb bigger. That's not worth talking about it...it downloads in no-time ;)
>
> If you don't put that changes back into your cvs I will put them into the cvs of www.tvbrowser.org!
>
> Bodo
> ---
> [Message sent by forum member 'troggan' (troggan)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=30799&#30799
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
> For additional commands, e-mail: jdic-help@jdic.dev.java.net
>
>

--
John Ellis
john.ellis@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jdic-unsubscribe@jdic.dev.java.net
For additional commands, e-mail: jdic-help@jdic.dev.java.net

troggan
Offline
Joined: 2003-06-21
Points: 0

I dont want to have a second Parameter...I want only 1 Jar. That reduces the possibility of an error. The overhead is minimal.

If noone is interested in doing this, I will create it for my Project...

Message was edited by: troggan

troggan
Offline
Joined: 2003-06-21
Points: 0

Why can't you do a "if OS = Windows then use this class"-Factory?

With that you could put everything in one Jar-File.

My Problem is that I bundle everything into 1 Jar-File. With that the User is able to enter "java -jar tvbrowser.jar". If I use your libs I have to create 2 different tvbrowser.jar-Files for my application. I want to reduce the possibility of errors.

Bodo

chas
Offline
Joined: 2004-06-23
Points: 0

Adding the dependent jars to the Class-Path attribute does not prevent you from using the -jar command line. You would add Class-Path=jdic.jar in your tvbrowser manifest. The Class-Path inside jdic.jar (or any other dependent jar) is automatically merged into the system classpath by the system classloader.

The problem I have with every platform in a single jar is when my app is a webstart app, I don't want to download every platforms' classes.

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Johnny,

You are right, the jdic.jar file does differ between Windows/Linux/Solaris.

There is another thread talking about this problem:
http://www.javadesktop.org/forums/thread.jspa?threadID=2753&tstart=100

But what's the gain to use a common jdic.jar for all platforms, and a jdic-win-adapter.jar and jdic-lin-adapter.jar respectively? I feel that one or two .jar files do not matter much to the end users, since they just need to add the patch to CLASSPATH.

Any more comments ?

Thanks,
-George.

jhujol
Offline
Joined: 2006-02-17
Points: 0

Hi George,
I did not bother to find another thread, sorry for that!

I'm designing a little framework at work to provide a Java web browser in a OS agnostic world. Also the app are Java Web Started. The code is then compile on a different architecture (windows, Linux or Solaris). That's why I was wondering about this. Of course I could compile 3 times my app for each system using 3 != jdic.jar, but this is not the way to do it because I'm relying only on jdic and Java is OS agnostic (I definitely like this word ;). I want to keep it that way.

So now, the gain would be to be able to compile on any platform and then to link the os dependent implementation on runtime (like for db drivers).
I haven't tried to compile with the windows jdic.jar and then run the app using the linux jdic.jar. It would probably work to a certain point.

I haven't look enough at the source, but it seems that at some point depending on the os there could be a jdic-lin-web-driver.jar or jdic-win-web-driver.jar which fills the gap between abstraction with Java and the dependencies with the os like db drivers.

That was my thoughts on this. I hope I make it a little bit more clear. Thanks for taking the time to answer my consideration George.

I will follow the thread 2753 on that, I'm curious!

Johnny

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Johnny,

Thanks for stating a real user case of JDIC. : )

To make sure I caught your points, below are my comments.
You see, each JDIC release for a specific OS has an OS dependent jdic.jar and native libraries (jdic.dll/libjdic.so). The jdic.jar contains all the public(exposed), common JDIC API shared by all OS, and an OS dependent implementation.

If you want to build your java code using the public JDIC API, you just need to build it with any of the OS dependent jdic.jar file. For example, the bundled Browser demo built with jdic.jar for Linux OS just simply runs with jdic.jar for Windows OS on Windows.

So, you don't need to "compile 3 times my app for each system using 3 != jdic.jar". Did I catch your case? : )

Thanks,
-George.

jhujol
Offline
Joined: 2006-02-17
Points: 0

George, you're right on it ;)

As I wrote previously:
"(...) I haven't tried to compile with the windows jdic.jar and then run the app using the linux jdic.jar. (...)"

And your point is:
"(...) For example, the bundled Browser demo built with jdic.jar for Linux OS just simply runs with jdic.jar for Windows OS on Windows. (...)"

That's exactly what I wanted to hear. Thanks!
But that brings up another consideration here!

So now it seems to me that if I can compile my app with any of the jdic.jar and run the app with any of the jdic.jar, doesn't it imply that the OS dependant implementations are also common to any OSes and so one jdic.jar musts be enough instead of at leasst 2 != ones?

I don't want to bother you but this is getting interesting!

Johnny

georgez
Offline
Joined: 2003-08-19
Points: 0

Hi Johnny:

> So now it seems to me that if I can compile my app with
> any of the jdic.jar and run the app with any of the
jdic.jar,

I said you can just compile one app with any of the jdic.jar, since they use the public, common APIs. But you CAN'T run the app with any of the jdic.jar on one specific OS. Say, on Windows, you can run it only with the jdic.jar for Windows.

>I don't want to bother you but this is getting interesting!

No problem : )

-George.

jhujol
Offline
Joined: 2006-02-17
Points: 0

Hi George,

this is a bit confusing, but I see clearer.
I still think that for the sake of it, having a jdic.jar for the common api and some jdic-.jar would be better, anyways ...

Thank you for the clarification and your time on this.
Have a good w-e et a bientot!

J

chas
Offline
Joined: 2004-06-23
Points: 0

I suggest that there should be jdic.jar and jdic-platform.jar.

The jdic.jar is almost pure interface. The jdic-platform.jar contains all platform specific code.

To prevent needing two jars on the classpath, the jdic.jar has a Class-Path entry in its manifest specifying jdic-platform.jar