I was reading a question StackOverflow about What is Boost missing?
and I was wondering how many of these features are available in Java already and whether making boost more like Java is good idea.
|Suggestion||What is in Java|
|JSon||Requires an additional library like XStream, Possibly should be in core Java|
|Audio||Java has basic support. Don't know if it much good.|
|callstack, a standard API||Throwable.getStackTrace() and Thread.getStackTrace()|
|Support for archives||Support ZIP and JAR|
|Redeveloped collections||The same could be said for Java Collections|
|Standard XML parsing for UTF-8 text||SAX (event driven) and DOM (Document object model) parsers for XML|
|Platform independent GUI||Swing|
|Concurrency with lock free collections and atomic operations||Concurrency library|
|Arbitrary precision floating point and decimal||BigDecimal and BigInteger|
|Python, Ruby and Lua support||Not built in, but there is Jython, JRuby and LuaJava|
|High performance (sub micro-second) timers||System.nanoTime()|
|Better concept support||This looks like staticly defined duck typing and Java is a long way from having anything like this. ;)|
|Atomic||AtomicBoolean, AtomicInteger, AtomicLong, AtomicReference, AtomicIntegerArray and AtomicLongArray|
|Thread pools||ExecutorService and ScheduledExecutorService|
|GPU support||I would love Java to have this as well. There is JoCL but its not exactly transparent or close to the Write One, Run Anywhere model.|
|Hashing/Checksums||MessageDigest and CRC32|
|OS performance measures||This is poor in Java. You can get the load average but its always 0 on windows.|
|Co-routines||The closest is fork/join with anonymous classes. In Java 8 methods will become first class objects which is a little closer.|
|Fixed size strings||You can have this in Java. However I assume the point of this is efficiency, which Java is unlikely to match, ever.|
|cryptography||Java SE Security|
|Extend GC to trigger a GC and handle when an object is cleaned up.||System.gc(), finaliser() and PhantomReferences|
|A overflow/underflow safe integer||This would be useful if language support was included, but I doubt that will happen, (like unsigned int)|
|unification and backtracking||This could be added in the far future. I imagine after Java 8|
|Singletons||An enum with one instance (enum are Objects in Java not int values)|
|A Persistent Collections Library.||Java doesn't have much support for functional programming. This is something which it could have, but I don't imagine it being any time soon.|
IMHO, The best suggestions which are missing or could be better in Java are
- persisted collections
- JSon serializaton/deserialization
- GPU support
- Good OS performance measures
Even more useful would be a common interface and basic support for collections which are distributed and persisted. e.g. standardised/simplified Hazelcast, Terracotta and Hibernate. @Vyadh points out this is not what is meant by a persisted collection
in functional programming
While I really like Java, but I have never looked at C++ & Boost and thought; if only it were more like Java. (Some of the limitations of the C syntax are a bit backward IMHO) I have thought this about the refactoring tools in IDEs e.g extracting a method from a body of code (and have it replace any duplicates)
Is making C++ & Boost more like the relatively heavy weight Java a good thing? Or is it better to use a language for it strengths?
When they say "persistent collections", I would have thought they are more likely to be talking about immutable functional data structures.ReplyDelete
@Vyadh, I suspect you are right. I meant it would be good to have collections which are transparently persisted. (Without the luggage which comes with hibernate)ReplyDelete
What do you think about Jackson(http://www.cowtowncoder.com/hatchery/jackson/index.html) or GSON(http://code.google.com/p/google-gson/) as an implementations of json serializations/deserialization.ReplyDelete
To me Java's biggest hurdle going forward is recoding parts of the JVM and standard libraries to be OpenCL accelerated.ReplyDelete
@Maxim, Jackson, GSON and XStream (for JSon) and all good but not part of the JVM. Boost is so commonly used, its almost considered part of C++ for many projects.ReplyDelete
@Chad, At a minimum Java should be able to be compiled for OpenCL or have OpenCL support. In theory this should be relatively easy, but I am sure in practice is not. I don't imagines its on even on Oracle's radar as their hardware doesn't support it AFAIK.
Yep, easy and transparently persisted collections would indeed be nice.ReplyDelete
"Java doesn't have much support for functional programming. This is something which it could have, but I don't imagine it being any time soon."
I am pleased to say that that on the Lambda mailing, they are showing the functional collection API's that are going into Java 8. No sign of persistent and lazy collections yet though.
@Vyadh, One of the signs that Java's designers still don't get functional programming is a lack of tail recursion optimisation.ReplyDelete
Functional programming should be a way of describing some problems elegantly and efficiently.
Libraries have been written which give functional like features but they have always been slower and wordier to write than a simple loop or non-functional approach. In theory, automatic parallelism of functional programming should make it faster (in some cases) I believe this is the stated aim of adding closures to Java 8 (Making it easier to use more cores)
Closures will help, but in the meantime there is always Scala ... ;)
OT to the point of your post and really this is just a rant.ReplyDelete
Some of the features that you mentioned as part of the standard jvm is also generally avoided as complete ... crap.
Logger. Who uses the jdk logger?
BigDecimal/BigInteger. These are NEVER used in an programs that I know of that require performance sensitive currency handling as they are significantly slower.
Swing. Still heavily used as there's not really a good alternative for desktop apps but this hasn't progressed in ages. (javafx?) Also, I could be wrong, but wasn't there rumors that swing will be deprecated in the future?
@H3adache, Its not meant to come to an conclusions or say whether anything is good or bad.ReplyDelete
I have seen Logger used more and more, simply because it is standard. Java took a long time to support this and there are lots of libraries out there that people were already using (and probably better)
Performance sensitive code shouldn't be using objects any more than absolutely necessary. Using int, long or double is usually a faster solution.
The biggest direct challenge to Swing would be the Android GUI. I imagine that slowly it will try to takes its best features. I have heard this rumour but it doesn't appear to have any basis.
I would hope that Boost learns from Java's mistakes as Java once tried to do from C++. ;)
Yes, ParallelArray looks pretty nice.
Scala (that's Scala programming to you TIOBE) has certainly been the way to go for us. However, I don't hold too many great hopes it will hit mass adoption, so it's still in my interest for Java to stay current - if only to help our recuitment for potential Scala developers :)
Nothing wrong with the JDK logger. If you just need something simple, or are willing to add the odd handler/formatter, then it's perfect - and comes with the (albeit minor) benefit of one less external dependency to manage.
BigDecimal. Often it is far more important to get something right, than have it be fast. I work with financial systems with many different currencies. It is plenty fast enough for our purposes. Also, in Scala, it's just as nice as using a primitive type.
Some of the functionality I have added already has standard function names in Scala. So even if most people using the library use Java the naming will be following some sort of standard.ReplyDelete