Skip to main content

A few ideas off the top of my head

10 replies [Last post]
osbald
Offline
Joined: 2003-06-13

Can we have a getSize() method on Collection. Its a long running gripe, especially when using EL only to find the size property isn't available because Collection wasn't made fully compatible with the JavaBean spec.

Like many I see the VM sharing could have its uses, but we'd need a way to control the startup of these shared spaces too.. via an enhanced JNLP spec? A key part of this would be the need for Isolates which in would seem to suggest a re-engineering of the classloader mechanism which is long past its sell-by date. Isolates and Classloaders are at the top of my list here.

I'd like to see another extension installed into Windows to allow for executable Jars (.jre)? Currently I can't tell wether a jar is executable or not - except by double-clicking. Also many users seem to have jar associated with winzip, powerarchiver or whatever. I'd like a spereate icon & mime type to distinguish these.

A decent Java based browser/html viewer for Swing would be very handy; not easy I know and JDIC has been making progress allowing me to embed the native browser. But trying to embed a heavyweight peer into a lightweight Swing application isn't very practical. SWT has a very definite edge here (being heavyweight by nature).

I've also had a few OS integration issues I've yet to find answers for. One is when invoking a desktop app (via web start) I can't ask for a max-heap of say 30% of the max memory the client has installed. I can only find out memory figures AFTER the app has started and can't change the min/max figures from here (without launching another JVM). Actually I'd really like to say 30% of what the client has installed or an minimum of 128mb -- whichever is larger.

Also can the executable jars also have some of these extra runtime parameters in the manifest.. at the moment its not possible to start a runnable jar with anything but the default 64mb (without going via the command line which kinda defeats the point).

A similar issue is with process/cpu usage (thinking Windows here). Currently I can't reduce the task priority assigned to my Java apps under Windows.. often I'll see my Java IDE to even a simple Swing App rendering a webpage shoot the CPU usage to 100% rendering the clients desktop unusable leading to the old stereotypical Java-app empty grey box effect. I can only change these priorities via the Windows taskmanager setting the Java process to below normal or low. What I may be asking for here is a means to control/throttle thread usage? how do I stop being such a cpu hog and play nice.

I also dislike the way personal firewalls (like the builtin Windows XP SP2 one etc..) treat all Java applications as the same program. It's a bit of a concern that when a XP user installs the JRE they'll get a popup saying some unauthorized program is trying to access the Internet (Java update).. if they click NO at this prompt (and the dialogs pretty much tell them to) they'll disable all of the runtimes networking ability for all Java programs. Dislike the fact I cant distinguish between trusted Java apps and some ropey spyware Applet, its all or nothing (and I'll have to set this again next time the jvm is upgraded). Not sure what can be done here, its just a pain.

- Richard

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vhi
Offline
Joined: 2004-10-11

What I meant was that moving from one JDK to another is always costly. I do not think that a few method name changes will affect the already inherent cost. I do not think that anyone who has migrated from JDK 1.3 to JDK 1.4 with significant codebase would say that it was free. For example, right now, I am migrating a Web Application from Java 1.3 to Java 5. Java 5.0 includes some org.w3c.* packages that are of higher versions than mine. Either I upgrade my application to adopt the new libraries, or I fiddle with classpaths, which may result in unpredictable surprises (this is why library versioning and splitting of "rt.jar" is so important in Java). The point is, in the end, I would simply upgrade my application to work with Java. While I am upgrading, I do not mind to change a few more classes if the end result is a better and maintainable program.

osbald
Offline
Joined: 2003-06-13

How far would simply adding a protected getSize() method to AbstractList etc.. get us?

osbald
Offline
Joined: 2003-06-13

>Right now, even an executable jar itself is worthless
>without a lot of work when it depends on other libraries.
>They either have to be in the user's lib/ext folder, the
>user must specify (usually through some lousy batch file),
>or in the clever cases, the JAR includes a special
>bootstrap classloader that then looks for the rest of the
>classes.

Actually that isn't is quite true, you can already specify a class path in the manifest of the jar itself, I've been using this successfully for years..
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest
Where its lacking functionality is the ability to pass JVM parameters like max heap & permsize etc.. Although whether these manifest details are migrated into a APP-INF like structure I honestly don't care. I suppose if this gets supported you could also do things like having your own application icon for the jar in a resources dir etc.. Talk about duplicating some of the JNLP properties also reminds me it might be nice to influence some of the new java.exe options like jre-restrict-search ref: http://blogs.sun.com/roller/resources/watt/jvm-options-list.html

This discussion also vaguely reminds me of the codehaus uberjar project.

- Richard

monika_krug
Offline
Joined: 2004-10-14

> Can we have a getSize() method on Collection. Its a
> long running gripe, especially when using EL only to
> find the size property isn't available because
> Collection wasn't made fully compatible with the
> JavaBean spec.

Would be nice, but is not possible: If Sun changed the Collection interface, all existing implementations would be broken, because they don't implement the method.

Monika.

tsinger
Offline
Joined: 2003-06-10

... which raises the question of compatibility. Every decent project attempts to get rid of inherited waste (you also can call it "errors of the past").

Why not make a cut? Java X will not be source compatible any more to Java 1.5 (to be honest, 1.4 was not 100% compatible to 1.3, 1.5 is not 100% compatible to 1.4): Some methods were cleaned up (e.g. collection.size() -> collection.getSize()), deprecated stuff and obsolete classes (like Vector or Enumeration) where removed.

I'm sure, if SUN will not find a way to drop the inherited waste, Java will collapse on it in some years.

Tom

vhi
Offline
Joined: 2004-10-11

It is interesting that Sun insists on source compatibility, but it is ineffective most of the time. For example, in my company there is a project that was made in JDk 1.2. It was ported to JDK 1.3 without any modifications. It was source compatible, mainly because many bugs for which the company had implemented work-arounds where not fixed, and the overall Swing architecture was same. But, now, they cannot port it to JDK 1.4 at all. There are huge problems because of bug-fixes done in 1.4, and the Swing cleanup. Now, since they have to do some work to port it to 1.4, I do not think that they would mind working a bit more to correct cases where Eclipse IDE would easily help, that is, removing deprecated methods, renaming methods etc. I do not believe that there is much portability issues in renaming methods, removing methods etc. It would be painful when there are substantial changes in the way the code works (e.g. in case of old event handling vs. new event handling). But I think some of the changes are worthwhile.

monika_krug
Offline
Joined: 2004-10-14

If Sun did not insist on compatibility, likely many companies would not upgrade to the next JDK because there would be so much cost involved.

Monika.

tsinger
Offline
Joined: 2003-06-10

Of course, there are companies, where refactoring is not understood as essentially necessary - only features count and can be sold.

Tom

trinition
Offline
Joined: 2003-07-29

> I'd like to see another extension installed into
> Windows to allow for executable Jars (.jre)?
> Currently I can't tell wether a jar is executable or
> not - except by double-clicking. Also many users seem
> to have jar associated with winzip, powerarchiver or
> whatever. I'd like a spereate icon & mime type to
> distinguish these.

I've personally got my JARs associated with both WinZip and javaw.exe. But, like you said, there is nothing to indicate to a user that a jar is executable until they try it.

But rather than the small step you propose, I propose something bigger. We have WARs (web application archives), EARs (enterprise application archives) and RARs (resource adapter archives) and JARs (java archives). THe former all depend on the last, JAR, as internal archives of code. What's missing is a standalone applicaiton archive (SAR? AAR? JRE?)

I propose a new archive with a distinct extension. This would indicate executabilityt o the user right away. Furthermore, I propose this new archive format would have some sort of an APP-INF directory in it (similar to WEB-INF in WARs or the APP-INF supported in EARs by WebLogic). This directory would contain information similar to what is in a JNLP file, as well as a lib folder (similar to WEB-INF/lib) that includes libraries that would implicitly be available on the classpath.

Right now, even an executable jar itself is worthless without a lot of work when it depends on other libraries. They either have to be in the user's lib/ext folder, the user must specify (usually through some lousy batch file), or in the clever cases, the JAR includes a special bootstrap classloader that then looks for the rest of the classes.

Those are all pitiful solutions. Obviously someone was recognizing that applications are made of many JARs, classes, resources, etc. when they made the WAR and EAR specs. I think this shoudl be brought back around to plain old Java applications in a new archive format that leverages those same ideas.

afreije
Offline
Joined: 2004-10-14

Second!

I would prefer AAR, Application Archive.
The APP-INF directory could contain an [url http://ant.apache.org/]Ant[/url] xml file to allow for multiple execution targets.