Any possibility of supporting newer JDK features?

Any possibility of supporting newer JDK features?

• TopTN

  I'm not interested in J2EE, or in the entire J2SE environment.  I don't even care that much if we add more new areas in the classes for the J# system.
  
  But, when I try to port MY code from Java to J#, I spend lots of time working around incompatibilities in the exiting class libraries.  
  
  J# has really old versions of just about every fundamental class in the JDK, and these classes work different, and have different members, than the real Java JDK.
  
  This makes porting any code from a recent Java (1.4 say) to J# a real pain.  Dates work different, Calander classes aren't there, ByteToCharConverter doesn't exist, Gregorian doesn't exist, BigInteger doesn't have the same members, SecureRandom doesn't have the same members, Array doesn't have the same members, etc.
  
  I also tried moving a JDBC driver over, only to find that fundamentals like the Driver and DriverManager classes are different.
  
  

• aprenot

  To me the question resides in... why is not there already
  You can convert jdk 1.2 code into c#, microsoft has a converted. I just saw the converter beta 3.0 that converts java jdk 1.3 and even J2EE, JNDI and so on (pretty advance code) into c#
  
  if j# is supposed to have the same syntax than java, how is it possible that microsoft is using resources to do such a nice conversion from java to c# but not from java to j#
  
  what's the point behind it
  
  
  Joaquin Grech
  
  

• doomgaze

  Chuck McD wrote:

  Now that Sun and Microsoft are supposedly making nice, would it be possible to update the class libraries to be a bit more complient with modern JDKs Or is J# really a dead-end, just here to allow J++ users a migration path

  
  
  Hi Chuck,
  
  First of all, thanks for your interest in J#! Your question is probably the #1 question I get.
  
  First a bit of history for the sake of others reading this post... Visual J# was originally intended as a migration path for the Visual J++ user. I'm sure you're familiar with the Sun/Microsoft history there - since we had to stop working on J++ we decided when we were building the .NET Framework that we could help J++ users stay current by building J# to carry forward their existing J++ assets. Since then, we've seen the majority of interest in J# from ISV customers who want to preserve their business logic when porting their Java offerings to the .NET Framework. In fact, we have several case studies of ISV's doing this at the J# Dev Center. So in 2005, we've taken feedback from these customers and have done a lot of work to round out the business logic JDK functionality to help these customers maintain better compatibility with their Java source branches. So yes, the work we did in 2005 includes a lot more JDK functionality in the areas of collections, util libraries, serialization, some new keywords, etc.
  
  But the key word here is business logic. We aren't building the entire J2xE framework on top of the .NET Framework - that's never been our goal, and quite honestly we don't have resources to build both a Java stack implementation and support for the .NET Framework. But we will continue to do what we can to support customers who want to preserve their business logic when porting their Java applications to the .NET Framework. We have found when talking to customers that the business logic is the most expensive section of the application to build and maintain, and when it comes to considering migrations, customers understandably want the business logic to "just work" - re-implementing the platform-specific code is not only much easier than re-implementing the business logic, but it also affords the opportunity to re-architect the platform-specific layer and optimize for the platform (in this case, the .NET Framework).
  
  Now, that's a long post to answer your question, but with all of that said... do you have specific asks for business logic enhancements we can make If so, let me know so we can triage them and see what we can do for future versions. If you haven't already done so, check out Visual J# 2005 to see what we've already done for you here. The customers I've talked to have been happy with what we've done so far.
  
  All the best -
  Brian Keller
  Product Manager
  Visual J#
  
  

• Alaa_fcis

  I think many Java aspects can be found in .NET, but with different names. Thus, there should be a converter from Java to J#, as soon as possible.

  
  
• Any possibility of supporting newer JDK features?