Skip to main content

Add support for .NET

6 replies [Last post]
ahoma
Offline
Joined: 2003-06-20

When Java was initially designed, it was perceived as the JVM would sit on top of the operating system completely hiding it. The idea of 100% Java reflected this, by saying no direct access to the OS.

And this works well if you write an applet, if you are writing a servlet. However it does not work at all if you are trying to write an desktop application.
JNI is there but extremely difficult to use. And why should I write a C++ wrapper to access the operating system directly.

What we need is a simple access to the operating system. .NET provided this by allowing code to be declared unsafe and a language construct allows the declaration of an interface and you are in business.

This is what makes .NET a good platform to develop on Windows. A simple language (yes Java like) with enough hooks into the operating system.

Almost all Desktop applications will run on Windows only. Users are expecting the application to be indistinguishable from a native Windows application and for .NET applications that is the case.

I am not suggesting to make Java dependent on Windows, far from it.

But we need to embrace and extend Windows, not the other way around it. We need to make Java to embrace Windows. And in this moment Java is a second rate citizen on Windows. This is true even on Linux.

I realize this will open another religious debate. We need to push Java to the Windows desktop. We need to make Java integral part of Windows and Linux. A lot of people wrote libraries to use a Java application as a service, to show a Java application as the system tray etc. All of this should be part of a standard Java library.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
pdoubleya
Offline
Joined: 2004-02-09

The problem with this integration is not just that Java doesn't support "managed code", but also that the Windows API for instantiating widgets etc. requires callbacks and associated pointers to work.

My understanding is that this was part of the Microsoft-Sun argument a few years ago. Microsoft had their own toolkit to build Windows applications using Java, but it required the VM to support these sort of callbacks, etc. From one point of view, Microsoft was looking to enable developers to easily write Windows applications in Java, using the native GUI toolkits. From another point of view, Microsoft was forking Java, breaking WORA, and looking to eventually destroy Java by creating an incompatible version of the language. Sun took them to court and won the argument. Microsoft then developed the CLR, C# and associated languages specifically to enable this sort of coding.

You can argue both ways about this. Certainly Microsoft was breaking an agreement with Sun to respect the explicit and implicit intentions of the JLS. On the other hand, it's arguable that Sun's counter-proposal for desktop development, AWT and Swing, never took off precisely because of the problems with working with a WORA GUI toolkit.

My strong guess is that your proposal was long ago debated and turned down by Java's development team at Sun.

Note, there is a project called JDIC, https://jdic.dev.java.net/, which allows some better integration with the desktop and host operating system...for example, access to the "Tray", and the possibility of embedded a native browser component within a Java application. It's still in development but looks promising.

Regards
Patrick

coxcu
Offline
Joined: 2003-06-11

"What we need is a simple access to the operating system."

Since all of the platforms that J2SE ships on provide
similar desktop interfaces and abilities, there should be an a desktop abstraction API to provide access to the desktop shell. I'm talking about a layer over this stuff:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc...

There are RFEs you can go vote for.

RFE: javax.desktop package
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4915908

RFE: Access to desktop notification area, i.e. Windows Systray
http://developer.java.sun.com/developer/bugParade/bugs/4737770.html

RFE: Windows taskbar notification/flashing support
http://developer.java.sun.com/developer/bugParade/bugs/4902807.html

Add a system method for launching the user's default browser
http://developer.java.sun.com/developer/bugParade/bugs/4210168.html

Programmatic access to network parameters
http://developer.java.sun.com/developer/bugParade/bugs/4691932.html

To that list I would add:
Integration of the Java Activation Framework and its native counterpart.

patrikbeno
Offline
Joined: 2004-10-11

We have to keep the old promises, WORA concept, cross-platform environment, etc because that's what Java is. We should NEVER give up this goal.

So, yes I am for "embracing and extending" Windows but this MUST NOT make Java Windows-dependent!

Final note: users do not expect Java applications look like Windows apps. First of all, they just expect the same ease of use, comfort and ergonomy.

ahoma
Offline
Joined: 2003-06-20

I am not suggesting to drop WORA. But Java needs to provide better support for Windows, because in this moment is doing an abysmall job of it.

Once again, I did not suggest to make Java Windows-dependent, but clearly we need to allow for people to program for Windows in Java. They are a lot of developers developing Java applications running only on Windows.

That is not true. Only people who are running more than 50% percent of their time on something else then Windows expect a Java application to not look like a Java application. Why do you think that Eclipse become so popular, and why the best known Java desktop application is Azareus an application written with SWT ?

patrikbeno
Offline
Joined: 2004-10-11

I think SWT applications are not popular because they look natively (well that's the reason, too, but not primary). they are popular because the GUI components, widgets and so on are more usable than default Swing implementations.

I use a few Swing applications that are far better than any SWT app I've ever seen, Eclipse included. these apps do not look natively (although Windows L&F helps) but they are implemented properly and with respect to the small details that make application usable and comfortable.

Don't fool youself. SWT and/or native look does not solve all problems Java has on desktop batlefield.

tsinger
Offline
Joined: 2003-06-10

Again, full consent. The problem is not Swing, the problem are the dumb developers. Let the same developers do SWT (or Windows API or whatever) and they will produce the same horrible UIs like a lot have done with Swing (and VB and Delphi, ...).

Tom