Re: [Jessie-discuss] 1.4 support? ("1.4 not enabled")

[Casey Marshall]

>>>>> "Martin" == Martin Egholm Nielsen <address@hidden> writes:

Martin> Hi Casey,
Martin> I'm trying to use Jessie as a replacement for Sun's
Martin> implementation.  However, I reach a point where Sun's
Martin> "java.net.Socket" invokes a method on Jessie's SSLSocket that
Martin> is not supported (#isInputShutdown):
Martin> --- 8< ---
Martin> If I scan the source for Jessie's SSLSocket, I however see
Martin> that there is some commented code in #isInputShutdown:
Martin> --- 8< ---
Martin> So, my question: Should one avoid using Jessie with Suns Java
Martin> 1.4, and do you know whether the new GCJ 4.0 has been
Martin> "designed" to avoid these 1.4 methods?

>> I started developing Jessie so it could run on Sun's 1.2-1.4
>> runtimes, as well as on Classpath-derived ones. At the time, there
>> was a divergence between Classpath and Java 1.4 in the Socket class
>> (I don't know if this is still the case)

Martin> It is - that is what I saw today. Scanning Socket.java from
Martin> GCJ HEAD and comparing to Sun's.

I should update Jessie to reflect this, and make a new release that
targets these newer releases.

>> and you could configure the build (with autoconf) to target Java
>> 1.2, Classpath, or Java 1.4. In the latter case, the commented
>> stuff above would not be, and the exception would.

Martin> Oh, so configure no longer supports this? Doesn't look like it, no:
Martin> ./configure --help | grep [interesting]

Martin>    --enable-maintainer-mode enable make rules and dependencies not 
useful
Martin>                            (and sometimes confusing) to the casual 
installer
Martin>    --enable-jaxp           Compile with JAXP support (default=yes).
Martin>    --enable-single-jar     Put all built classes into `jsse.jar'
Martin> (default=no).
Martin>    --enable-awt            Compile AWT callbacks (default=yes)
Martin>    --enable-swt            Compile SWT callbacks (default=no)
Martin>    --disable-provider-only Only compile JSSE provider, not the
Martin> cleanroom JSSE
Martin>                            classes.

Yeah, that option has been removed, and the files that were generated
into Java source (.java.in) have been removed (except for a few
others, where I inject e.g. the version number).

Martin> However, looking at these options made me wonder: 1) What are
Martin> the jaxp stuff for - and what will I miss if disabling (going
Martin> embedded)? My first guess was for storing sessions as XML, but
Martin> otherwise?

JAXP is used for storing session data, and nothing else.

Martin> 2) What are the AWT callback stuff?

When parts of the code need to read a password, or something similar,
the code uses the javax.security.auth.callback package, along with
pluggable implementations of real UI elements that implement the
password request. The AWT callbacks are a concrete implementation of
these that use the java.awt package.

>> I think I abandoned supporting Sun's runtimes, and just focused on
>> making Jessie work with Classpath. If Classpath is to the point where
>> the 1.4 methods are all present, then I should update the source to
>> reflect this.

Martin> So you mean, the reason for omitting these methods was that
Martin> Classpath didn't have implementations for those methods, or
Martin> erronous implementations? Just so that I know what to look for
Martin> if trying (with GCJ 3.4.3 for starters)...

Yeah, Classpath did not have those methods at all at the time, meaning
that Jessie wouldn't even compile with a free environment. I think
that all of this was prior to the release of GCC 3.4, and I always
wanted to ensure that it worked with GCJ.

>> In the meantime, I'd just suggest uncommenting those parts of those
>> methods. All the code to support Java 1.4 should be there, just
>> commented out.

Martin> All places are marked with Unsupported-1.4-exceptions, right -
Martin> just to know what to grep for...

Yeah, it should always be 'UnsupportedOperationException', I believe.

-- 
Casey Marshall || address@hidden