Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Improving The Java Core Library

simoniker posted about 10 years ago | from the angry-coffee dept.

Java 37

dautelle writes "Many Java developers are frustrated by the not-so-open process to improve/correct/augment the Java core libraries. Unless you work for Sun or belong to a JSR expert group, there is very little you can do to influence the future of the Java platform. Even the JCP route can be a frustrating one (e.g. JSR-108 withdrawn by Sun because not enough progress made in a timely manner). To address this serious issue, the charter of the Java Addition to Default Environment (JADE for short) has been extended, along with the release of JADE 7.0. Participation to the jade.* package development is truly open (unlike javax.*). The library already provides numerous useful classes, bug fixes, enhanced implementations of existing classes, etc. Hopefully in the near future, the library could become so useful that it becomes a de-facto complement to the JDK."

cancel ×

37 comments

Sorry! There are no comments related to the filter you selected.

Interestin library ... this jade ... but ... (4, Interesting)

moro_666 (414422) | about 10 years ago | (#10010078)

i have been programming around with java for quite a long time, sometimes indeed i have felt like some c/c++ solutions would be so easy'n'fast'n'economic at some points, but i always have found a working workaround. seems like the jade dudes are not satisfied with that.

the thing that disturbs me about this article is that, it seems like the author would like to have this lib in java. i'm against it. because it provides tools to improve your code in many ways, but at the same time, it somewhat brings java down to the c++ like level, where memory losses and "forgotten" objects are quite common mistakes.

as a separate library, i think jade is great and the next time i'm writing something really complicated i'll surely have a look at it. but at the same time i think it should not be included in java's original libraries cause java newbies would surely make a lot of mistakes by using it and then everyone would blame Java for being so buggy and unusable for them. java has a strong and stable baselib which doesn't provide many ways to make mistakes, jade surely has greater opportunities but also greater flawsources.

however i think that sun should somehow support jade's development and offer at least a link to it under it's downloads page, so people could see that the usual oop model is not the limit and also would avoid inventing the wheel in a lot of cases.

i think sun is being conservative, cause it has always been that way, and it seems a quite secure and reasonable, cause most java apps are more secure and stable than anything else around. they are just concerned about java's reputation and dont want to rush items into their language which would overhaul new java developers and lead to popularity loss of java.

many cool libraries could be real battleaxes in the hands of java, but at the sametime, they could backfire, which sun is just trying to avoid.

keep up the good work on jade :)

I'd killed Java (-1, Troll)

Anonymous Coward | about 10 years ago | (#10011634)

There are a lot of languages with Pure Garbage Collection (fully 0% leaks-memory) (not like awful leaking Boehm-GC).

  1. elastiC [elasticworld.org]
  2. Lua [lua.org]
  3. Python [python.org]
  4. Perl [cpan.org]
  5. ... any more? ...

Sorry, Mono C# [mono-project.com] uses Boehm-GC :(

open4free © ;)

Re:Interestin library ... this jade ... but ... (0)

Anonymous Coward | about 10 years ago | (#10018240)

it somewhat brings java down to the c++ like level, where memory losses and "forgotten" objects are quite common mistakes

No C or C++ program should have these problems anymore, thanks to Valgrind [kde.org] . Garbage collection is unnecessary if you use modern programming tools.

Re:Interestin library ... this jade ... but ... (3, Informative)

jaoswald (63789) | about 10 years ago | (#10018789)

Garbage collection means you don't have to use tools that run your program in a sandbox to avoid programming errors which are unfortunately easy to make. Instead, you can spend the time making enhancements and improving performance instead of plugging stupid leaks all day.

Valgrind only fixes memory allocation problems which you can reproduce in a test situation. It doesn't fix memory allocation problems which occur when your application reaches the field and can be subjected to long runs with unpredictable inputs.

Garbage collection IS a modern programming tool. Why are you so afraid of it?

Re:Interestin library ... this jade ... but ... (0)

Anonymous Coward | about 10 years ago | (#10020124)

I think you're both wrong.

The AC exaggerates how "irrelevant" GC is.

You, on the other hand, exaggerate its usefulness and necessity.

Personally, I think GC has its place, but so does the old style. A program can work effectively with either method. A program can also use and abuse too much memory with either method. It's convenient to use GC for some things. It's good not to for others. All in all, it's good to be aware of the shortcomings of both.

This is an issue that divides programmers deeply in terms of philosophy, but frankly, it needn't. Can't we all just get along?

Re:Interestin library ... this jade ... but ... (1)

dkf (304284) | about 10 years ago | (#10022198)

Valgrind doesn't solve all problems. It doesn't even find all problems (unless you're extremely good at test suite authoring). It's a really cool tool, but let's not oversell it.

Re:Interestin library ... this jade ... but ... (0)

Anonymous Coward | about 10 years ago | (#10023439)

it somewhat brings java down to the c++ like level, where memory losses and "forgotten" objects are quite common mistakes.
Are you talking about the stack-based allocator here?

If so, forgetting objects here is not an issue! Perhaps you should look into what "the stack" actually refers to. By definition, the stack is "freed" when the function returns.

xml parser (1, Interesting)

raffe (28595) | about 10 years ago | (#10010201)

Has anybody worked with the jade xml parser. Can someone comment? It looks interesting...

New Jade Version Released (3, Insightful)

tod_miller (792541) | about 10 years ago | (#10010296)

No need to impose any library additions onto the core libraries of Java, or gripe at the JCP, however flawed, I have yet to see a similar process that works.

W3C use similar methods to develop the web standards we use every day.

Jade is a useful and in particular thier XML parsing libraries are interesting.

Look deeper and you see some interesting components. I am a little perplexed at the underlying ethos of trying to patch the core libraries with this library though.

I think the whole of Jade should be living in commons.apache.org somewhere, there is an example in invaluable libraries that I take for granted every day. That doesn't mean another programmer does, or that they should be shipped by default.

Kudos on the new version! If I ever need it, I will surely be grateful!

Re:New Jade Version Released (3, Informative)

sr180 (700526) | about 10 years ago | (#10011180)

I think the whole of Jade should be living in commons.apache.org somewhere

Apache Commons has been closed. Nothing lives there now.

Re:New Jade Version Released (3, Informative)

Anonymous Coward | about 10 years ago | (#10012835)

The author of the post was referring to the http://commons.apache.org/ commons project being closed. This is not the jakarta commons at http://jakarta.apache.org/commons/index.html.

jakarta.apache.org/commons/ (1)

trafik (707566) | about 10 years ago | (#10013055)

The project you seek can be found here:

http://jakarta.apache.org/commons/

Re:New Jade Version Released (5, Informative)

Zach Garner (74342) | about 10 years ago | (#10011304)

I think the whole of Jade should be living in commons.apache.org somewhere

You mean: http://jakarta.apache.org/commons/ [apache.org]

The Jakarta project is Apache's Java efforts. commons.apache.org used to hold common libraries such as APR for Apache HTTPD. These were mostly C libraries, I believe.

Apache Jakarta Commons (ok, so Apache needs to clean up and simplify there project namespace), rocks.

Here's there summary for commons-collections
* Bag interface for collections that have a number of copies of each object
* Buffer interface for collections that have a well defined removal order, like FIFOs
* BidiMap interface for maps that can be looked up from value to key as well and key to value
* MapIterator interface to provide simple and quick iteration over maps
* Type checking decorators to ensure that only instances of a certain type can be added
* Transforming decorators that alter each object as it is added to the collection
* Composite collections that make multiple collections look like one
* Ordered maps and sets that retain the order elements are added in, including an LRU based map
* Identity map that compares objects based on their identity (==) instead of the equals method
* Reference map that allows keys and/or values to be garbage collected under close control
* Many comparator implementations
* Many iterator implementations
* Adapter classes from array and enumerations to collections
* Utilities to test or create typical set-theory properties of collections such as union, intersection, and closure

For those doing Swing programming, also check out Java Desktop Network Components (JDNC [java.net] ) project (this isn't from Apache, unfortunately). The documentation isn't that great yet, but the API [javadesktop.org] is all you need.

Re:New Jade Version Released (2, Insightful)

notyou2 (202944) | about 10 years ago | (#10017184)

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most [sun.com] of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps [sun.com] , reference maps that allow garbage collection [sun.com] , adapters for converting collections to/from enumerations [sun.com] and arrays [sun.com] .

Re:New Jade Version Released (0)

Anonymous Coward | about 10 years ago | (#10019233)

clean up and simplify there project namespace
Here's there summary

"their".

An alternative ... (4, Insightful)

LizardKing (5245) | about 10 years ago | (#10010374)

As an alternative to trying to contribute to the Sun java and javax libraries, people could contribute to the Classpath libraries [gnu.org] . Getting these complete means effort could then be expended on useful extensions and perhaps some optional improvements to the standard libraries. If Classpath could get some serious impetus (from IBM for instance), then Sun may have to open the development of their reference implementation or risk being left behind.

Re:An alternative ... (3, Interesting)

MemoryDragon (544441) | about 10 years ago | (#10010943)

I dont think the classpath project would be a good idea, they want to emulate the core libs as good as possible. The best point to donate extensions to, is the jakarta commons project which already has many useful extensions and already has become a second core lib to many developers.

"Improving The Java Core Library" (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10010553)

"I think it would be a very good idea" -- Mahatma Gandhi

I'm confused (3, Insightful)

Anonymous Brave Guy (457657) | about 10 years ago | (#10010871)

When I read the intro, I was expecting something like a Java version of C++'s Boost libraries -- things the standard library missed or didn't do well, peer-reviewed to keep the quality up, etc.

When I read the linked page, I found more like a Java version of C++ -- it looks as though a lot of those libraries are there to overcome the very strengths/weaknesses (depending on your application) that most differentiate the two languages. If you want to use C++, why not just use C++?

Alternative to the core libs (1)

MemoryDragon (544441) | about 10 years ago | (#10010932)

Donate your solutions to the Jakarta project, namely to the Apache commons project, which is basically already a second inofficial core library, used by most programs out there. I dont think you really need a revamp of the core libary addition process, Sun is doing a fine job there, since there are so many alternatives out there.

Re:I'm confused (1)

Glock27 (446276) | about 10 years ago | (#10043217)

Unfortunately I missed this topic when it originally came up, but this thread seemed a good place to throw in my (belated) two cents...

When I read the linked page, I found more like a Java version of C++ -- it looks as though a lot of those libraries are there to overcome the very strengths/weaknesses (depending on your application) that most differentiate the two languages. If you want to use C++, why not just use C++?

I don't see why you think JADE is a "Java version of C++". If you're referring to the .realtime library, it is mainly a factory implementation that recycles objects when "new" ones are needed rather than creating them from scratch. This is a good design pattern that also works well for C++ - heap allocation is also expensive (and non-deterministic) for C++. For Java, it brings the benefit of determinism, which is very nice. Java has many strengths over C++, but its one major weakness has been a lack of determinism. Long (or even noticeable) garbage collection pauses don't work well for realtime applications (like games for instance;). com.dautelle.jade.realtime addresses that issue.

BTW, on the "make it a part of the core library" front, I don't really see the necessity. Putting it in Jakarta would be O.K., although it seems like something of a strange spot for the realtime part. At least the com.dautelle.* namespace gives the author some much-deserved credit! :-)

How times change... (5, Insightful)

crazy blade (519548) | about 10 years ago | (#10011371)


Many Java developers are frustrated by the not-so-open process to improve/correct/augment the Java core libraries. Unless you work for Sun or belong to a JSR expert group, there is very little you can do to influence the future of the Java platform.

What about MS? I think that they also wanted to "embrace and extend" Java as well at some point.

My point is, that sometimes I feel like people think free software should always get its way as a matter of principle. The truth is, that you are free to write an alternative classpath. and distribute it with your own VM as it is. Quit moaning and join in with the guys at GNU Classpath [gnu.org] . Sun doesn't mind. It's focusing on its own. That's what MS did.

That's why you should use C++! (-1, Troll)

Chemisor (97276) | about 10 years ago | (#10011997)

> Many Java developers are frustrated by the not-so-open
> process to improve/correct/augment the Java core libraries.

First Java fanatics sing praises to the fact that in Java EVERYTHING is built-in to the language, unlike in C++, where you actually have to download a separate library. Now they are complaining that those built-in libraries are not easily extended. Well, duh!

Re:That's why you should use C++! (0)

Anonymous Coward | about 10 years ago | (#10016216)

Don't be silly... I think the existance of JADE goes to show you that if you want to treat Java like C++ where you pack your own libraries with your app, that's easily accomidated.

And this is bad why? (5, Insightful)

SpootFinallyRegister (787720) | about 10 years ago | (#10012908)

Locking down the core libraries is a good thing.

Yes, people could cram more and better functionality in there, and everyone is sure their idea will just make Java better; but every new version makes Java less and less portable. Adding the same functionality in a non-core library is every bit as effective, but doesn't add the additional requirement for a new version, and will avoid breaking and deprecating enormous existing bodies of code.

If you need new or better/differently implemented functionality, you are free to add it. If Java is unable to accomodate the addition outside the standard library, then the platform has failed.

Don't get me wrong -- I'm a fan of Java. But, if the core of a language needs to be constantly updated, its an unstable language, and bad for production development. I think Java can be stable, but it requires that the developers do just what they are. Keep the standard libraries standard, and not full of every shoehorned-in functionality they can think of. Its already bloated enough.

Universally true (5, Interesting)

pauljlucas (529435) | about 10 years ago | (#10013365)

Many Java developers are frustrated by the not-so-open process to improve/correct/augment the Java core libraries. Unless you work for Sun or belong to a JSR expert group, there is very little you can do to influence the future of the Java platform.
Huh? This is univerally true for any language: unless you're on the ISO C committee, for example, you have very little influence of the future of the C programming language. Ditto for C++, SQL, XQuery, and every other language with a standard. If you want to have an influence, join a committee!

Re:Universally true (1)

michaelggreer (612022) | about 10 years ago | (#10016654)

They aren't talking about the language specification, but the core libraries that ship with the JVM. They are interested in improving and augmenting the core implementation classes. However, I happen to think building a hedge around Java is the right thing. Since you can always ship these extra libraries with your product, the need for including these v. managing the stability and interoperability of Java just isn't compelling enough.

Re:Universally true (4, Insightful)

pauljlucas (529435) | about 10 years ago | (#10016754)

They aren't talking about the language specification, but the core libraries that ship with the JVM.
Yes I know. It's irrelevant. STL (part of the C++ standard) can't be changed by anybody except the ISO C++ committee. The POSIX API can't be changed by anybody except it's committee. These people who want to change the Java core libraries are asking for special treatment and crying because they don't have it.

Re:Universally true (1)

michaelggreer (612022) | about 10 years ago | (#10017080)

Good point. I'm not sure, however, "crying" describes what they are doing. I don't think getting on the committee is easy, and even then its hard to make changes. Apache (a member) has not found it easy to bring in additions: hence our two logging systems.

Re:Universally true (1)

DrEasy (559739) | about 10 years ago | (#10020066)

There's a lot of wheel reinvention going on with Sun and their Java libraries. Witness the Collection Frameworks, where we already had the Java Generic Library (JGL), same deal with JAXP going against many good XML parsers. Now we have indeed two logging systems, and I'm willing to bet that we'll have some sort of JUnit copycat soon enough.

OTOH, my guess is that having Sun provide such libraries makes life easier license-wise, but IANAL.

Re:Universally true (0)

Anonymous Coward | about 10 years ago | (#10020172)

How much do you want to bet that if a big Unix vendor like Sun changed their OS in a way that breaks POSIX, other Unix vendors might follow suit, and POSIX itself could be changed? It's been done before.

The POSIX API evolved from existing implementations of Unix. For example, sockets are based on BSD APIs. A lot of things, like threading, are based on Solaris APIs. And so on.

So when a Unix programmer comes up with a new API that does something Unixes previously could not, groups like POSIX adopt them as standards for others to follow.

So logically, if a Java programmer creates an innovative library that re-shapes the way people do Java programming, it would only make sense if it becamse a standard part of the library. That is the spirit of how these type of standards have traditionally evolved.

Re:Universally true (1)

DrVxD (184537) | about 10 years ago | (#10034905)

> unless you're on the ISO C committee, for example, you have very little influence of the future of the C programming language

This is a little misleading. I sat on the ISO C++ committee's library working group for quite a while (and will resume doing so when circumstances permit), and we were always prepared to consider well thought-out proposals for library extentions (go check out Boost [boost.org] for several examples). All ISO committees have a route for interested parties to make changes to a standard, although it's true that your desired change is much more likely to gain support if you're prepared to join the committee and support the change in person (or can find someone to do so for you)

cern.colt (4, Informative)

rowanxmas (569908) | about 10 years ago | (#10015129)

if you program in Java and need to do matrix stuff or, want fast data structures check out:
the CERN Colt Libraries [home.cern.ch]

Re:cern.colt (0)

Anonymous Coward | about 10 years ago | (#10026224)

The above link is dated, try this

http://dsd.lbl.gov/~hoschek/colt/ [lbl.gov]

Perplexed (4, Insightful)

dark404 (714846) | about 10 years ago | (#10018654)

I've never really understood why people get their panties in a wad over the java core library. The java core is a wealth of good tools, but the language is not limited to just those tools. If you write a good library, people will use it. If you write a crappy library, getting it included in the core java library won't make people use it, it'll just waste space. I personally would rather the core library be slower to include things until they are well tested, than to include lots of new things just because they're popular. Just because YOU write a library to calculating profit given two arguments and a couple ?'s doesn't mean *I* want it included as part of the java core.

I already improved the java core library! (-1, Troll)

Anonymous Coward | about 10 years ago | (#10021326)

on my system:

rm -fR /opt/java*

It's cute, but it won't fly... (2, Informative)

dkf (304284) | about 10 years ago | (#10022460)

What we have here is a library that comes in several bits. The numeric and units handling parts are all very neat, but rather special-purpose (I just don't need them at all in my Java programs), and the stuff to allocate things on the stack for improved realtime performance is rather risky for non-experts to use (e.g. stack space tends to be much smaller than heap space, so you have to be careful with how much stuff you actually allocate on the stack). The RT bits also look (from a casual glance) like they'd need an update to the JVM and bytecodes to actually work...

JVM and bytecode updates are painful (can you say "Porting and Deployment" without winceing?) so those bits are a non-starter for general use, and the rest of it could (theoretically; I don't know how much it depends on the parts I've just rejected out of hand) just as happily be in a third-party lib, and they're something that Java's really good at.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>