From: Ola S. <ola...@lc...> - 2004-05-12 09:33:42
|
Hello, My group is investigating the possible use of CDK as framework/basis for constructing an integrated bio/chemoinformatics enterprise application. I have installed the CDK library and have a few newbie-questions that I hope someone might answer. We have also been looking at the commercial application Jchem (because of the good database support, descriptor analysis and 2D-visualization) but would of course prefer CDK! 1) We would like to read SMILES and convert to 2D-structure. What are the options after using the SmilesParser? Which algorithms should I use? StructureDiagramGenerator gives me something to visualize in Jmol but the bonds are incorrect. 2) Can CDK output images (GIF/PNG etc) of 2D-structure of a molecule? If not, how do people address this matter with external programs (like JchemPaint)? We would like to put the 2D structures on the web, not in a java-panel. 3) Are there any algorithms for converting 1D/2D structures to putative 3D (or just 3D)? Any energy minimizing modules? 4) How extensive is the database support? Can CDK only store/retrieve molecules from a database? It would be nice with for example Hibernate support... All help very appreciated! Regards, .../Ola Spjuth ola...@lc... The Linnaues Centre for Bioinformatics, Uppsala University, Sweden |
From: Peter Murray-R. <pm...@ca...> - 2004-05-13 17:29:10
|
At 11:33 12/05/2004 +0200, Ola Spjuth wrote: >Hello, I'll try to help with some of the Q... >My group is investigating the possible use of CDK as framework/basis for >constructing an integrated bio/chemoinformatics enterprise application. >I have installed the CDK library and have a few newbie-questions that I >hope someone might answer. We have also been looking at the commercial >application Jchem (because of the good database support, descriptor >analysis and 2D-visualization) but would of course prefer CDK! > >1) We would like to read SMILES and convert to 2D-structure. What are >the options after using the SmilesParser? Which algorithms should I use? >StructureDiagramGenerator gives me something to visualize in Jmol but >the bonds are incorrect. >2) Can CDK output images (GIF/PNG etc) of 2D-structure of a molecule? If >not, how do people address this matter with external programs (like >JchemPaint)? We would like to put the 2D structures on the web, not in a >java-panel. We use CDK to generate 2_D coordinates and create output in CML. CML holds these coordinates which can then be transformed to SVG (scalable vector graphics in XML). Alternatively you may be able to export SVG from JChemPaint. SVG can then be converted to a range of other formats (PDF, etc.) with tools such as FOP from Apache. SVG means that the diagrams are rescalable and even editable (e.g fonts and colours can be changed). >3) Are there any algorithms for converting 1D/2D structures to putative >3D (or just 3D)? Any energy minimizing modules? > >4) How extensive is the database support? Can CDK only store/retrieve >molecules from a database? It would be nice with for example Hibernate >support... CDK (or JChempaint) has been used to interface with our XML repository using Apache Xindice. The molecules are very rapidly retrieved by exact search using the new IUPAC/NIST identifier (INChI). See http://wwmm.ch.cam.ac.uk/Bob for a demo We currently see CDK as the primary engine for adding 2D coords and bond orders to our data. Egon can tell you more about thoughts on 1-D to 3D and forcefields, etc. - this is an important target. HTH P. >All help very appreciated! > >Regards, > > .../Ola Spjuth > >ola...@lc... >The Linnaues Centre for Bioinformatics, Uppsala University, Sweden > > > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by Sleepycat Software >Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to >deliver higher performing products faster, at low TCO. >http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 >_______________________________________________ >Cdk-devel mailing list >Cdk...@li... >https://lists.sourceforge.net/lists/listinfo/cdk-devel Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Miguel <mi...@jm...> - 2004-05-20 16:54:54
|
> Thanks for your answers. Here is my simple benzene 2D file, it was > constructed with CDK in the following way: [snip] > Wouldn't it be easy to convert 2D to 3D when importing (x3=x2, y3=y2, > z3=0)? That way Jmol would support 2D as well... Yes, but a CML file can have both 2D and 3D coordinates in the file. So we need to pick up the 2D formats only if the 3D coordinates are not present. We are using an XML parser that makes a single pass through the file. I think we need to do the following: - if we see 2D coordinates and have not seen 3D coordinates, then read the 2D coordinates - if we see 3D coordinates and have already read 2D coordinates, then throw away the 2D coordinates. We just need to think this through. > Another question, why is the bond 1.5? Is that the aromatic bond in a > cml-file? I don't know, but your theory makes sense to me. Miguel |
From: Peter Murray-R. <pm...@ca...> - 2004-05-20 18:36:11
|
At 18:54 20/05/2004 +0200, Miguel wrote: > > Thanks for your answers. Here is my simple benzene 2D file, it was > > constructed with CDK in the following way: >[snip] > > Wouldn't it be easy to convert 2D to 3D when importing (x3=x2, y3=y2, > > z3=0)? That way Jmol would support 2D as well... >Yes, but a CML file can have both 2D and 3D coordinates in the file. So we >need to pick up the 2D formats only if the 3D coordinates are not present. I don't think Jmol can usefully display the 2D coordinates. They are schematic chemical diagrams ("on paper") and must not be displayed in 3D - they must never be rotated! Otherwise it gives the impression that molecules are flat when the are not. >We are using an XML parser that makes a single pass through the file. > >I think we need to do the following: > >- if we see 2D coordinates and have not seen 3D coordinates, then read the >2D coordinates They can only be used on a 2D display like JChempaint. It would be useful to send 2DEvents to JChempaint if/when Jmol and JChempaint talk to each other. >- if we see 3D coordinates and have already read 2D coordinates, then >throw away the 2D coordinates. > >We just need to think this through. I suggest that at present Jmol throws away 2D coordinates as soon as it sees them! P. > Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Peter Murray-R. <pm...@ca...> - 2004-05-16 10:12:39
|
I am considering moving some of my code to use vecmath for 3-D geometry. I would like access to the definitive javadoc (and perhaps the source) and need to know that these are compatible with the jar distributed in CDK. (The CDK version number is vecmath1.2-1.14.jar and it appears to be ca 2 years old on CVS.) There are some general and specific questions for CDK: general. If CDK uses a package and the supplier changes the public version there is a potential incompatibility. (This is common with xerces, etc.!) It would be useful if CDK can make it clear on the website that the version included in the distrib is not the same as the latest on the site. (Note that many of the CDK jars do not have version numbers). Yes, I know this is difficult! If Java changes the version then there is a possibility that different version could be loaded from the JDK/JRE. I'm assuming that Java does not load a different javax/vecmath at present but conceivably it might in the future. If an OpenSource supplier disappears it may be difficult to find the source and the documentation to the package. With later versions of the Java OS/libraries it may even happen that the jar stops working or functions differently (e.g. methods become deprecated). It is then important to be able to recompile the code and javadocs. I would certainly find it difficult to find the definitive version of source for many of the jars in CDK. Therefore I think CDK should have some method of protecting itself. These would include: - links to the supplier's actual version of jar used - copying the source to the CDK site. vecmath There seem to be different versions of vecmath on the web. In the past I was worried about its stability - can I stop worrying? When I search for vecmath on java.sun.com there doesn't seem to be anything later than 1.3.1 (but I am not good at searching this site). The javadoc there seems to have the same classes as those in CDK jar (which has an extra VecmathTest class), but I haven't checked all the signatures. I assume that vecmath is normally distributed with java3d (which none of us uses, I think). Is it likely to become part of the JRE? Is CDK committed to the use of vecmath? If so I shall look into converting my code where appropriate and will recommend its use in the interfaces where 3D geometry is used. P. >Peter Murray-Rust >Unilever Centre for Molecular Informatics >Chemistry Department, Cambridge University >Lensfield Road, CAMBRIDGE, CB2 1EW, UK >Tel: +44-1223-763069 > > > >------------------------------------------------------- >This SF.Net email is sponsored by: SourceForge.net Broadband >Sign-up now for SourceForge Broadband and get the fastest >6.0/768 connection for only $19.95/mo for the first 3 months! >http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click >_______________________________________________ >Cdk-devel mailing list >Cdk...@li... >https://lists.sourceforge.net/lists/listinfo/cdk-devel Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Miguel <mi...@jm...> - 2004-05-16 11:16:03
|
Peter, The vecmath package is used in Jmol, so I share some of your concerns. I can answer some of your questions (and hopefully ally some of your concerns) for this particular package. > I am considering moving some of my code to use vecmath > for 3-D geometry. I would like access to the definitive > javadoc (and perhaps the source) and need to know that > these are compatible with the jar distributed in CDK. I looked into this about a year ago. I was uncomfortable using the .jar unless I knew where it came from. The API for javax.vecmath is defined as part of the Sun Java3D product. I always use the javadoc at sun: /http://java.sun.com/products/java-media/3D/ forDevelopers/J3D_1_2_API/j3dapi/index.html > (The CDK version number is vecmath1.2-1.14.jar and it > appears to be ca 2 years old on CVS.) The Java3D API is still at 1.2 ... it has not changed for at least 5 years. (Rumors say that Java3D seems to be completely dead, with no Sun developers working on it ... so there will be no changes in the forseeable future) The vecmath package that we use (vecmath1.2-1.14) is a "free software" implementation of the Java3D API that was written by Kenji Hiranabe in Japan: http://objectclub.esm.co.jp/vecmath/index.html The source code is available ... dated Nov 1999. Some random observations: - I have looked at the source and built it. - It generally looks OK - It is easy to understand - I have *not* gone through it in great detail - I trust that the guy who wrote it knows more vector math than I do. - the .jar that we are using in Jmol is one that I built from the source - I wish that there were less cross-links between the classes I meant to commit the source to the Jmol CVS. But apparently have never done so. Thank you for the reminder ... I will do so right now. > There are some general and specific questions for CDK: > > general. > > If CDK uses a package and the supplier changes the public > version there is a potential incompatibility. (This is > common with xerces, etc.!) It would be useful if CDK can > make it clear on the website that the version included > in the distrib is not the same as the latest on the site. > (Note that many of the CDK jars do not have version > numbers). Yes, I know this is difficult! Indeed ... it will be quite a task ... but for a good cause. > If Java changes the version then there is a possibility > that different version could be loaded from the JDK/JRE. > I'm assuming that Java does not load a different > javax/vecmath at present but conceivably it might in > the future. If someone has Java3D installed, then their virtual machine should probably load the Sun Java3D. I believe that Egon has run this way in the past ... and has not noted any problems. > If an OpenSource supplier disappears it may be difficult > to find the source and the documentation to the package. > With later versions of the Java OS/libraries it may even > happen that the jar stops working or functions differently > (e.g. methods become deprecated). It is then important to > be able to recompile the code and javadocs. > > I would certainly find it difficult to find the definitive > version of source for many of the jars in CDK. > Therefore I think CDK should have some method of protecting > itself. These would include: > - links to the supplier's actual version of jar used > - copying the source to the CDK site. > > vecmath > > There seem to be different versions of vecmath on the web. > In the past I was worried about its stability - can > I stop worrying? I don't think that you need to be worried about the stability: - the API will not change - the implementation has not changed in 4+ years - we have the source code > When I search for vecmath on java.sun.com there doesn't > seem to be anything later than 1.3.1 (but I am not good > at searching this site). The Java3D API has been at version 1.2 for many years. > The javadoc there seems to have the same classes as > those in CDK jar (which has an extra VecmathTest class), > but I haven't checked all the signatures. Nor have I checked all the signatures. But I have exclusively use the Sun javadoc with this implementation for the past 18 months and have not encountered any problems. > I assume that vecmath is normally distributed with java3d (which none of us uses, I think). Is it likely to become part of the JRE? As I said, rumor has it that java3d is completely dead. So, that concerns me a little bit. I wish that Sun *would* include this vecmath package in the standard JRE. I will post a question to Sun asking if they can do so. > Is CDK committed to the use of vecmath? I believe that Jmol is committed to using the vecmath package. > If so I shall look into converting > my code where appropriate and will recommend > its use in the interfaces where 3D geometry is used. I would suggest that you do so. The API was defined by Sun, so I assume that some smart people worked on it. And I think that makes it almost a 'standard'. And I believe that the vecmath implementation we have is stable and robust. Miguel |
From: Peter Murray-R. <pm...@ca...> - 2004-05-16 14:47:29
|
At 13:15 16/05/2004 +0200, Miguel wrote: >Peter, Many thanks, I now feel happy to use vecmath. For those who might be interested I implemented a set of geometry classes (jumbo.euclid) as long ago as Jumbo1 (ca 1996) because there was nothing in the Sun library. It also includes 2-D geometry and general array/matrix tools. There was a lot of overlap with vecmath and many of the signatures are isomorphic. However there are also other 3D primitives such as Line3, Plane3, etc. I think JCP/CDK/Jmol need all and more of this functionality. We need to be able to - carry out any reasonable geometrical operation in 2D. Examples are rotation of object, intersections of lines, etc. *** Is java.awt.geom satisfactory for this (e.g. should we use java.awt.geom.Point2D.Double for 2D points)?*** *** if so, can Point2D be used independently of a graphics canvas? *** - do something similar in 3D. The reasons for this are many: draw objects support 3D geometrical operations and analysis (e.g. calculate torsion angles) construct regions of space with chemical functionality support 3D searches and descriptors - support n*m arrays and matrices. This will be important for the chemoinformatics stuff. <snip/> >Some random observations: > - I have looked at the source and built it. > - It generally looks OK > - It is easy to understand > - I have *not* gone through it in great detail > - I trust that the guy who wrote it knows more > vector math than I do. > - the .jar that we are using in Jmol is one that > I built from the source > - I wish that there were less cross-links between the classes I agree in general. I have also looked at the source and generally agree. I think this is one of the classic areas where there have to be many crosslinks between the classes as the objects are very tightly coupled and none have precedence. For example a Line intersects a Plane to give a Point. >I meant to commit the source to the Jmol CVS. But apparently have never >done so. Thank you for the reminder ... I will do so right now. Thanks <snip/> >I don't think that you need to be worried about the stability: > - the API will not change > - the implementation has not changed in 4+ years > - we have the source code That was my feeling <snip/> > > Is CDK committed to the use of vecmath? > >I believe that Jmol is committed to using the vecmath package. > Good. That will mean we have a good working knowledge of it! As mentioned above there are many places where 3D geometry is required in CDK. I think that all interfaces should use it where possible. > > If so I shall look into converting > > my code where appropriate and will recommend > > its use in the interfaces where 3D geometry is used. > >I would suggest that you do so. I will do so as time permits... >The API was defined by Sun, so I assume that some smart people worked on >it. And I think that makes it almost a 'standard'. > >And I believe that the vecmath implementation we have is stable and robust. P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Peter Murray-R. <pm...@ca...> - 2004-05-16 17:55:07
|
Does CDK contain routines to determine whether a bond is cyclic (i.e. in a ring)? P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Egon W. <eg...@sc...> - 2004-05-20 14:44:23
|
On Sunday 16 May 2004 19:51, Peter Murray-Rust wrote: > Does CDK contain routines to determine whether a bond is cyclic (i.e. in a > ring)? I do not think it does explicitely, but I think you can do the following: - determine all rings, or the smallest subset of rings... - loop over all bonds and see if each of them is in the RingSet or not... Egon |
From: Egon W. <eg...@sc...> - 2004-05-16 18:36:22
|
On Sunday 16 May 2004 13:15, Miguel wrote: > > (The CDK version number is vecmath1.2-1.14.jar and it > > appears to be ca 2 years old on CVS.) > > The Java3D API is still at 1.2 ... it has not changed for at least 5 > years. (Rumors say that Java3D seems to be completely dead, with no Sun > developers working on it ... so there will be no changes in the forseeable > future) > > The vecmath package that we use (vecmath1.2-1.14) is a "free software" > implementation of the Java3D API that was written by Kenji Hiranabe in > Japan: > > http://objectclub.esm.co.jp/vecmath/index.html > > The source code is available ... dated Nov 1999. The version that CDK uses is in CDK cvs: cdk/gcj/vecmath/javax/vecmath It's actually a slightly adapted version, so that it compiled with GCJ... It was just an implementation change, I think... not a API change. Egon |
From: Peter Murray-R. <pm...@ca...> - 2004-05-27 08:10:13
|
If it is known that a given bond is cis or trans (or some other measure of stereochemistry such as CMLBondStereo) is there a means that the layout algorithm can take this into account? P. Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Egon W. <eg...@sc...> - 2004-05-31 14:32:01
|
On Sunday 16 May 2004 17:30, Peter Murray-Rust wrote: > If it is known that a given bond is cis or trans (or some other measure of > stereochemistry such as CMLBondStereo) is there a means that the layout > algorithm can take this into account? AFAIK, not at this moment. Egon |
From: Peter Murray-R. <pm...@ca...> - 2004-05-31 15:53:40
|
At 16:33 31/05/2004 +0200, Egon Willighagen wrote: >On Sunday 16 May 2004 17:30, Peter Murray-Rust wrote: > > If it is known that a given bond is cis or trans (or some other measure of > > stereochemistry such as CMLBondStereo) is there a means that the layout > > algorithm can take this into account? > >AFAIK, not at this moment. I have now solved this in JUMBO in that I can take a CDK layout, find the acyclic double bonds and "flip" about them. The code will be in JUMBO4.4 Of course this will sometimes flip part of a structure on top of itself, but I am prepared to live with this (cis bonds are not likely to be easy to layout anyway). The CDK layout I get is often not as "good" as when I press the clean (broom) button on JCPCDK. Do they use different methods. If so, which should I use? P. >Egon Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: Egon W. <eg...@sc...> - 2004-05-31 18:22:10
|
On Monday 31 May 2004 17:52, Peter Murray-Rust wrote: > At 16:33 31/05/2004 +0200, Egon Willighagen wrote: > >On Sunday 16 May 2004 17:30, Peter Murray-Rust wrote: > > > If it is known that a given bond is cis or trans (or some other measure > > > of stereochemistry such as CMLBondStereo) is there a means that the > > > layout algorithm can take this into account? > > > >AFAIK, not at this moment. > > I have now solved this in JUMBO in that I can take a CDK layout, find the > acyclic double bonds and "flip" about them. The code will be in > JUMBO4.4 Of course this will sometimes flip part of a structure on top of > itself, but I am prepared to live with this (cis bonds are not likely to be > easy to layout anyway). > > The CDK layout I get is often not as "good" as when I press the clean > (broom) button on JCPCDK. Do they use different methods. If so, which > should I use? No don't think so... this is the code from JCP: Point2d centre = GeometryTools.get2DCentreOfMass(molecule); diagramGenerator.setMolecule(molecule); diagramGenerator.generateCoordinates(new Vector2d(0,1)); cleanedMol = diagramGenerator.getMolecule(); Egon |
From: Peter Murray-R. <pm...@ca...> - 2004-06-01 08:14:19
|
At 20:23 31/05/2004 +0200, Egon Willighagen wrote: >On Monday 31 May 2004 17:52, Peter Murray-Rust wrote: > > At 16:33 31/05/2004 +0200, Egon Willighagen wrote: > > >On Sunday 16 May 2004 17:30, Peter Murray-Rust wrote: > > > > If it is known that a given bond is cis or trans (or some other measure > > > > of stereochemistry such as CMLBondStereo) is there a means that the > > > > layout algorithm can take this into account? > > > > > >AFAIK, not at this moment. > > > > I have now solved this in JUMBO in that I can take a CDK layout, find the > > acyclic double bonds and "flip" about them. The code will be in > > JUMBO4.4 Of course this will sometimes flip part of a structure on top of > > itself, but I am prepared to live with this (cis bonds are not likely to be > > easy to layout anyway). > > > > The CDK layout I get is often not as "good" as when I press the clean > > (broom) button on JCPCDK. Do they use different methods. If so, which > > should I use? > >No don't think so... this is the code from JCP: > >Point2d centre = GeometryTools.get2DCentreOfMass(molecule); >diagramGenerator.setMolecule(molecule); >diagramGenerator.generateCoordinates(new Vector2d(0,1)); > >cleanedMol = diagramGenerator.getMolecule(); > JUMBO uses: StructureDiagramGenerator sdg = new StructureDiagramGenerator(cdkMolecule); try { sdg.generateCoordinates(); This seems to be the same tool, so maybe it is a version thing and maybe just stochastic somewhere (if hashtables are used). Anyway I now have tools which read in either: - 2d connection table with bond stereo and wedge/hatch - 3d connection table and generate bond stereo and atom parities This can then be used to add stereochemical annotation to a 2D diagram. It hasn't been exhaustively tested but I'm optimistic that's it's correct. What does CDK do with SMILES input for stereochemistry? is it stored in the CDK molecule? If so I can potentially translate it. P. P. >Egon Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069 |
From: E.L. W. <eg...@sc...> - 2004-06-01 08:18:00
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 01 June 2004 10:13, Peter Murray-Rust wrote: > What does CDK do with SMILES input for stereochemistry? is it stored in t= he > CDK molecule? If so I can potentially translate it. Stereochemistry is currently disregarded. There is no choice made how/where to store atom parities... Will make a=20 proposal right away... Egon =2D --=20 eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFAvDuxd9R8I9Yza6YRAoi+AJsFGRjywuc9hnk1zdpqytJpwW4+AQCdH9yk a0Vznh8rn9E57wflTGEUEwo=3D =3Dm+LJ =2D----END PGP SIGNATURE----- |
From: M.Le_maudit <mle...@us...> - 2004-05-17 07:57:26
|
> On Sunday, May 16, 2004 1:15 PM, Miguel said: > [snip] > As I said, rumor has it that java3d is completely dead. If I remember well, the java3d project as moved to the jogl project (i.e. java opengl project). jopg site: https://jogl.dev.java.net/ I hope this will help you to find answers to you questions. Yours. M. |
From: Miguel <mi...@jm...> - 2004-05-17 08:26:21
|
>> On Sunday, May 16, 2004 1:15 PM, Miguel said: >> [snip] >> As I said, rumor has it that java3d is completely dead. > > If I remember well, the java3d project as moved to the jogl project (i.e. > java opengl project). > > jopg site: https://jogl.dev.java.net/ > > I hope this will help you to find answers to you questions. Thank you for this pointer. My understanding is that jogl is an independent project, that has gained momentum over time. But that there was no official move to jogl by Sun. Interestingly, when looking in the jogl forums I found an announcement by Sun that they plan to open up the Java 3D source code. (see below) This should ensure that the javax.vecmath package will remain available in the future. (I will send a follow-up message to this list.) Miguel ----------------------- From: Doug Twilleager <Doug.Twilleager@SUN.COM> Reply-To: Discussion list for Java 3D API <JAVA3D-INTEREST@JAVA.SUN.COM> To: JAVA3D-INTEREST@JAVA.SUN.COM Subject: [JAVA3D] ANNOUNCEMENT: Java 3D plans Date: Wed, 17 Mar 2004 21:28:28 -0800 We take this opportunity to announce that Sun is renewing its commitment to Java 3D. The highlights of this announcement are: . Sun is in the process of making the source code for Java 3D available through a public source license in the very near future. . Sun will work with the Java 3D community, via the Java Community Process (JCP), to actively evolve the API going forward. -------------------- The renewed emphasis on Java 3D complements Sun's increased efforts in the desktop space and the recent release of the Java Desktop System (JDS). More information will be forthcoming, but here are a few details concerning our plans. . Sun is right now working on making the source code for Java 3D available through a public source license. This will be done via a java.net project, which will include a developer's web site and CVS repository. This will allow developers to download the Java 3D source code, and to contribute bug fixes and utilities. The time frame for this release is before JavaOne 2004. . We will be forming an expert group under the JCP process to define and implement the next version(s) of the Java 3D API. Our current thinking is that we want to work with the expert group to create a 1.4 version of the Java 3D API that will add programmable shaders, and possibly other critical features, if they can be done without architectural changes to the implementation. We hope to get this release out relatively quickly. . We also want the expert group to help define the next major revision (1.5? 2.0?) to the Java 3D API, which could involve more widespread changes to the API. We look forward to working with the Java 3D community to move the API forward. Doug Twilleager Sun Microsystems |