Skip to main content

Is the Java SE API too big?

47% (440 votes)
53% (499 votes)
Total votes: 939


How about separate Java SE by different purposes?

For example, if the app is developed without UI, no AWT or Swing api is needed. If the app is no relation with networking, the network package is no need. How about we package several sub-packages by different purposes?

How about separate Java SE by different purposes?



Pull out the old...

All the old stuff gets stuffed into its own jar file. If you need backward compatability you include the jar file in your project. If you don't you have slimmed down the size of your project.

java desperately needs refactoring!

There are 2 problems: 1) there are a bunch of big libraries in J2SE that almost nobody uses (has anyone ever used that CORBA shit?) 2) Due to the evolution of the platform thare are a lot of ways of doing the same thing now (start to smell like C++...) and even then sometimes not one of those ways is good (Calendaring anyone?). Here' s some stuff I'd like to see: * remove all pre 1.5 deprecated stuff. Really this should have been done a long time ago. What's the point of deprecating something if 7 years later it's still in there? If people know that it's never going to be removed anyway why would they not keep using it? This will make it easier for new people to learn java and it also will make the JDK size smaller! * refactor some stuff that does break backward compatibility. I've never seen a system after it was put into production been changed to a new JDK version so backward compatibility is overrated. And if old code is reused in a new project and some classes/methods are now gone then programmers are smart enough to change the code to use the replacement classes. Here' s some ideas (there many more possible): * put collections in its own proper package e.g. java.util.collections instead of intermingled with other stuff * put date/time stuff in its own package, e.g. java.util.datetime + simplify it drastically! e.g. i find the way factory methods are used on the abstract superclasses (for example Calendar.getInstance()) a rather convoluted design. I would have been much nicher to split the factory and abstract base class and have a separate factory class (which is a more used design pattern if you look at most good OS projects). The same goes for java.text. * merge the javax.sql into java.sql. Having a single API (JDBC) spread over two namespace is awkward to program. The guy who came up with the horrendous idea of javax package names should be fired! * remove some of the functionality in java.text that can now be much better done with regular expressions (e.g. StringTokenizer) * merge java.nio and into one package ( and only keep the good stuff (nio) . Also the whole io system in java is way too complicated. Why is this so complicated? In other languages like C++ (streams), Perl, Python,... it's really simple. * merge the awt stuff that Swing builds on (the core stuff like events etc.) into the javax.swing packge and remove the awt package. * remove all the corba stuff from J2SE. (Almost) nobody uses this and this just pollutes the namespace when doing code completion in an IDE. This should be an optional jar that can be downloaded from the SUN site. There's lot's more that could be done in J2EE but i'll stop here ;)

java desperately needs refactoring!

Yes, people do use that CORBA sh**. It's also actually used behind the scenes in RMI, which means even more people use it.

java desperately needs refactoring!

I sincerely doubt that the whole corba stuff is needed for RMI. It wasn't in there in JDK1.2 and RMI worked just fine. It might be used for RMI/IIOP but that's more of EJB thing and should probably be included in J2EE then not in J2SE. Anyway talking pure CORBA development: of course there's always somebody who is going to use a feature if it is available. But I doubt a great percentage does use the Corba stuff. So the question becomes should the whole bunch of packages be included in the standard JRE but a small number of users??? Downloading a jar from a site and including it in your classpath isn't that much work... I do it al the time for OS stuff I use ;)

java desperately needs refactoring!

Yes, people do use that Corba S***. At least in the corporate world that I play in. Refactoring is great, but your suggests would break an awful lot of software. Although the status-quo perhaps is a bit inconvenient for some developers, its very convenient for the customers (they don't have to get new versions of your software before they can run on the latest JVM). Yes, it is a drag for developers (me included), but backwards compatibility is paramount.

java desperately needs refactoring!

Of course it will break stuff but some OS projects actually do major refactorings from time to time that breaks backward compatibility and you know what? It's not such a big problem. People (meaning java developers) are smarter that SUN or you think. With good documentation concerning the refactoring and an IDE with good refactoring tools your code can be reworked in a matter of hours. I just swiched my project from Hibernate2.18 to Hibernate3 witch even changed its root namespace. I got everything working again in a couple of hours. So no big deal. And if something is deployed just leave at the current VM level => no refactoring needed.

Some people *are* resource constrained

*sarcasm* I suppose people on dial-up with five-year-old 200MHz computers like my mom don't exist? */ sarcasm*

Even more annoying is when Sun includes an API in the standard libraries, and then it winds up being only so-so in usefulness, and get eclipsed by something better from somewhere else (usually the OS world) (Log4J comes to mind). We're stuck distributing the library nobody uses with the VM, and app developers have to supply the extra libraries with their apps.

I would like to see all APIs tried in the "real world" as seperate bundles *before* a JSR is submitted to tie them into the VM.

Consolidation is more the problem...

I personally think the problem is not the size, but those incosistencies that are due to the platform evolution. For example, Collections and their not being used in Swing/AWT, Enumeration vs Iterator, PrintStream vs Writer, io vs nio, ... The more the platform evolves, the more we will have these incosistencies that are very very confusing to newcomers. Not that I know how one would solve the problem without sacrificing backward compatibility (which can't be done) or adding some even more complex scheme (like having the JDK have multiple versions of the libraries, and the ability to specify at commandline whether one wants java 1.0, 1.1, 1.2, ...). Do other people agree? Any ideas on how to fix it?

I say, "Bloat away".

To me the question of bloat is only pertinent for a resource constrained environment. A couple of years ago portable devices such as MP3 players were commonly available with 64 MB's of memory. Today that figure is 256 MB's, and 1 GB devices seem to be coming out every other week now. There's even some talk about Flash memory overtaking hard disks in the portable market (laptops included). Commodity PC's are starting to ship with 512 MB's of memory. My point is, the question of bloat should not involve resources (IMHO), since available resources are clearly growing at a non-linear rate. By the time round two of this debate is reached, my cell phone will have gigabytes of available memory. My PC will ship with >terabyte of disk space. So I say, "bloat away". Having access to a large established library is what makes Java rock for me.