Skip to main content

ANNOUNCEMENT: Java 3D plans

33 replies [Last post]
kcr
Offline
Joined: 2004-03-17

We would like to share with you our plans for Java 3D.

As many of you are aware, Sun's emphasis on client technologies has led to the creation of JavaFX -- a platform for creating rich content applications for mobile, set-top, and desktop devices. The majority of our current effort is focused on building out the 3D support for JavaFX.

As a result, our plans for improvements to the Java 3D API are on hold at this time. We will continue to provide bug-fix releases as needed, with many of the fixes coming from the community. The plan to deliver the upcoming 1.5.2 release, sometime within the next couple of months, remains unchanged.

Specifically, we are working on a new 3D scene graph, as part of the JavaFX player, that will complement the 2D Scenario scene graph. Its initial focus will be 3D effects, casual games, and simple 3D viewing applications. We anticipate that future versions will include additional features that may meet the needs of many existing Java 3D applications. As our plans about Java 3D change, we will update you with more information.

For more information on JavaFX, see https://openjfx.dev.java.net/ and http://www.sun.com/software/javafx/index.jsp
For more information on the 2D scene graph, see https://scenegraph.dev.java.net/

-- The Java 3D Team

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tmilard
Offline
Joined: 2004-03-25

> My wish list for Java3D below. >
> - Plugable renderer - ...
> - More utility classes - ....
> - [b]More cool demos[/b] -
===> At least there is one good I know of : "Sweet Home 3D" is very stable and easy to use.
Emmaneul Puybaret is a nice French guy. Good work on Swing and java3D. More and more people use it every day. Fre and Open
Here is the link :
http://sweethome3d.sourceforge.net/fr/

mcneillk
Offline
Joined: 2005-02-03

On a related note, here is an example of rich-client Java3D / SWT integration: https://sourceforge.net/projects/j3dworkbench/. It show lots of utility classes, and a GUI abstraction layer.

weiland
Offline
Joined: 2005-08-05

Hi,

Hope you saw my post from yesterday (in reply to kcr's last post, I think), I had made some of the same points (which means at least 2 people want this stuff :-)

Just a few thoughts in reply to your message:
> Future, and present, are Shaders . DX10 drop down the
> fixed pipeline, OpenGL ES 2.0 does the same, and
> OpenGL 3.0 probably will do. To me, this means that
> we, 3D developers from fixed pipeline school, must
> rethink how to program 3D in this new paradigm.
>
> Java3D does support it, did you already try it ?
>

I'm aware that Java 3D supports it; I was thinking more along the lines of abstracting it. There would be more extensive use of shaders in the engine, and perhaps the normal way of constructing appearances would use shaders (unless you're on old hardware, then maybe it would drop to "old school"). I'll try to come up with some more concrete example of what I'm talking about.

>
> A great, great, feature which Java3D has is the multi
> thread capability. This is overlooked by many

Complete forgot to mention this - agree 100%. I absolutely depend on this. This is critical to scaling performance.

> ---------------------------------
>
> My wish list for Java3D below. As it is open source,
> it is up to us to develop it towards our needs :
>

I agree with your comment on open source; however, there can't be a secret process that's deciding the direction - at best, that leads to a fork, at worst, it kills the whole thing because people move on to other products or roll their own. I'm not accusing anyone of being secretive here, but it sure would be nice if there were more open discussion in some forum about what's happening with the 3d product, whatever it may be.

Bill

tmilard
Offline
Joined: 2004-03-25

bheffner75,
I personnally started to use/learn java3D 3 years ago.
At that time there were many bugs, rendering issues, no sound, and overall quite a few people were sending post betting their mother's life 'j3d would die'. I was scared ...
3 years after (today 2008) java3D has never been so good from my personnal point of vew :
- stable API (no bugs )
- fast rendering
- Sound
- Opened

Do not be scared. Be confident : There are clound, sometimesit rains, but we all know spring and Sun is coming. Easy. ;)

-------------------
Sun' java3D team is apparently reengeneering it to improve it see post from kcr. This is not such a bad idea : build a new 3D java client based API that grounds of the good technical aspect of java3D. And improve others. But apparently it is made [marketed ?] for javaFx ...
-------------------

[b]Personal Wish [/b]:
I have a personal wish for next things to come for java3D or java3D+++ future API:
- Based on a few (very small) test I made around javaFx and based on [u]my needs[/u] as "[b]saas[/b]" (software as a service... Applet++) programmer, I wish there was also a [u]realease not linked to javaFx[/u].

- Why ? I might love javaFx as a way to improve my productivity on Swing/client ihm. But Because the start up time of one applet is crucial and I am [u]scared javaFx might increase the start up time issue[/u].
Or let's make it different : I just wish my programs/Applets with java3D start in 0.5 seconds. Crucial to me. With jre 6update N coming and with quicker hardware it seems we are almost there ! Big improvement!
My concern is that javaFx will cap/ lower those huge improvements I need ( and any future SaaS developer needs).
Therefore I wish any 3D API of Sun's team can also be programmed [u]also [/u]without javaFx.

Thierry

aces
Offline
Joined: 2003-07-17

I´d like to put some points of view, as Java3D developer and also as C++/DirectX [i]quasi-[/i]developer.

Most of reputation of DirectX as "good" API comes from amazing demo applications like 3DMark. But it is double-edged sword. In one side it has amazing capabilities, and in other side a pretty hard work for development, not to mention C++ pointers and issues, Visual Studio 6.0/2003/2005/2008 ties, bi-monthly(!!!!) SDK releases, bringing new bugs , the well know uncompromise with backwards compatibility, and so on.
And I talking about DirectX 9.0, out there since Dec/2002, not mention DX8, DX10 (already outdated, hahahaha), DX10.1, etc.

So as much I know DirectX, more I like Java3D. ;)

---------------------------------

Future, and present, are Shaders . DX10 drop down the fixed pipeline, OpenGL ES 2.0 does the same, and OpenGL 3.0 probably will do. To me, this means that we, 3D developers from fixed pipeline school, must rethink how to program 3D in this new paradigm.

Java3D does support it, did you already try it ?

----------------------------------

A great, great, feature which Java3D has is the multi thread capability. This is overlooked by many people, and it is very important now, with double and quad cores processors on mainstream.
All others APIs out there complains about the "new challenge" : programming for multi thread / multi core. Man, I'm doing it for years, don't you ?

---------------------------------

My wish list for Java3D below. As it is open source, it is up to us to develop it towards our needs :

- Plugable renderer - This can help development for others APIs as DirectX 10.1, OGRE, software rendering, etc.

- More utility classes - to simplify some tasks as camera management, bounds and position detection, just to mention recent requests in this forum. Of course this can be, and should be, done *outside* Java3D classpath. That why we have a incubator sub-project on Java3D.

- More cool demos - That is the kind thing which convince clients. Moving images tells more than 1,000,000 words.

stylertim
Offline
Joined: 2006-05-04

What could be interesting for us is if the new 3D API used with JavaFX will be available as a stand-alone module. Or isn't this intended? It's been a bite since I last read the first posts, so maybe I missed something.

- Thomas

weiland
Offline
Joined: 2005-08-05

Hi Kevin,

Somehow, I had missed your original post, but it brings up a lot of interesting issues:

[what's wrong with Java 3D]
> 1) Size & complexity
Amen!
> 2) Interoperability with Swing and with the 2D scene
> graph (including the animation timing framework)
Interesting, I've spent some effort working around the fact that animations are tied to the real-time clock, instead of my own simulation clock
...
> Java 3D anyway. The view model is cumbersome and
> difficult to use / understand. ... Plus the current Java 3D
> rendering system is in need of a major overhaul.
> Additionally, the current API is not easily
> extensible.
All correct (esp the part about view model).
...
> -- Kevin

Now, many of us here could point out issues with current Java 3D and ideas about great new functionality/approaches. The distressing thing (apart from potentially orphaning Java3D) is that JavaFX thinking isn't being done out in the open AFAICT - I think you'll miss the opportunity to develop something dramatically better. Is there a open forum/process where the design is being developed with at least some community involvement?

Here is a list of stuff in random order, at least some of which I hope you guys are thinking about:
- LOD/dynamism - how many times have people requested the ability to check whether something is going to be culled - the ability to introspect and/or be notified when things move in and out of view.
- Mesh construction - either you load files from 3d tools (.3ds, etc. - poorly supported), or you construct them programmatically (and that is very common and desirable, but probably harder than it needs to be). Much higher level facilities for constructing meshes, so you don't have to worry about how to get good performance out of it (you eventually figure out that you should always use BY_REF, tri-strips, maybe indexed UCIO, but we don't really know why). Dynamic updating is also common. It would be cool if you'd support CSG.
- How about considering that fixed-function 3d cards are becoming obsolete - maybe design around vertex/fragment programs upfront? Pre-defined shaders to do better lighting? Vertex shaders to do polygon smoothing or subdivision surfaces; nurbs?
- Just in time applied to scenegraph compilation
- Provide hooks to low-level rendering (e.g., OpenGL)

- Crazy ideas:
- Define surfaces that can be rendered automatically from 2d sources or 3d sources as needed, depending on LOD (e.g., a Java 2D surface gets drawn into a texture applied to a 3d object - that texture gets re-rendered at higher res as I get closer).
- Let me specify bindings for things (like transforms, colors, vertex coordinates) so that as the app updates a Model, the bound "stuff" gets updated by the scenegraph instead of the app. Picture the use of this for skeletal animation or dynamic visualizations (the bars in the 3d histogram are getting moved by updating data in a model, instead of "manually" propagated)
- Provide hooks to different kinds of renderers (e.g., raytrace the scenegraph)

Where can this be discussed further?

Bill

aces
Offline
Joined: 2003-07-17

I agree with several points exposed, but not all ..

>.NET seems to be ...

Dot Net owner has a long tradition of not being fair with developers.
They (ms) can throw dot Net in trashcan anytime, and it wouldn't surprise a lot of people.
Also they (ms) are not concerned about importance of applications for web, as webstart or applets. "Software is to be distributed in DVDs or Blue-Ray discs" :lol ...

JavaFX is natural upgrade for Java technology, so Java3D must go for it. ;)
I can`t wait to have Java3D version of JavaFXPad . :D

cowwoc
Offline
Joined: 2003-08-24

> I made a spooky dream last night:
> -- First I dreamed Sun management smart guys could
> just understand that the java jre client is killing
> java experience ( too fat, too slow to start to
> XXXXX@:!!! to recognise client machine, to boring to
> install) If only they could just get this then maybe
> they would perhaps work overnight to FAST(er) release
> java 6 Update N. Not in July or Angust 2008. Just
> release it now before you lose all developers
> confidence.

If there was one thing I learned about Sun in the past couple of years it was not to rush them. Be happy (as I am) that they are committed to improving the client-side experience and be happy that they have committed a long stretch of time to get all the important improvements in. By pressuring Sun to get it out the door sooner you are not going to get the same client sooner, but rather you are forcing Sun to cut features and release *that* sooner.

I'd rather see Sun do this right the first time around, because history has shown that it will be difficult to convince them to keep on working on client-side improvements once this release is out. In the past Sun's focus kept on shifting from one domain to another (probably with good reason) because once they satisfied 90% in one domain they moved on to another one. I personally hope that they commit to improving the client-side experience at the rate they've been doing with Update N past its release. In my opinion they are doing an excellent job so far!

In any case, if you care about the client-side experience I encourage you to help them by testing Update N releases and pressuring them to commit to even more client-side enhancements in the future :)

tmilard
Offline
Joined: 2004-03-25

Hello again java3d team.
On my last mail I told you the feelings I had about java3d comitment to javaFx : myopic-belief-in-javaFx-sucess .... while so many small stuffs is just awfully needed to keep people happy on java-java3d-orAnyApi java platform.

How odd it might be for managers of Sun : The success of javaFx itself depends surelly 10 times more on the [b]install-startup-jvm-on-client issue[/b] then on the fact that there is a java3d gateway on javaFx scripts.

-----------------
I will tell you my n°1 whishes for the java3D (as a software concrete user of java3D):

- A) [u]Good, bravo [/u]
I like java3D programing. Ok, I do not come from 3D business so java3d is for me a not-so-hard way to make 3D. I had no alternativ to C++.I am satisfied when I run it on my local machine. Fast, no bugs. Even swing-java3D problems and sound seems to be a issue of the past.

- B) [u]java3d is a client API. Damned[/u] !
The only criticise is not a technical one. It is a social one : java3d would benefit mostly by gaining audience. Why ? Because the more people the more tools/specialized API aroud it. Import 3d object API, 3D sound API is OK. But it is just a start. More people is better. But once again, this popular need around java3d is 98% linked to [b]install-startup-jvm-on-client issue[/b]

- C) [b]Need improve for DirectX-OpenGl-XP-Vista-Apple [/b]java3D deployment
I would love to be able to make my java3d program work fine and easely on Microsoft XP and Vista and Apple Mac. I know the OpenGl and DirectX neverending story. I do not blame java3d team. But If just the java3D API could do the maximum to ease the deployement process and prevent us fromhaving bad surprises. For people like me who do not come from C++ business and try to have a web service (ie it works on 98% of machines). Talk of headache ...

Let's resume once again my feeling :
java3D plans is uselless. Why because its future along allk java client API (Swing, javaFx, ....) depends only on the [b]install-startup-jvm-on-client issue[/b] .

Ps: I am still positive because 4 years ago Flash platform (also a client platform) was also very low. Many feared it would not be part of the future. Small improvments nested Youtube and hundreds of web services. Hope java Sun people manager can see that.

Thierry

bheffner75
Offline
Joined: 2005-05-19

It is regrettable that Sun has opted to put a hold on Java3d advancement. Unfortunately, our project cannot be put on hold because of a vendor's business decisions. We will probably abandon Java3D as a sustainable graphics API in favor of a direct OpenGL implementation.

With technology, you either move forward or the competition overtakes you. There are other alternatives out there that are continuing to move forward. My opinion is that businesses will increasingly put Java3D on the shelf in favor of more supportable options.

Tom Rink

Hi,

java3d-interest@javadesktop.org wrote:

>It is regrettable that Sun has opted to put a hold on Java3d advancement. Unfortunately, our project cannot be put on hold because of a vendor's business decisions. We will probably abandon Java3D as a sustainable graphics API in favor of a direct OpenGL implementation.
>
>With technology, you either move forward or the competition overtakes you. There are other alternatives out there that are continuing to move forward. My opinion is that businesses will increasingly put Java3D on the shelf in favor of more supportable options.
>
>
What are some of the alternatives?

>[Message sent by forum member 'bheffner75' (bheffner75)]
>
>http://forums.java.net/jive/thread.jspa?messageID=263586
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
>For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

bheffner75
Offline
Joined: 2005-05-19

There a several alternative scene graphs, depending upon your product's business focus:

Aviatrix3d is designed for the visualization industry
Xith3d is designed for the gaming industry

For Java. In C-land, there is Open Scene Graph, and others.

I have been working with Java3d for 4 years now. It has some very good features (the scene graph is fantastic), and some not so good features (relatively slow performance, poor Swing integration, no access to the low-level graphics API). I chose Java3d initially because of cost and a quick time-to-market. Java3d has remained with our project because the cost/benefit of replacing it has been prohibitive (considerable rework of the code base).

Having said that, the news that advancement of Java3d is put on hold tilts the cost/benefit analysis. Combined with previously stated issues, the benefit of replacing it with another solution now outweighs the investment cost. We will probably use native OpenGL because it allows us tight control over every aspect of the rendering process and we can write a customized pipeline that is tailored to our product's needs. It also frees us from a third-party vendor and improves supportability.

It's not that Java3d is a bad product--I have championed it for a while now. It's just that it is no longer the best option for our product. It's just like Sun deciding to focus in JavaFX. JavaFX is a better business alternative from a profit perspective than Java3d, hence the shift in focus. When it comes down to brass tacks, it's about delivering the best product in order to maximize revenue. We will continue to monitor Java3d, but is is unlikely that we will transition back to it unless something earth-shattering takes place.

mcneillk
Offline
Joined: 2005-02-03

Reading about "working on a new 3D scene graph", the big question is... WHY?

Reading the various replies, I think the development community would be more understanding of this announcement if there were a TECHNICAL or STRATEGIC ARGUMENT presented to explain WHY this decision was made, and WHY Java3D cannot fulfill the requirements for JavaFX.

Any chance of obtaining such information?

kcr
Offline
Joined: 2004-03-17

The main reasons that we aren't just using Java 3D for the 3D scene graph for JavaFX are:

1) Size & complexity

2) Interoperability with Swing and with the 2D scene graph (including the animation timing framework)

The changes needed to render directly into a swing buffer would have broken compatibility with existing Java 3D anyway. The view model is cumbersome and difficult to use / understand. The behavior system uses a different model from the animation timing framework that JavaFX uses. Plus the current Java 3D rendering system is in need of a major overhaul. Additionally, the current API is not easily extensible.

We could have kept the Node hierarchy itself from Java 3D (maybe subsetting it for the smaller footprint that we need), but that still wouldn't have solved some of the concerns over extensibility.

-- Kevin

tmilard
Offline
Joined: 2004-03-25

> The main reasons that we aren't just using Java 3D
> for the 3D scene graph for JavaFX are:
>
> 1) Size & complexity
> 2) Interoperability with Swing and with the 2D scene
> graph (including the animation timing framework)
to render directly into a swing
> 3) buffer would have broken compatibility with existing
> Java 3D anyway.
4) The current Java 3D rendering system is in need of a major overhaul.
> Additionally, the current API is not easily extensible.

----> Maybe one BIG "improved java3D version" with a break in compability would be better for us then to fork java3d with a second API. If I get what that was said earlier...

Personnally I prefer a java3D new version with lots of new things rather than a "sleeping project". A dormant project is worth much less for me then a risquy new version witch breaks comptability.
I do imagine with ease that some choice that were made few years ago for java3D API should be reconsidered today. Let's do it now. Do not be afraid of compatibility break.
Do not forget that some small developers, we have bet a bit of our fortune on java3D API.

Thierry

interactivemesh
Offline
Joined: 2006-06-07

Hi,

searching for concrete (non marketing) information about JavaFX and 3D results in:

[b]FAQ: Why did you create another scripting language ?[/b]

JavaFX Script is specifically designed to optimize the creative process of building rich and compelling UIs leveraging Java Swing, Java 2D, and [b]Java 3D[/b] for developers and content authors.

(http://java.sun.com/javafx/script/)

[b]What are the consequences for Java 3D really ? [/b]

- Is Java 3D definitely out of the game or will it be somewhere secretly under the surface of JavaFX?

[b]What's wrong with Java 3D ?
[/b]
- Just telling us the bad news "improvements are on hold at this time" is neither sufficient nor adequate for this committed and competent Java 3D community!

[b]What are we going to tell our customers?[/b]

- 'Wait and see!' ?

August

paulby
Offline
Joined: 2003-06-13

For those concerned with how this affects the Wonderland project please refer to this thread http://forums.java.net/jive/thread.jspa?threadID=35979&tstart=0

Rgds

Paul

suhail
Offline
Joined: 2003-06-12

Hi

I am disappointed to be honest with your having said "our plans for improvements to the Java 3D API are on hold at this time". It stems from the fact that its not clear what "hold at this time" means in the long run. Pausing something should mean that there is a possibility to start things up again. However, given your statements about JavaFX, I do not see how. My deeper anxiety stems from the fact that https://lg3d-wonderland.dev.java.net/ may suffer. Wonderland is surely one of the most compelling use of Java3D and it shows so much potential. Sun may have identified 3D as one area where Flex and Silverlight may be weak but if you really think about it, JavaFX and Java on the desktop is generally poor when it comes to Video. Therefore I would argue for resources be expended in that area instead of taking something that has been improving and which has adequate support with respect to JavaFX, that you concentrate on improving Video support for JavaFX. Do you know how simple it is to do do Video Chat with Flash/Flex? Can you even imagine what it would mean to have full support for the SIP protocol with JavaFX? Please stop nitpicking the Java API for all the really cool stuff please and do the right thing.

Kind regards
su./hail

mlouka
Offline
Joined: 2004-06-27

I've been wondering about this too as the Wonderland web pages have quite a detailed roadmap with a 1.0 release slated for January 2009 and comments on future features beyond that.

I'm sorry, but based on past experience waiting for initially promising Sun technologies to mature, only to see them dropped or placed in limbo (Java 3D, JMF, JSDT...), I've got no confidence in JavaFX, or patience to wait to see how it evolves as a 3D platform.

ofh
Offline
Joined: 2003-06-10

Hi Java Team,

I welcome your idea very much.

Thanks!

samkass
Offline
Joined: 2004-09-22

There seems to be a trend lately to replace largely functional and powerful toolkits on Java (JMF, Java3D, etc) with underpowered "casual" versions under the "desktop" mantra.

To me, "desktop" means having a GUI toolkit with:
1. Ability to render HTML-- it boggles my mind that Swing has no lightweight HTML rendering capability, nor ability to embed heavyweight until JDK 7.
2. Ability to play, stream, edit multimedia
3. Ability to easily integrate with the OS'es systems-- logs, environment variables, existing install/uninstall, etc.
4. Snappiness
5. Ability to layer and embed "heavyweight" components
6. A license that lets commercial entities participate

(I can't even LOOK at the scenegraph stuff yet because it's all in a commercially-hostile GPL license. Since my company also has an internally-developed Jazz/Piccolo-based scenegraph codebase, I have to advise everyone to avoid the Sun one until their license is such that we won't get sued if we happen to implement something similarly. I would love nothing more than to unify my company's scenegraph with the official one, contributing our developments to fill any gaps and adopting it to replace ours.)

In summary, I hear a lot of noise about desktop but most of it looks somewhat ineffective so far, and I don't know whether to suspect that Sun just fundamentally doesn't understand the desktop.

samkass
Offline
Joined: 2004-09-22

Heh... got distracted from my list talking about licensing... one other big one for "desktop" uses...
7. Have a rich lightweight text editor component that can receive copy/pastes from MS Word, among others. (You can drop the "lightweight" requirements if the heavy/light mixing gets backported to JDK 6uN)
7a. If 7 is going to be based on the current infrastructure, make the HTML and RTF editor kit classes subclass-friendly.

aberrant
Offline
Joined: 2006-02-02

JavaFXScript with 3D support sounds great. One of the nice things about the 2D Scenario scene graph is that it's available as a stand alone jar. I use it with just plain Java and it works well for bleeding edge software. Will the new scene graph be JavaFXScript only? Also why two separate graphs? Isn't 2D just a special case of 3D? What is it about the current Java3D scene graph that is so incompatible with JFX that you have to start over?

Thanks,

Collin

aces
Offline
Joined: 2003-07-17

Hi

If it opens path for Java 3D on JavaFX, it´s a good news to me. ;)

Rich Rein

Hi,
How are the graphic environment dependencies going to be resolved?

Graphic HW/SW compatibility/configuration seems to be a significant part
of the java3d interest group discussion.
I think this marriage would be fantastic as long as there are no nasty platform surprises.

Rich

> -----Original Message-----
> From: java3d-interest@javadesktop.org
> [mailto:java3d-interest@javadesktop.org]
> Sent: Wednesday, January 30, 2008 3:27 AM
> To: interest@java3d.dev.java.net
> Subject: Re: ANNOUNCEMENT: Java 3D plans
>
> Hi
>
> If it opens path for Java 3D on JavaFX, it´s a good news to
> me. ;) [Message sent by forum member 'aces' (aces)]
>
> http://forums.java.net/jive/thread.jspa?messageID=256539
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
> For additional commands, e-mail: interest-help@java3d.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

surikov
Offline
Joined: 2007-05-26

how to use Java3D in JavaFx
http://molgav.nn.ru/index.php?option=com_content&view=article&catid=34:e...

my tutorial

English version coming soon

surikov
Offline
Joined: 2007-05-26
tmilard
Offline
Joined: 2004-03-25

..... Hello java3D team
Nice to hear from you.

I made a spooky dream last night:
-- First I dreamed Sun management smart guys could just understand that the java jre client is killing java experience ( too fat, too slow to start to XXXXX@:!!! to recognise client machine, to boring to install) If only they could just get this then maybe they would perhaps work overnight to FAST(er) release java 6 Update N. Not in July or Angust 2008. Just release it now before you lose all developers confidence.

-- I also day-dreamed yesterday and it bumped my head : " Why Sun engeneers always want to chalenge future when it is easier and less risky to just improve present (ie.existing java piece of art). I mean by that that Ok javaFx might be a piece of need for us developers. By wow : how can you be so sure of that ! My grandmother always tells me this thing : Do not put all your eggs in the same basket. Sometimes I wonder if javaFx is not like in france we say "Le miroir aux alouettes".

Fot the rest I say : Yes I like java3D. Maybe I will love javaFx.
Just to idiotic for all these API to be standing on such a sandy growd : the (bad) java/jre install and execution.
Thierry

""who has had life to If I were cautoius I would say That per (once Once they The
f Sun could understand that UJnderstood.
Maybe If Sun

stylertim
Offline
Joined: 2006-05-04

Hey Kevin!

It might be quite presumptous for a student of computer science like me to complain about development efforts at Sun. Still I have to agree with Thierry in some way and I'd like to add some thoughts.

As far as I'm informed JavaFX could be considered a direct competitor for MS Silverlight and Adobe Flash/Flex. Correct? The thing is, these product, especially Flash, are already widely used and established and although it seems to make sense for Java to introduce a comparable product it doesn't make sense to put already available and well working products on the sidelines, especially after annoucing a major release for Java3D with a bunch of pretty neat features a few months ago (Java 3D 1.6/2.0). The "sandy ground", as Thierry called it, should not be loosened further by halting the work on the API. I guess all of us were so looking forward to the things to come. :(

Another, IMHO, true statement Thierry made concerns performance. The Java platform keeps growing and growing all the time but desktop performance still doesn't seem to be a major concern, although the improvements are obvious with every succeeding JDK. Sure, there are high-performance situations Java is used in, but the Desktop does not belong to these.

As a guy who loves Java it pains me to say that for most applications, if you want to stay with a complete framework, .NET seems to be a better alternative and with the ongoing development of Mono Java's platform-indepence advantage keeps vanishing from day to day. I remember a quite objective statement in a book on Visual C# where the author honors the innovation Java offered when it started to grow but at the same time he
states that .NET has raised the bar considerably and it is likely impossible for Java to reach in the future. This scenario isn't pleasant - still, there is some truth to it. From what I experienced up until now, many of the desktop capabilities of Java already seem to be outranked by those provided by .NET, and I'm not even speaking of the overall performance.

Don't get me wrong, I still love Java and enjoy working with it and I definitely will use it in the future but I hope you guys at Sun, who I really adore for the whole work put into Java so far, don't get of the track and forget about the desktop - for what really might happen, to quote Thierry again, you could lose a lot of developer confidence.

To get back to Java3D, maybe there's some other way to keep improving the API and still be able to enhance the JavaFX thingy. I think we shouldn't waste the potential resting in J3D. I hope I didn't put my thoughts all wrong...

- Thomas

linuxhippy
Offline
Joined: 2004-01-07

> .NET seems to be a better alternative and with the ongoing
> development of Mono Java's platform-indepence advantage
> keeps vanishing from day to day

Have you ever seriously used mono for desktop applications? I guess not and you just write what you believe.
Mono is far from beeing ready for prime-time, and considering the amount of man-power and money Sun and MS put into their frameworks compared to Novel its no wonder at all.

Mono is great for low-hit asp sites and some small gnome-applications. By the way ikvm is able to compile eclipse to (quite good) CLR. Try running it, and you'll understand what I am talking about.

After all what are all your concerns?
What I read was:

1.) Java has to be installed:
Yes, thats true and good. Applets/webstart would be dead if everybody would compile his/her apps to native code and platform indipendence would suffer a lot.

2.) Java is slow:
Really? Where? Have you tried jdk6_u10?
Its slowness is to some degree part of the language design - but anyway - .NET is not different here.

3.) Java has weak platform integration:
WoooW. wow. yes!
By the way ... who wonders. I write java-code and it runs anywhere. Where does Windows.Forms code run?
Considering GTK# as cross-platform is no option, its a joke.

lg Clemens

Message was edited by: linuxhippy

stylertim
Offline
Joined: 2006-05-04

I'm not sure If you were responding only to me or Thierry as well (because I didn't mention installation concerns) but:

> After all what are all your concerns?

Clemens, I welcome criticism but my post only was a collection of thoughts on the announcement which involved some feelings about Java 3D being put on hold and some things on Java and desktop integration, and thus not supposed to be torn apart like that but to be taken as input. Looking at what aces wrote I feel myself and my thoughts confirmed to some extent. Nonetheless I'd like to reply.

> I guess not and you just write what you believe.

Yes, I really do write what I believe. I believe that Mono really is at the beginning of its development, speaking of 1.2.6, and I also believe that in time it surely will get a lot more versatile. And if you read my statement with a little more emotional distance you'd have taken the words "[..]keeps vanishing from day to day." a little more seriously. I didn't say the cross-platform advantage is gone already - still, it's not that unlikely to happen some day, at least for a wide range of applications.

I'm a strong defender of the oppinion that Java isn't slow per se. And again, if you read my words correctly, you'd have seen I didn't fail to honor the constant improvements. All I was saying was it would be quite desirable if it was comparable to .NET. And I guess you're not seriously going to doubt .NET's performance advantage for it is quite real.

The third point is somewhat unclear to me. Either it is because I lost the ability to read correctly over night or the ability to interpret statements but what I read on the official mono webpage a few minutes ago was:

"Support for Winforms 1.1 has been completed and was released in Mono 1.2"

Sure, that's not the currently available version but it works with Mono on many platforms. By the way, with Mono constantly improving and supporting WinForms 2.0 in the future, point 3) will become obsolete. To be fair, WinForms on Mono will likely be a little slower due to a lightweight implementation concept.

I thought I was careful enough to avoid appearing offensive. Seems I wasn't...

- Thomas

P.S.: A little personal note to my compatriot concerning "WoooW. wow. yes!":

Clemens, find' ich nicht in Ordnung, dass du dich in einer seriösen und durchaus konstruktiven Diskussion, auf ein so unsachliches Niveau herablässt. Ich hoffe du vermeidest solchen Unsinn in Zukunft...

linuxhippy
Offline
Joined: 2004-01-07

> All I was saying was it would
> be quite desirable if it was comparable to .NET. And
> I guess you're not seriously going to doubt .NET's
> performance advantage for it is quite real.

Yes, thats exactly what I was saying - Java is as fast or faster than .NET.
The Hotspot-JIT generates better code than .NET's, there are plenty of GC algorythms to choose and the whole thing scales really well to _large_ machines.
One concern I have is Java's its class-loading performance, cold-start (and warm-start even before) performance are currently adressed in jdk6_u10 - another is that Swing sometimes is a little bit less responsive than Win32 (but faster than GTK2 for example).

> "Support for Winforms 1.1 has been completed and was
> released in Mono 1.2"
Yes of course, the code is there - but it feels a lot like Wine.
Have you tried some Winforms apps under mono - they are slow, look strange, and often don't work - which I don't think is Mono's fault, its just that they have been developed for .NET and not Mono.

> To be fair, WinForms on Mono will likely be
> a little slower due to a lightweight implementation
> concept.
Not necessarily.

> P.S.: A little personal note to my compatriot
> concerning "WoooW. wow. yes!":
That was not personal. It was just my way of saying "hey I am tired of the continuous bullying of java".
I am tired of hearing the same complaints ever and ever again - the code is open so why don't sit those people down and write some code instead of wasting hours destroying java's reputation.

> Clemens, find' ich nicht in Ordnung, dass du dich in
> einer seriösen und durchaus konstruktiven Diskussion,
> auf ein so unsachliches Niveau herablässt. Ich hoffe
> du vermeidest solchen Unsinn in Zukunft...
This thread was about Java3d and has been hijacked to just another sun-does-everything-wrong thread, so the discussion was not really objective anyway.

I hear these complaints now over a decade and guess what - Java is still here and healthier than ever before.
I've heard that VB will kill Java, that .NET will kill java, that AJAX will kill java and whatever. Factis that there is more Java code written today than anytime before.
And compared to the days when Java was "ready" the first time for larger apps (1998, 1.2.x) it now really feels good and works reliable.

lg Clemens