Skip to main content

Which JSRs do you think should be proposed?

27 replies [Last post]
mister__m
Offline
Joined: 2003-06-14
Points: 0

Which areas need a (better) spec? I personally think a better date/time system and a XUL/simpler GUI model would be nice things to have.

What do you think?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
johnlon
Offline
Joined: 2006-05-21
Points: 0

Re "Without WORA Java looses 90% of its appeal for realworld use"

I'm not sure which real world you inhabit - certainly not the same one as me.

My organisation has the order of 50000 JVMs running.
Only a tiny proportion of these run on a non-Unix platform and the developers of these apps are explicitly targeting Win2X servers and have their own set of problems due to the inability to access local OS features.

If you are a software vendor then I expect you would be keen to have a platform independence.

However, if you are an organisation writing enterprise software targeted at your enterprise-wide strategic OS then platform independance question is irrelevant.

There are lots of reasons why my organisation uses Java but OS independance is certainly not one of them.

(By the way another example of a particularl stupidity in Java is its lack of any standard way to get your JVM's process id - I've seen Java code actually forking a perl subprogram just so perl can echo pack the parent process id - this is an embarassment).

encinarus
Offline
Joined: 2005-06-08
Points: 0

> Try new File("C:\\temp\\file") on Unix.

Bad example. You shouldn't be doing that even on windows. Try File.createTempFile("prefix", "suffix") or File.createTempFile("prefix", "suffix", new File("somedir")). If you really need to reference a specific path and run on multiple platforms then put the path in a properties file and pass it in to your program at runtime.

nuggetboy
Offline
Joined: 2008-11-14
Points: 0

SQL

mthornton
Offline
Joined: 2003-06-10
Points: 0

Have you looked at the early draft JSR-203 proposal? This includes some support for symbolic links. It also provides support for several features that won't be available everywhere, in particular Access Control Lists and Posix file attributes.

If you don't like the proposal, plase comment NOW and not leave it until too late like so many who dislike generics have done.

P.S. I am not part of the JSR-203 working group, just an interested outsider.

martinstraus
Offline
Joined: 2003-08-22
Points: 0

> The Java folks (Sun) have to get over WORA. It is a
> chimaera in it's current dogmatic form. Real
> software runs on real hardware running real operating
> systems. This brings me to my second request for a
> JSR.
>
> In order to work cleanly with necessary platform
> specific libraries Java needs a simple preprocessor
> (#ifdef/#ifndef would suffice) in order to make a
> workable WORA model.

If you are a C/C++ developer migrating to Java, I understand you, but I don't agree with you. If you are aren't, then you're a bad Java developer. If you feel the [i]need[/i], the [i]desire[/i] of using preprocessor instructios, Java is not the tool for you.
A tool should help you; if Java doesn't help, then go with something else. But don't try to convince the rest of us that preprocessor instructions are a good thing. I think they are not.
Using Java and subscribing to some design principles is not dogmatic; if you need to do something that is in conflict with those principles, you need to pick a different tool.
You don't need to use preprocessor instructions to achieve what you wan't to do, anyway. The plain old if {} block is your friend if you like quick and dirty solutions.

greggwon
Offline
Joined: 2003-06-14
Points: 0

> When trying to write system level software WORA just
> doesn't work. Trying to build a file access control
> interface that encompasses both the Windows ACLs
> model with unix user/group/permissions model is
> essentially impossible. The models for the two
> platforms are incommensurable. And file access
> control is just the tip of the iceberg. Unix, for
> instance has a setuid call, critical to many
> enterprise applications. Windows has a similar but
> more restricted ability to impersonate a different
> user. Unix setuid or seteuid is per process.
> Windows impersonation is per thread. The models are
> e once again incommensurable.

Your assuming that this check still belongs in the OS. Is it in fact necessary for this check to be in the OS? I am not sure that it is. If Java had more complete support for user based principals, I think that all OSes could support this as long as the process ran at administrative levels. The issue is that you wouldn't want everyone reimplementing a security model each time. So, there would need to be a mechanism in the JVM to authenticate using PAM or something that would validate you against the OSes known credentials.

I've created my own solution for linux using a JNI based login module that accesses PAM. A lot of people have done this too.

The new wave is X.5XX or Kerberos based authentication. This works okay in highly stable networks with global access to CAs. But it doesn't work so well in small, isolated networks where a CA is not present and certs don't have as good of a validation chain.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

No!
This just breaks WORA and we'll give up on cross-platform programming.

I agree that we need access to platform-specific features but it MUST be done in a cross-platform way. No specific packages, just cross-platform components that provide plafform-specific functions. Function may or may not be available and this has to be handled in programs.

But instead of

if (windows) doThis(); else if (unix) doThat();

...we need crossplatform approach:

Feature feature;
if (featureAvailable) feature = Runtime.getFeature();
else feature = new FeatureEmulator();
feature.doThis();

brittpark
Offline
Joined: 2004-10-09
Points: 0

When trying to write system level software WORA just doesn't work. Trying to build a file access control interface that encompasses both the Windows ACLs model with unix user/group/permissions model is essentially impossible. The models for the two platforms are incommensurable. And file access control is just the tip of the iceberg. Unix, for instance has a setuid call, critical to many enterprise applications. Windows has a similar but more restricted ability to impersonate a different user. Unix setuid or seteuid is per process. Windows impersonation is per thread. The models are once again incommensurable.

The Java folks (Sun) have to get over WORA. It is a chimaera in it's current dogmatic form. Real software runs on real hardware running real operating systems. This brings me to my second request for a JSR.

In order to work cleanly with necessary platform specific libraries Java needs a simple preprocessor (#ifdef/#ifndef would suffice) in order to make a workable WORA model.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

System level software IMHO should not be written in Java. Java is about WORA, it's about being cross-platform. We have to hang on this as hard as we can otherwise we deny Java's main idea.

So, I have to insist, Java application should not care about platform or OS. It should care about application problem.
If you need to go deeper, closer to the system, try to build abstraction on top of the feature you use.
Platform specific stuff that cannot be done in Java belong to native libraries encapsulated by Java API that decouples JVM and system as much as possible.

We do not need #ifdef & co. at all. You can achieve the same thing using constants.

Message was edited by: patrikbeno

lorban
Offline
Joined: 2004-10-06
Points: 0

The JTA specification (JSR 907) is horrible. It is extremely vague, confusing, implicitly requires deep understanding of the XA C language specification and is not well adapted to the Java language.

The recent 1.1 version helps in no way.

Message was edited by: lorban

aleixmr
Offline
Joined: 2006-03-13
Points: 0

I think it would be useful an Interface to access easily to all low level devices, such as a scanner, a camera, printer, USB, etc.

I write a TWAIN wrapper scanner driver and its really a pain !!. I' don¡t know how this issue should be solved, but I think of a way as mentioned a post above:

import java.awt.scanner.*;

or more generic:

import java.awt.os.DeviceFactory;

I love swing a lot, I've done my own library on top of it and its really really productive. The only thing I miss is when i have to acces to low level os layer, 'features' etc.

We need a generic interface to access to ALL underlaying os features, avoiding JNI or doing it a lot simpler and less buggy.

johnlon
Offline
Joined: 2006-05-21
Points: 0

I am truely gobsmacked by the suggestion that WORA should take precedence over offering common features required by real systems (write once run on a single OS family).

I think its at least 10 years since support for sym links was requested.

Pretty damning.

Message was edited by: johnlon

twe
Offline
Joined: 2005-05-11
Points: 0

> I am truely gobsmacked by the suggestion that WORA
> should take precedence over offering common features
> required by real systems (write once run on a single
> OS family).
> I think its at least 10 years since support for sym
> links was requested.

Did you notice that you got the same "reasons" GUI developers got for a long time when it came to support for accessing the system tray? That feature indeed took ten years.

I think symlinks can be done in a few month when taking a practical approach. And I don't buy the "but it has to be perfect" line. Non of the Java APIs is really perfect (printing anyone? Or desktop integration?), and some language features are extremely ugly, incomplete and half-baken hacks (generics anyone?). So not being able to do it perfect is not an excuse for not doing it at all.

For symlinks at least two features need to be modeled

1) File-system supported symlinks (like the ones on Unix)
2) Userland-interpreted "symlinks" (like the shortcuts on Windows or desktop shortcuts on GNOME)

(I i think recent Windows file systems can also have the equivalent of symlinks, but I am not sure if that particular "OS" on top of it makes use of them at all).

To round it off maybe a third feature needs to be modeled

3) Hard-links ala Unix

So three classes, plus probably a common superclass, abstracting the very few features different link types have in common (like they all have a name and point to a second name, they can be created and removed, etc.).

abstract class FileLink {
void setName(File n);
File getName();
void setDestination(File n);
File getDestination();
boolean exists(); // a file with the name exists, but not is necessary a link
boolean isLink(); // name is a link, but not necessarily pointing to destination
boolean isLinked(); // name is a link and even points to destination
void link() throws someSubclassOf_IOException;
// create link if no file or link with that name exists
// no-op and no exception if link with name pointing to destination exists
void forcelink() throws someSubclassOf_IOException;
// overwrite any previously existing link or file
void unlink() throws someSubclassOf_IOException;
// remove link if name and destination of link match the data in this object
void forceunlink() throws someSubclassOf_IOException;
// remove link or file independent of type or link contents
}

class SoftLink extends FileLink{ void SoftLink(File name, File destination) ... }
class HardLink extends FileLink{ void HardLink(File name, File destination) ... }
class Shortcut /* or SuperSoftLink */ extends FileLink /* or SoftLink */ {
void Shortcut(File name, File destination) ...
// lots more attributes, like description, icon(s), icon references,
// start directories, command line arguments, etc.
// just the union of all attributes which can be found on all common
// platforms
}

Probably also a factory (class or method) from which one can request link objects with particular minimum features. In case a platform doesn't have a link type supporting the requested features one gets a null or an exception. Yes, such failures than have to be handled, but what else can one do?

To round it off one can now think of additional features, like the ability to have a special notation of some kind to identify the desktop and place desktop shortcuts onto it. And to finally enhance the File class so that all kinds of file attributes can be set and get.

class SpecialPlace {
File toFile(); // return as file object if platform supports addressing the place as a file
void addLink(FileLink l); // add shortcut to special place
void removeLink(FileLink l);
Icon getIcon();
String getIdentifier(); // internal name, unified among platforms by convention
// e.g. all first CD drives on all platforms are called "CD0"
String getName(); // Localized name of the place the user is used to on the
// particular platform. E.g. "D:" for the CD drive, or
// "My Documents", "Desktop" for other common special places.
}

class SpecialPlaces {
static SpecalPlace getDesktop();
static SpecialPlace getUserHome();
static SpecialPlace getUserDocuments();
static SpecialPlace getSharedDocuments();
...
static Tree getHierarchy(); // all known special places and their hierarchy
}

Yes, I think it can be done in less then ten years, in a way that would allow to use the features on the platforms where it is supported. And without too much pain on platforms where there is no such thing as a hardlink, softlink, or shortcut. I can even imagine that it would be possible to at least artificially support shortcuts on every platform by mimicking the Windows way of doing shortcuts (they are just files in Windows). Maybe even by just reusing Window's .lnk file format.

The API won't be perfect, but it wouldn't be worse that the other Java APIs which try to abstract, bridge or hide platform specific features or even individual machine specific features.

i30817
Offline
Joined: 2006-05-02
Points: 0

I'm really rather annoyed by the people saying to ditch WORA. Go program in python if you want that. I'd rather my programs are garanted to work everywhere there is a jre implementation. In fact i'd rather that the testcases of the avaible features were refined to detect the "problems" you talk about, and that horrible api were replaced. If at first you don't succeed...

twe
Offline
Joined: 2005-05-11
Points: 0

> I'm really rather annoyed by the people saying to
> ditch WORA. Go program in python if you want that.

I don't want to waste much time discussing with fundamentalists. So just one note.

> I'd rather my programs are garanted to work
> everywhere there is a jre implementation.

As if it ever was. It was always the case right from the beginning that it was the responsibility of the programmer to not introduce platform dependencies. Try new File("C:\\temp\\file") on Unix. The whole 100% Pure Java marketing campaign was about to convince programmers not to introduce platform dependencies. And that campaign failed. Even Sun's own software often couldn't adhere to it. The reason for this is simple. When having to chose between an application not working well on any platform, or an application working well on one platform, a programmer usually has to choose the "working well on one platform" path. Because otherwise the customer walks away.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > I'm really rather annoyed by the people saying to
> > ditch WORA. Go program in python if you want that.
>
> I don't want to waste much time discussing with
> fundamentalists. So just one note.
>
So, anyone who doesn't agree with your views is a heretic who should be put to the sword?

Without WORA Java looses 90% of its appeal for realworld use. Without WORA Java is indeed (as its opponents have claimed for over a decade) effectively dead.

> > I'd rather my programs are garanted to work
> > everywhere there is a jre implementation.
>
> As if it ever was. It was always the case right from
> the beginning that it was the responsibility of the
> programmer to not introduce platform dependencies.

But at least he could prevent them.
If WORA is dropped you no longer can.

> 100% Pure Java marketing campaign was about to
> convince programmers not to introduce platform
> dependencies. And that campaign failed. Even Sun's

It worked fine. The majority of Java software works fine across platforms.
If it doesn't it's usually because of a flawed JVM implementation for that platform rather than anything else and in the rest of the cases it's someone breaking WORA either deliberately (laziness, mostly) or accidentally (lack of understanding, not knowing about different line terminators on different platforms is a classic one).
Can't blame the language for that...

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I tend to agree. If you really need some OS-specific feature such as symlinks it is up to you to propose what should happen on platforms that do not explicit support it. If you cannot come up with some portable equivilent then I think you'd be hard-pressed to convince me or others that it should go in the JDK.

Java is not a programming language specifically for Windows or specifically for Linux. It is a language for the Java Virtual Machine. There is no point of programming for the JVM unless most platforms support most of the JVM features and by most I mean 95%.

If you want OS-specific features I would suggest you use some 3rd party JNI library (numerous ones exist) and leave this stuff out of the JDK as it doesn't belong there. Just my 2 cents.

mijzcx
Offline
Joined: 2004-09-11
Points: 0

I am thinking of multiline string (verbatim).

See...
http://forums.java.net/jive/thread.jspa?threadID=2522&start=0&tstart=0

Support for verbatim string literals. Dated JUN-21-2001.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4472509

Had anybody an Expert Group JSR this one "syntactic sugar"?

erickson
Offline
Joined: 2004-07-07
Points: 0

Can you explain where a multi-line string would be useful?

In the code I've worked with, a multi-line string is a sign of a design flaw, not something that should be encouraged. But can you provide some examples of where long strings embedded in source code are a good idea?

jwenting
Offline
Joined: 2003-12-02
Points: 0

But Ruby has it so Java MUST have it too!!!!!!!

roguexz
Offline
Joined: 2003-08-13
Points: 0

I think we need a standardization on basic user management. I am not aware if there are any JSR's already in progress or not.

I am aware about Project Liberty, but i couldn't specifically find any Java spec for it.

The reason I am suggesting this is because, in almost every major project, we need to leverage the concept of identity management. It would be great if as an end user, I had access to some simple User management APIs (which could be configured to access an LDAP store or a DB store).

What do you guys think about it?

thanks,
Rogue

p.s.: If I am ignorant, please enlighten me about where such a package definition exists.

vhi
Offline
Joined: 2004-10-11
Points: 0

I would rather wait for the upcoming Compound Document Format specification from w3c (it is basically SVG+XForms+CSS). I think a proper Java implementation from Sun would be sufficient to satisfy our need for GUI XMLs. What I am sure about is that I do not want yet another GUI XML. It is better to have one standard and sticking to it.

brittpark
Offline
Joined: 2004-10-09
Points: 0

java.os.unix
java.os.macos
java.os.windows

or some other logically named platform specific libraries that are standardized and shipped with the JDK and JRE.

Sun has to wake up to the fact, particularly now when most java coding is for midddleware and server technologies, that write once run anywhere doesn't always cut it. Many applications need access to os specific features to be feasible, just take os users and groups, file permissions, process ownership. Practically every enterprise Java project I know of has to deal with these issues, and usually does by resorting to JNI. There must be literally hundreds of private implementations of essentially the same functionality. They are not particularly difficult libraries to write and maintain, and would greatly add to the scope of Java's applicability.

zander
Offline
Joined: 2003-06-13
Points: 0

> or some other logically named platform specific
> libraries that are standardized and shipped with the
> JDK and JRE.
>
> Sun has to wake up to the fact, particularly now when
> most java coding is for midddleware and server
> technologies, that write once run anywhere doesn't
> always cut it. Many applications need access to os
> specific features to be feasible, just take os users
> and groups, file permissions, process ownership.

While I fully agree that these functions should be available from Java in the base classes, I see no need to have that in OS specific packages.

ethernet options, groups, advanced permissions and even process ownership are all common functionality that all OSes have. And I really mean all OSes here, including MacOs.

The simple extentions to the core API such as File.getOwnerId(), File.getGroupId(), File.isWorldReadable() should be a JSR IMO.

mthornton
Offline
Joined: 2003-06-10
Points: 0

> The simple extentions to the core API such as
> File.getOwnerId(), File.getGroupId(),
> File.isWorldReadable() should be a JSR IMO.

What would File.getGroupId() mean on Windows and what would be the type of the result? A File.getOwner() method might reasonably return java.security.Principal. You could also have File.canRead(Principal p) and File.canWrite(Principal p), and then be able to obtain a 'Principal' corresponding to 'Everyone'.

Perhaps some of this is under consideration by the much delayed JSR 203 --- it would be nice to know what that JSR team is up to. All we know beyond the original JSR (7 Jan 2003), is that the target has now slipped to Mustang. :-(

s690716
Offline
Joined: 2004-03-04
Points: 0

Proposed? Simply implemented...

This quote is very interesting and explains the missing implementation of jsr 203 and the missing support for community needs - simple (?) politics:

[i]JSR-203, "More New I/O [(NIO)] APIs for the Java Platform (NIO.2)," is a proposed new input/output APIs. [b]It was originally intended to appear in J2SE 5.0[/b]*, which has been publicly available since September 2004.

"Google is disappointed that JSR-203 has missed two targeted J2SE releases and that it has not moved out of the 'Expert Group Formation' phase in the two years since it started," the company stated in the comment area of its vote on JSR-270.

Officials were not available at press time for more comment on its issue.

Reinhold, who was the specification lead for the first NIO, JSR-51, said JSR-203 was originally pushed back with the intent of placing it into the next feature release, but the faster release model meant it wouldn't be developed in time for Mustang.

"At the time we dropped it from Tiger, we were still operating under the old release model which would have placed Mustang three years after Tiger, but when the new release model came along, we looked at [JSR-203] and thought, 'hmm, well, we could rush and try to do this in Mustang,' but it's sufficiently big and sufficiently important that we thought it was better to hold it off until J2SE 7, [code named] Dolphin.

"It will still come out three years after Tiger, it just won't be in Mustang," he added.[/i]

[b]* error correction: "It was originally intended to appear in J2SE 1.4" and then the jsr was edited... 3 + 3 = 6[/b]

Source: http://www.aspnews.com/news/weekly/article.php/3487146

Conclusion:
Sometime we can read the following line:
"hmm, well, we could rush and try to do this in Dolphin," but it's sufficiently big and sufficiently important that we thought it was better to hold it off until J2SE 8...

Or 9, 10...?! who knows?

And don't ask for a platform independant TWAIN API... JNI is your friend. ;-)

steevcoco
Offline
Joined: 2004-05-23
Points: 0

I can agree with a simpler GUI model -- a lot.

My feeling is that Swing should be moved into the EE space. There is a long-standing bug on the parade about "keep AWT development alive" and it would be nice to see that get attention again.

In straight up version 1.0, we had: the subset of known "common" widgets (the AWT components) and the Component class itself so we could write our own framework. That is all Sun did with Swing anyway.

- Steev.