Slashdot Mirror

Java has been doing realtime for over a decade now. In fact the very first JSR was JSR 1: Real-time Specification for Java which began in 1998.

Saying Java is not suitable for realtime due to "unpredictable GC" shows you haven't read much on the topic. Many Java open-source projects guarantee millions of operations per second on the right hardware. Java has a huge HFT community footprint.

Take a look at what http://chronicle.software/ and OpenHFT is doing for instance.

But Java was the important thing we couldn't let die. And it isn't open source so the community couldn't steal it away from oracle.

Java is fully open-sourced and the most open-sourced programming language I know. OpenJDK is the same source code Oracle uses for its JDK. It's easy to download and compile all Java executables. Here is a guide and a Youtube video detailing how to build the JDK.

Java is defined and updated by the JSR process, which resembles RFCs. And also by the JEP process which tells you exactly what's being built into Java and when. You can also use their bugtrackers and mailing lists to track Oracle engineers' work.

I've learnt a ton just by tracking those lists.

It is a lot easier to embrace an "open standard" when you developed it yourself, then donated it to a consortium.

WBEM is a decades old open standard implemented by just about every major software and hardware manufacturer out there. It's shipped with just about every OS. The computer you are using right now probably has CIM implementation built in or at least available in the core OS.

The standard is managed by the Distributed Management Task Force which includes most top software firms. Here is the Java JSR-48: WBEM Services Specification and Implementation for example.

What Microsoft is giving the open-source community is a CIMON ( CIM Object Manager ) implementation. This is fully standards based and Microsoft is just donating the code. But as mentioned earlier Ubuntu and most OSes already ship with a lightweight CIMON.

They're adding a currency API in Java 9: https://jcp.org/en/jsr/detail?...

Well I work with Java all the time and I find Swing great to use, but when I want to build my own user interface elements, then yes, I find it very painful indeed. I've done custom widgets in Cario/GTK, .NET, and even for Android; and Swing is pretty up there for the bar that needs to be crossed to have a custom widget. I don't find Swing all that difficult to use at face value but just mucking about AWT or even SWT is far better than trying to muck around and build custom GUIs in Swing.

In that respect, GWT is worst. GWT makes a lot of assumptions about how you want to convert Java into JavaScript. When you want to create your own web elements, not only do you have to build it using some of the worst API I've seen, you actually have to fight the assumptions that GWT tries to make right out of the box. You are literally fighting on two fronts to just make a damn clock widget or rich editor widget. It is ridiculous.

GWT on a whole is a pretty sad state. It integrates poorly with JEE frameworks and when it does, it's literally shoe-horned. You'll find that something like JSR 356 is a waaaaaay better approach to bridging the gap between server side code and client code, and I'd hope that the Java community can keep hitting excellent projects like this. Because Google isn't doing it with their idea of interoperability.

Also since you want to be mincing words between library and framework. If you happen to head over to JSR 296 you'll see that the JSR refers to it as "The Swing Application Framework". Maybe you should head over there and educated them that they should have called it "The Swing Application Library". That being said, I believe your retort to have loss any of its credibility but seriously, this is Slashdot, does anyone think anything on this site is credible? Hope you are still laughing though.

We built Java to be an open source computing platform freely available to anyone wishing to use it. In 2006, Java was released under the GPL open source license and we continue to develop and innovate the platform under the same open source license -- it is available to everyone at: http://java.net./ This openness allows device manufacturers to customize Java and enable new user experiences, driving innovation and consumer choice.

As the lead developer and shepherd of the open platform, we realize that we have a responsibility to app developers -- those who invested in the platform by adopting it and building applications specifically for Java. These developers each contribute to making the platform better -- because when developers support a platform with their applications, the platform becomes better and more attractive to consumers. As more developers build great apps for Java, more consumers are likely to buy Java devices because of the availability of great software content. As more delighted consumers adopt Java phones and tablets, it creates a larger audience for app developers to sell more apps. The result is a strategy that is good for developers (they sell more apps), good for device manufacturers (they sell more devices) and good for consumers (they get more features and innovation).

In biological terms, this is sometimes referred to as an ecosystem. In economic terms, this is known as a virtuous cycle -- a set of events that reinforces itself through a feedback loop. Each iteration of the cycle positively reinforces the previous one. These cycles will continue in the direction of their momentum until an external factor intervenes and breaks the cycle.

When we first contemplated Java and formed the Java Community Process, we wanted to create an open virtuous cycle where all members of the ecosystem would benefit. We thought hard about what types of external factors could intervene to weaken the ecosystem as a whole. One important external factor we knew could do this was incompatibilities between implementations of Java. Let me explain:

Imagine a hypothetical situation where the platform on each phone sold was just a little bit different. Different enough where Opera Mini would run normally on one phone but run terribly slow on another. Let's say, for sake of example, that Java implemented an API that put the phone to sleep for a fraction of a second to conserve battery life when nothing was moving on the screen. The API prototype for such a function might look like SystemClock.sleep(millis) where the parameter "millis" is the number of milliseconds to put the device to sleep for.

If one phone manufacturer implemented SystemClock.sleep() incorrectly, and interpreted the parameter as Seconds instead of Milliseconds, the phone would be put to sleep a thousand times longer than intended! This manufacturerâ(TM)s phone would have a terrible time running Opera Mini. If apps donâ(TM)t run well across devices due to incompatibilities, consumers would leave the ecosystem, followed by developers. The end of the virtuous cycle.

We have never believed in a âoeone size fits allâ strategy, so we found a way to enable differentiation for device manufactures while protecting developers and consumers from incompatibilities by offering a free "Technology Compatibility Kit" (TCK). TCK is a set of software tools that tests and exercises the platform to make sure that (for example) SystemClock.sleep(millis) actually puts the device to sleep for only milliseconds. Like Java, the test suite is freely available to everyone under the OpenJDK Community TCK license: http://www.jcp.org/en/resources/tdk/

While Java remains free for anyone to use as they would like, only Java compatible devices benefit from the full Java ecosystem. By joining the Java Community Process, each member contributes to and builds one Java platform -- not a bunch of incompatible versions. Weâ(TM)re grateful to t

You write the C# -> native compiler first ;)

And how do you think C# code is executed?

The "Native Image Generator" is

the Ahead-of-time compilation service of the .NET Framework. It allows a .NET assembly to be pre-compiled instead of letting the Common Language Runtime do a Just-in-time compilation at runtime

Not an ordinary .exe, granted, but the native code is there even in normal C# use. Ordinary native binaries can be generated from C# if necessary though - this is how Mono targets platforms like the Wii. The reason you can't write (normal) Windows drivers in C# is because Windows isn't written in C#.

That said, bindings exist for libusb, so that's a start.

(There seem to be a number of similar bindings for Java, and a standard API spec that no-one's implemented.)

Google tells me two operating systems have been written in C#: Cosmos and Singularity.

This isn't to say C# is more suited than C to OS/driver work, but it can be done.

The more you talk the more it is obvious you don't even understand Java. So here it is in nice big slides so even you can comprehend: http://jcp.org/aboutJava/communityprocess/ec-public/materials/2011-02-15/Compatibility.pdf

http://jcp.org/en/jsr/results?id=5207 There you will find the comments... It is good to see that it is not google the one that would like the license of java changed, but IBM and SouJava as well.

Interesting that they view the licensing and transparency as deal-breakers, and doubly interesting that a majority of the committee members feel somewhat supportive of that position (but not enough to vote against).

How I understand it is this: The licensing terms restrict Google from making their own platform specific version using the spec. It basically stops Google from rebranding Java to "Gava" and using it as the language of choice on Android.

"While Google supports the technical content of this JSR, we are voting no because of its licensing terms"

Typical

Interesting that they view the licensing and transparency as deal-breakers, and doubly interesting that a majority of the committee members feel somewhat supportive of that position (but not enough to vote against).

On 2010-12-05 VMWare voted Yes with no comment.

If they're not happy, then too bad. They made their own bed.

If you are implying that Apache has some anti-Oracle grudge, I think the conflict probably started after Oracle launched the first-strike by suing Google over its use of Apache's Harmony in Android (and other stuff. Oracle is being represented by BS&F who mastered the art of being unspecific when they represented SCO vs. the Free world). If Oracle hadn't violated the terms of the JSPA, their law suit against Google would have had no merit because according the JSPA, Apache was supposed to get an irrevocable, license to the very copyrights and patents Oracle is suing over.

If I had to dole out blame I would give 2% to Sun and 98% to Oracle.

I'm curious to see how this is going to play. Given that Java technology are open specifications is a "Clean Room" implementation a doable defense?

Java was never in the hands of any one company, not even Sun- because Java (both language and frameworks) is controlled and evolved using the JCP (Java Community Process).

There are a variety of companies on the various panels so any one company cannot hijack (or kill) the language or platform.

That was always part of the strength of Java, instead of going through a more hidebound standards body they created one specifically for Java, run by the people of the Java community.

http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html
http://jcp.org/en/jsr/detail?id=310

Interesting. I noticed especially the comment:

JSR 310 classes store date/time representations only as a nanosecond offset from the same standard epoch used by Date and Calendar; calendar fields such as day of month are only computed when needed and are not used for internal representation of dates.

Back in the late 1990s, I worked as a developer for a project that was mostly done in java. One of the things we had to deal with twice each year was that, when we switched to/from Daylight Saving Time, the java time-handling code went insane. Every time. We'd dig around to try to find the problem this time, and each time we'd find a good number of discussions of the problem.

I kept pointing them to java "standards" which stated that java's internal clock was kept in local time. I'd simply comment that this totally explains the problems. No time package whose basic clock is any representation of local time can ever be made to work quite right. The main reaction of the managers was to treat me as a trouble maker, and periodically accuse (;-) me of trying to secretly introduce Universal Time into their software, when I knew they wanted only local time.

After a few years, I moved on, as developers usually do. I've talked to the people still associated with the project off and on, and usually asked them about their DST problem. It still bites them every year. I shrug, and move on to another topic. Since then, I've worked in a few projects that used java and were contemplating changing more of the code to java. I've suggested that they should look up the twice-yearly online discussions of DST-related time bugs. This has often been enough to put a damper on further java plans.

It's good to know that the java people have a time package based on a single universal epoch counter, and which even counts nanoseconds. Maybe this will end the time problems. Or maybe managers will nix its use on the grounds that they don't want any of that UTC stuff in their code. Time will tell, I suppose.

And I suppose it's all part of the general problem of bureaucratization of the java user culture. It was pretty bad even 15 years ago, and doesn't seem to have improved with age. So I now mostly prototype in perl or python, and when I have a quick-and-dirty version running, I start talking about recoding it in java (or C++ or C or whatever). It's interesting how often I'm told to not bother, and work on a prototype for something else that's needed.

It does go along with the observation that a major reason for much our ongoing software problems is that most of our code is prototyping. Developers are rarely allowed the time to do it over the right way. I've seen cases in which N departments in a company have "standardized" on N different versions of the prototype code, all of which are slightly incompatible with the others, and none of the managers will permit redoing it all as a single package that works the same everywhere. And you have to carefully hide from them the fact that your date/time calculations use a basic UTC "epoch" counter, because they want it all to be local time.

And doesn't the java sandbox model prevent java applets from writing to the filesystem?

IIRC, this vulnerability was specifically caused by improperly letting applet code out of the sandbox. The problem was when deserializing a Calendar object, there are com.sun classes involved which require the deserialization code to run at a higher permission level since com.sun classes are outside the sandbox that applets typically live in. So Sun created a loophole for deserializing Calendars. What they didn't count on was that the attacker could supply a serialized class that was not of the correct type but had static initialization code. So by the time the JVM deserialized the class and threw a ClassCastException, the static initialization code had already been run at the escalated privilege.

So yes, this vulnerability was every bit as dangerous as it was hyped to be. The attacker could load an applet that phoned home for the code that it needed to run and then ran it, all within that static initialization block. The code did not need to be present on the victims computer ahead of time and the sandboxing did not protect the user.

It's not all on Apple though, since Sun is partially to blame for the crap state of Date/Calendar APIs in Java. Better libraries like JodaTime have been around for a while and there was even a JSR for adding something similar to Java, but Sun didn't prioritize it. Still, Sun released a fix a long time ago and it took Apple months to apply the fix to a new Java release.

I think the JCP has pretty much destroyed Java.

I think quite differently. The JCP has brought us things like JOGL, JAXP, and many more advancements of the Java technology.

They reneged on those promises because it forced them to open up the language too much

Because Sun saw fit to prevent Microsoft from making a bastard version of Java? Because such a version would have destroyed the entire point of Java, Write once/Run everywhere? Much like their MS LDAP? (I mean Active Directory.)
Moot point now that Microsoft has their own Java, er, Runtime.

they have numerous patents on core Java and the libraries.

Do you care to point them out? And how OpenJDK has worked around those?

why should using Mono bother any open source developer?

Because Microsoft is a big software bully. Really, however, the implementation of Mono works around the tricky parts much like OpenJDK does. I know all too well the pain that Mono devs must face. OpenJDK gets dogged for, "Always being behind the one true JVM," or "Java is a patent trap, GPLv2 wasn't enough, now we're making exceptions?!" In the end, I don't think that I'm your target audience for that question because I think Mono does enough to protect itself.

I don't know about .NET, since I don't use it. I do use Mono...but Java is a good example to contrast with Mono because many people regard it as "open"

Java like .NET is a platform. Sun's Java implementation is to Microsoft's .NET implementation as OpenJDK's Java implementation is to Mono's .NET implementation. I can see that you can tell the difference between MS .NET and Mono .NET, I hope I've cleared up the comparison for JVMs as well.

I think the JCP has pretty much destroyed Java.

I think quite differently. The JCP has brought us things like JOGL, JAXP, and many more advancements of the Java technology.

They reneged on those promises because it forced them to open up the language too much

Because Sun saw fit to prevent Microsoft from making a bastard version of Java? Because such a version would have destroyed the entire point of Java, Write once/Run everywhere? Much like their MS LDAP? (I mean Active Directory.)
Moot point now that Microsoft has their own Java, er, Runtime.

they have numerous patents on core Java and the libraries.

Do you care to point them out? And how OpenJDK has worked around those?

why should using Mono bother any open source developer?

Because Microsoft is a big software bully. Really, however, the implementation of Mono works around the tricky parts much like OpenJDK does. I know all too well the pain that Mono devs must face. OpenJDK gets dogged for, "Always being behind the one true JVM," or "Java is a patent trap, GPLv2 wasn't enough, now we're making exceptions?!" In the end, I don't think that I'm your target audience for that question because I think Mono does enough to protect itself.

I don't know about .NET, since I don't use it. I do use Mono...but Java is a good example to contrast with Mono because many people regard it as "open"

Java like .NET is a platform. Sun's Java implementation is to Microsoft's .NET implementation as OpenJDK's Java implementation is to Mono's .NET implementation. I can see that you can tell the difference between MS .NET and Mono .NET, I hope I've cleared up the comparison for JVMs as well.

If anybody can point to an actual patent that Mono or Tomboy violate, please file an issue report against the Mono project;

I know it is a bit old but, we'll file one once they publish which part they're going to patent, of course, that shouldn't be long. PS: The only complaint I have of .NET is the syntax of LINQ, but what'cha going do?

Besides, anyone thinking that MS would attacking Linux using patents isn't giving Microsoft any credit. I figure that they would try to kill Linux (GNOME proper, since GNOME != Linux) via contracts with Linux vendors as opposed to patents. It just seems too obvious to go that (patents) route. Linux isn't the problem with MS, it is more like the vendors pandering Linux that is.

Also I develop on OpenJDK, I was wondering if you could provide a list of patents that the OpenJDK is infringing on? I'm sure we could work out what it is that you feel is something we may have overlooked.

Mono is way ahead of languages like Java in that regard because, unlike Java, Mono is based on an open standard

Could you clear that up? I'm not sure I follow what you are talking about. Is it because .NET is a standard through an organized body? Whereas, Java is basically a community process with Sun at the head of the community? If this is your beef with Java then what exactly is different between how Java is made versus something like, Linux or GNU HURD?

Besides, what is all this seemingly bad blood between .NET and Java? I've been to many PDCs and the people behind .NET seem pretty accepting of Java much like the Samba - Microsoft love (which granted isn't awesome but it is still pretty good). Also, the Mono devs are pretty cool people on IRC. Really? Do we need to build walls?

If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.

The problem you're referring to is a well-known limitation of the java platform with a planned solution. The problem is that it's been stalled and hasn't made it past the JSR stage despite being first reviewed in 2001.

See either: Project Barcelona or the Java Isolates JSR.

That combined with the Java Resource Consumption Management API would, if implemented, give application server vendors everything they would need to make a Servlet container that could be used in a shared hosting environment.

Until then, Java just isn't suitable for a shared hosting environment...at least not in the out-of-the-box kind of way. I have managed to string together a thin C CGI implementation that uses IPC to connect to a running Java process through JNI. It worked and actually substantially out-performed any of the scripting languages available from the hosting provider, but it took quite a bit of work to get running (mostly emulating what the Servlet API gives you for free) and the code I ended up with might not be portable to a real Servlet environment since I didn't bother implementing all of the Servlet API.

Long story short...I've felt that pain and can't wait for those two JSR's to make it into a new release of Java. I only wish Google's Java API had been available at the time.

If you want real problems, try running Java apps on a shared hosting provider sometime. The limitations of those sites will have you shouting praise for what Google is offering.

The problem you're referring to is a well-known limitation of the java platform with a planned solution. The problem is that it's been stalled and hasn't made it past the JSR stage despite being first reviewed in 2001.

See either: Project Barcelona or the Java Isolates JSR.

That combined with the Java Resource Consumption Management API would, if implemented, give application server vendors everything they would need to make a Servlet container that could be used in a shared hosting environment.

Until then, Java just isn't suitable for a shared hosting environment...at least not in the out-of-the-box kind of way. I have managed to string together a thin C CGI implementation that uses IPC to connect to a running Java process through JNI. It worked and actually substantially out-performed any of the scripting languages available from the hosting provider, but it took quite a bit of work to get running (mostly emulating what the Servlet API gives you for free) and the code I ended up with might not be portable to a real Servlet environment since I didn't bother implementing all of the Servlet API.

Long story short...I've felt that pain and can't wait for those two JSR's to make it into a new release of Java. I only wish Google's Java API had been available at the time.

I fall into neither of those python/ruby groups you mention... My understanding is that they've had to perform some magic behind the scenes with class loaders and reflection etc to obtain reasonable performance. Sun's hotspot vm doesn't support tail-recursion, so lisp dialect clojure has had to add language keywords to simulate it.

Sun have made some progress in this area by hiring some of the jruby developers, introducing new bytecodes and prototyping a new language independent vm.

One interesting feature of the competition is that .NET and JVM are also looking to make themselves more friendly to dynamic languages, so it's not a totally stationary target. The most promising seems to be the proposal to add an "invokedynamic" bytecode to the JVM, which would allow a bunch of stuff dynamic languages do to be handled by the JVM (instead of them having to build their own dispatch mechanisms on top of it).

I don't know how it is implemented by MS but there is a standard for this: the NFC Data Exchange Format. Nokia implements a standard Java API for this.

How does the process that creates the .NET spec compare to the Java Community Process that create the Java spec? (The spec that Sun's Java is an implementation of) Is .NET only MS deciding what .NET is or is ECMA involved? Just wondering since you said that the .NET platform is as propitiatory as ever.

Meanwhile, other manufacturers have been able to ship phones with a Bluetooth API for six years or so... A reference implementation and test suite is available under the APL, and has been for a very long time. Just shows how utterly stupid it is to create new standards when perfectly good ones already exist.

You might find this useful to read this before your next rant: JSR 1: Real-time Specification for Java

All good colleges still teach the "hard" stuff.

Yes, the process controls all aspect of Java - the VM, as well as language. There is of course freedom to write a VM how you like to some degree, but you have to pass standards tests to be certified a "real" Java VM and so that means compliance to bytecode standards and framework standards. That too has been true ever since Java 1.1 I think, possibly even earlier as the JCP was around almost from the start.

You can peruse the history of previous changes and current proposals, at the JCP website. Look at the list of all JSR's there to get a sense of the breadth of the thing.

As I said in reality JCP does for Java what ISO does for other things. Only personally I feel like the JCP is WAY better than ISO as far as speed, and approachability - you as an individual can easily join and comment on proposals, a far cry from locked down ISO committees. It's also a big reason why Java has been able to grow so fast, yet so intelligently - because it really is the community using the thing that takes proposals into account, and makes them better through a closer to hands on experience with how the language is used.

So, no. Unless someone takes the time to apply similar optimisations to Rhino.

But as far as a Java embedded scripting engine go, the comments for this blog about Java's new embeddable web component indicate that they are using the native webkit library (and JavaScript interpreter) underneath.

So, in theory, they could expose SquirrelFish to Java clients as a JSR 223 scripting engine. Would the performance benefits be as spectacular as claimed in this context? SquirrelFish has one set of JIT optimisations, hotspot another; the two must interact via JNI. (Significant overhead???)

NPEs will become less widespread when JSR 308 becomes a reality, mostly because of @NonNull. You can read about the proposition here.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

It's handy if you just want to make some simple forms and display simple data, but for real application development I find it insufficient.

• Wireless Messaging API 2.0 (JSR-205)
• Mobile Media API 1.1 (JSR-135)
• AMMS API (JSR-234)
• Bluetooth API (JSR-82)
• Personal Information Management (PIM) API 1.1 (JSR-75)
• FileConnection (FC) API 1.1 (JSR-75)
• Mobile 3D Graphics API 1.1 (JSR-184)
• Location API (JSR-179)
• Web Services (JSR-172)
• Security and Trust Services API (JSR-177)
• Session Initiation Protocol (SIP) API (JSR180)
• Scalable 2D Vector Graphics API (JSR-226)
• Nokia UI API

Sure, this sort of beats the write-once-run-anywhere mantra (not to mention that Series 60 phones are fairly high end) but when you target a specific family of devices the options are no longer so limited.

RT
--
Your Bookmarks. Anywhere. Anytime.

There is no good reason not to use Java for real time systems as well. The very first JSR, JSR#1 proceeds to specify what is required for real time Java. Later, it has been enhanced in JSR#282, which is implemented in The Sun Java Real-Time System 2.0 (Java RTS).

There is no good reason not to use Java for real time systems as well. The very first JSR, JSR#1 proceeds to specify what is required for real time Java. Later, it has been enhanced in JSR#282, which is implemented in The Sun Java Real-Time System 2.0 (Java RTS).

I have to say this a pretty scant entry for the front page of /. Amazing it got through really. Still this does look like quite a nice tool - I hope the port it to one of the better IDE's eventually. Eclipse always seems to me to be the Windows of Java IDE's. Hugely, unaccountably successful. It does everything but it doesn't do anything well. I actually prefer Netbeans of the free/open source tools though neither are a patch on IDEA.

"next J2EE middleware standard?"
Probably. Parts of Jboss Seam and Google Guice amongst others are being formalised into the JEE6 spec -
See http://jcp.org/en/jsr/detail?id=299. Oh and its JEE now, not J2EE. Has been for quite a while).

I've always been under the Impression that Java can't use hardware rendering, wouldn't that restrict usage for more intense applications?

Have a look at joda time http://joda-time.sourceforge.net/ a JSR for this libery http://www.jcp.org/en/jsr/detail?id=310 is also scheduled for Java 7